`ActiveOrganizationStorage`'s in-memory fallback is unreachable when `localStorage` exists but rejects writes — the tenant header is then never stamped for the whole session

[os-sales]

Found while documenting the X-Tenant-ID edge contract for #5279 (that card documents the observable consequence; it does not fix this). Measured, not reasoned — the probe is below.

The shape

packages/auth/src/createAuthenticatedFetch.ts — ActiveOrganizationStorage keeps a module-level _memoryValue as the fallback for environments without localStorage. set() always writes it. get() reads it only when the localStorage read itself throws:

get(): string | null {
 try {
 if (typeof localStorage !== 'undefined') {
 return localStorage.getItem(ACTIVE_ORG_STORAGE_KEY); // returns null, no throw
 }
 } catch { /* SSR / test */ }
 return this._memoryValue; // unreachable in that case
},

There is a real browser state where localStorage exists, reads fine, and rejects writes: Safari private browsing and any quota-exhausted origin, where setItem throws QuotaExceededError. In that state set()'s try swallows the write failure (correctly — the fallback is right there), but get() never consults the fallback, because the read path succeeded and returned null.

Probe

Run against the built dist/, with a localStorage that reads but refuses writes:

const store = new Map();
globalThis.localStorage = {
 getItem: (k) => (store.has(k) ? store.get(k) : null),
 setItem: () => { throw new Error('QuotaExceededError'); },
 removeItem: (k) => store.delete(k),
};
ActiveOrganizationStorage.set('org-42');

Result:

after set(), _memoryValue = org-42
after set(), get() = null

The value was stored and cannot be read back.

What it costs

For the whole session, in such a browser:

1. X-Tenant-ID is never stamped. createAuthenticatedFetch reads get(), so the request looks like a permanent first boot. Per the contract documented on Confirm whether X-Tenant-ID has a reader: the framework derives the tenant from the session, not the header #5279 the header is a routing hint that the edge falls through on, so this is not a data-scoping bug — the framework scopes from the session — but it does mean the tenant-routing input is missing on every request, not just early ones.
2. MetadataProvider's org-scoped session cache is permanently keyed @none. activeOrgScope() (packages/app-shell/src/providers/MetadataProvider.tsx) reads the same storage, and the whole point of that key is that it equals the tenant the entries were fetched under. It stays @none forever, and the first-boot relabel path never fires because the org id it waits for never becomes readable.
3. switchOrganization appears to succeed — the server-side active org does change — while the client-side stamp and cache scope never follow.

None of this is loud. There is no error, no warning, and no test covering the read-succeeds/write-fails combination; the existing tests exercise localStorage present and working, or absent entirely.

Repair sketch, for triage rather than as a decision

Make get() prefer a non-null localStorage read and fall back to _memoryValue otherwise, rather than returning the localStorage result unconditionally. That keeps the persisted value authoritative when it exists, and makes the memory fallback reachable in the state it was written for. The one thing to be careful about: after clear() the memory value is nulled too, so a fallback on null does not resurrect a cleared org — worth a test either way, since sign-out's clear is a security-relevant path.

[huangyiirene]

Triage: lands in packages/auth/src/createAuthenticatedFetch.ts (ActiveOrganizationStorage.get()) ⇒ domain:ui, graded Bug (label bug), queued (pm:queue).

Grading rationale: measured with a real probe (value stored, unreadable), reachable by ordinary users (Safari private browsing; quota-exhausted origins), and the cost is a silent whole-session degradation — tenant routing header never stamped, MetadataProvider cache permanently keyed @none, switchOrganization half-succeeding. The card's repair sketch (prefer non-null localStorage read, else fall back to _memoryValue) is the obvious mechanical shape; the one constraint the fix must pin with a test is the card's own caveat: sign-out's clear() must not be resurrected by the fallback — that path is security-relevant, and a naive "fallback on null" would re-stamp a cleared org. Test matrix: (a) read-succeeds/write-fails (the probe), (b) clear-then-get stays null, (c) plain working localStorage unchanged.

Sizing note: S. Related in-flight context: #5279 documents this window's observable consequence — if that PR's README section describes the unstamped window, the fix here narrows it; no ordering constraint, just cross-reference in the PR body.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 19
Session: session_01EuPCi56cnGyykygi3z9w4m
Branch: claude/issue-5703-active-org-storage-fallback
Worktree: objectui-issue-5703
Domain: domain:ui
File surface: packages/auth/src/createAuthenticatedFetch.ts and its tests (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus
Clause-②: no
Serial constraints cleared: packages/auth is free — #5724 (#5424) merged 01:07Z and released it. Round-19 siblings fenced disjoint: #5717 (packages/components + one apps/console specimen test) and #5660 (apps/console/index.html + src/main.tsx). Predecessor on this exact file, #5279/PR #5706, merged 2026-08-22 13:12Z — it documented this window; it did not fix it.

Tier basis. No path-derived mandate. Content judgement: clause ② does not trip — this is internal storage-read logic behind a module-local object; no contract accept/reject behaviour moves and no public surface widens. Size follows triage's S; tier at the default judgement档 because the clear() interaction is security-relevant.

Premise re-verified on origin/main d8afbe519 — the shape reproduces exactly:

• :47 — return localStorage.getItem(ACTIVE_ORG_STORAGE_KEY); returned unconditionally when localStorage exists.
• :50 — return this._memoryValue; reachable only when the read threw.
• :54 / :57 — set() writes _memoryValue first, then attempts localStorage.setItem.
• :63 / :66 — clear() nulls _memoryValue and removes the key.

So in a browser where localStorage exists, reads fine, and rejects writes (Safari private browsing; any quota-exhausted origin), set() correctly swallows the write failure into the memory fallback — and get() never consults it, because the read path succeeded and returned null. The card's probe measured exactly that: "after set(), _memoryValue = org-42 / after set(), get() = null."

Triage's ruling, binding. The repair sketch is the ruled shape: prefer a non-null localStorage read, else fall back to _memoryValue. ⚠️ The one constraint the fix must pin is the card's own caveat, and it is the security-relevant half: sign-out's clear() must not be resurrected by the fallback. A naive "fall back whenever the read is null" would re-stamp a cleared org after sign-out. clear() nulls _memoryValue too, so the correct behaviour falls out — but it must be pinned, not relied on.

Required test matrix, from triage: (a) read-succeeds/write-fails — the probe; (b) clear-then-get stays null; (c) plain working localStorage unchanged.

Blast radius worth knowing while you work (do not fix these here — they are consequences that disappear when get() is repaired): createAuthenticatedFetch reads get(), so X-Tenant-ID is never stamped for the whole session; and activeOrgScope() in packages/app-shell/src/providers/MetadataProvider.tsx reads the same storage, so its org-scoped session cache stays permanently keyed @none and the first-boot relabel never fires. ⛔ packages/app-shell/** is out of fence. Cross-reference #5279 in the PR body per triage.

---

Generated by Claude Code