Illustrator UXP secureStorage persistence discrepancy between debug preview and signed release in version 2023.2

Short answer

No. In Illustrator's UXP host of the 2023.2 era, treat secureStorage as scoped to the plugin's identity and signing context. A value written during a UXP Developer Tool (UDT) debug-preview session is not expected to be readable from the same plugin's signed release build. A null from getItem() in the signed build after a debug write is consistent with that design; it is not by itself proof of a persistence defect.

Documented behavior vs. inference

Documented

• secureStorage persists across sessions for a given plugin ID.
• getItem() returns null when no value is found for the key.
• The backing store is the OS credential store (Keychain on macOS, Credential Manager on Windows).

Inferred, not confirmed

• Debug preview loads the plugin from a folder under a development identity; a signed release carries a different identity and signature. Credential-store entries keyed by identity would therefore be distinct — the most plausible explanation for the null return.
• Whether the keying is the manifest id, the signing certificate, or a combination is implementation-specific. Do not assume.
• No Adobe commitment to align debug-mode storage with release behavior can be confirmed here. Design as if parity is not guaranteed in 2023.2 or later.

Also note that Illustrator's UXP support in that timeframe was comparatively early, so behavior may differ from the more mature Photoshop UXP host. Verify against your exact host build rather than extrapolating.

Verification steps

1. Log the manifest id and host version in both contexts, so you can see whether identity actually matches.
2. Round-trip inside debug only: write, fully quit Illustrator, reopen, read. If the value is gone even in debug, the debug path is ephemeral — a different problem from cross-context scoping.
3. Round-trip inside the signed release only, using the same procedure.
4. Test the reverse direction (write in release, read in debug) to see whether the mismatch is symmetric.
5. Inspect the OS credential store after each write, searching by plugin name in Keychain Access or Credential Manager. Entry naming is implementation-specific, so a GUI search is more reliable than a guessed service name.

const { storage } = require("uxp");
const { secureStorage } = storage;

await secureStorage.setItem("token", value);
const readBack = await secureStorage.getItem("token"); // null when absent
// Log readBack together with your manifest id and host version.

Debug-only fallback

Yes, a debug-only fallback is reasonable, with two hard rules: gate it behind an explicit build flag so it cannot ship, and never place long-lived production credentials in it. A file in the plugin's data folder is sufficient for token caching during local testing. Keep secureStorage as the release path.

One detail that changes the recommendation

Does the value survive a full host restart within the same debug-preview context? If yes, this is identity scoping and the fallback only needs to cover cross-context reads. If no, debug storage is ephemeral in your host build and the fallback must cover all debug reads, not just cross-context ones. That single observation determines the shape of the workaround.