MCP stdio transport pins its localization to the manifest defaults — the settings read happens in `start()`, inside the pre-bind window under every composition order

[os-steve]

Found by the step-1 measurement of #11045 (the settings bind-window gate). Filed per-plugin rather than fixed there, per that card's ruling.

This one is not the #10250 defect wearing a different hat: no dependency declaration can repair it.

What happens

packages/mcp/src/plugin.ts:301, inside MCPServerPlugin.start() on the stdio auto-start path (OS_MCP_STDIO_ENABLED / autoStart):

let settingsService: unknown;
try {
 settingsService = ctx.getService('settings');
} catch {
 settingsService = undefined;
}
const localization: EntryLocalization = await resolveLocalizationContext({
 ql: scopedQl, settings: settingsService, tenantId: initial.tenantId, userId: initial.userId,
});

The handle is acquired and consumed during start(). SettingsServicePlugin binds its data engine from its own start()-registered kernel:ready hook (settings-service-plugin.ts:153), which is strictly after every plugin's start(). So this read is inside the pre-bind window under every composition order — being started after the settings plugin does not help, and optionalDependencies: ['com.objectstack.service.settings'] would not move it.

Consequence

resolveLocalizationContext calls settings.getMany('localization', ['timezone','locale','currency']) (packages/core/src/security/resolve-authz-context.ts:757). In the window that resolves from the empty in-memory fallback plus the manifest defaults with source: 'default' — it does not throw, so failed stays false and the direct sys_setting $in fallback below it never runs. The declared defaults are non-empty, so the function returns { timezone: 'UTC', locale: 'en-US' } and reports success.

That value is then held for the life of the transport by design (#7279: "resolved ONCE for the life of the transport … the key's tenant cannot change mid-session"). A long-lived stdio MCP server therefore serves every call with UTC / en-US on a workspace whose persisted localization settings say otherwise, and never self-corrects. SettingsService.reportPreBindRead (#10250) does emit one warn line for the localization namespace at boot, which is the only symptom today.

Repair — one of

1. Move the localization hoist out of start() into a kernel:bootstrapped hook. That is the earliest phase after the bind, and the one reportPreBindRead's own remedy text names. The transport would need to either start from that hook too, or take the localization lazily.
2. Make localization lazy: resolve it on first use and memoize, instead of eagerly at transport construction. This keeps finding: a THIRD hand-written ExecutionContext assembly survives in the stdio MCP plugin, and it drops tabPermissions / accessToken #7279's property (not re-resolved per call) while moving the read out of the window.

Option 2 looks smaller and keeps the fail-closed identity probe where it is; whoever owns packages/mcp should pick.

⚠️ Do not repair this by adding optionalDependencies: ['com.objectstack.service.settings']. It would look like the #10250 fix and change nothing — packages/mcp is already ordered after the settings plugin in the serve composition (measured with the real resolvePluginOrder) and the read is still pre-bind.

Verification: after the fix, pnpm check:settings-bind-window must go green with the com.objectstack.mcp entry deleted from KNOWN_PRE_BIND_READS in scripts/check-settings-bind-window.mjs — that ledger is shrink-only and errors on a stale entry, so the deletion is part of the fix.

Suggested lane: whoever owns packages/mcp.

[os-zhuang]

Triage (Routine seat, hourly round): → pm:queue + domain:cli, type Bug.

Rationale: lands in packages/mcp (cli lane). Same pre-bind-window class as #11579 (found by the same #11045 measurement) but a different package in a different lane — routed separately by the anchoring rule, not foldable across seats. Expected fix follows the #10250 shape; verify against the check:settings-bind-window ledger the same way (shrink-only entry deletion is part of the fix).

---

Generated by Claude Code

[os-zhuang]

Claim — domain:cli seat

Session session_019siH5jDmk5hrayvfyojUqR, branch claude/issue-11580-mcp-stdio-settings-bind-window. pm:queue → pm:dispatched + assignee in one stroke, read back.

Declared file surface: packages/mcp (the stdio transport's localization read) and its test twin, plus the check:settings-bind-window ledger entry.

Direction is inherited and specific — triage (5392383903)

"Expected fix follows the #10250 shape; verify against the check:settings-bind-window ledger the same way (shrink-only entry deletion is part of the fix)."

Read what #10250 actually landed and transplant that shape. ⛔ Do not invent a second way to escape the pre-bind window.

⭐ The ledger deletion is not bookkeeping — it is the half that makes the fix real. A ratchet entry left behind after its site is repaired is a ratchet that has stopped measuring anything: it holds a ceiling for a leak that no longer exists, and the next reader cannot tell a fixed site from an unfixed one. Delete the entry in the same PR, and let the gate prove it (a stale entry should make the gate complain — if it does not, say so, because that is a finding about the gate).

⛔ Not foldable with #11579 — and the reason matters

Triage: "Same pre-bind-window class as #11579 (found by the same #11045 measurement) but a different package in a different lane — routed separately by the anchoring rule, not foldable across seats."

⛔ Do not touch #11579's package, and ⛔ do not "fix both while the context is loaded". The anchoring rule assigns a card to the lane owning the landing package; a cross-lane fold would put one seat's change under another seat's review and defeat the serial discipline both lanes rely on. If you find the two sites want a shared helper, that is a report, not a fold.

The defect

The MCP stdio transport pins its localization to the manifest defaults because the settings read happens inside start() — in the pre-bind window, under every composition order. So a stack that configures a locale gets the manifest's default anyway, silently.

⚠️ Re-derive the window on the ref you branch from. "Under every composition order" is a strong claim: check it rather than inherit it, and say what you measured. If some composition order does bind before the read, the card's shape changes and that is worth reporting rather than papering over.

Pins

Pin the configured locale reaching the transport, not merely that a read happens. And pin the ordering property, not one arrangement — a pin that passes only under the composition order you happened to test would leave the card's central claim unpinned.

Anti-vacuity: shown failing without the fix. Prove mutations on disk by grepping both the injected and removed text (an editor exit code proves nothing; a zero-hit sed exits 0), carry trap … EXIT INT TERM, predict the red/green split before running, and report a wrong prediction rather than fitting it. ⚠️ If the suite resolves a workspace dep through exports into dist/, rebuild between legs and read the dist occurrence count directly — a stale artifact gives a false green, measured repeatedly in this repo this week.

Clause-② — a stack's configured locale beginning to take effect is a behaviour change on a declared setting; measure and declare honestly rather than assuming no.

Delivery

Add a changeset. Push, open a draft PR with Fixes #11580, run the repo's fast checks plus the packages/mcp suite, derive the gate set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, and quote each gate's own verdict line — including check:settings-bind-window, which is the one that proves the ledger half. A gate that refuses is NOT MEASURED.

---

Generated by Claude Code