Foundation decisions

Original baseline: Platform main at f0125a735ff1dff5687a8438c464863836315bfd. Selected implementation: draft Platform PR #1129, head 542b32ef34c3a4fcdbe9165c262247474d8db11b, inspected on 22 October 2026.

The local ADR-024 reference preserves the proposal. The implementation branch changes its status to accepted and links PR #1129; the decision body is unchanged. That branch metadata is an adoption candidate, not evidence of mainline adoption. Shared semantic operations and WebMCP remain separate proposals, outside this foundation.

Foundation boundary

WorkOS authentication and trusted tenant/environment/resource binding establish the connection.
Tenant activation and mcp:read are required for protected MCP use. The write-permission tool also requires mcp:write.
Both tools return fixed, bounded messages. They read no inventory, mutate no business data and emit no business events.
Semantic commands/queries, generated business tools, browser refactoring, WebMCP and event-envelope changes are excluded.
Operational attribution records the verified human/client context. Delegation is not proof that the human approved each action.
Any later business exposure needs separately adopted shared-operation architecture and reviewed domain authorization/provenance.

Resolved direction

The first version uses the person's MCP permissions for the tenant across their connected clients. Separate read-only/write limits for individual clients are deferred.

This delivery introduces Platform's first WorkOS feature flag: Remote MCP access for organizations, with slug entitlement-remote-mcp-org, to control MCP availability for a tenant. Tenant access is resolved after authentication without assuming permissions, groups or flags are present in the Connect token. Every protected request resolves current WorkOS authority without an access cache. An admitted request expires at external-token expiry or eight seconds after its first access lookup, whichever comes first. WorkOS propagation delay remains to be measured and accepted before activation.

The proposal uses WorkOS's organization-flags API and existing role-permission lookup. The separate activation-file/revision/acknowledgement proposal is withdrawn. Chimp 0.6.0 and protocol revisions 2025-06-18 / 2025-11-25 are selected for Codex desktop. The buffered-response deadline guard resolves the previous ongoing-request expiry design gap; its guard-level test passes in hosted CI. No streaming or business effects are introduced.

The foundation is evaluated through the manual client checks and technical tests. A separate business-user trial belongs with future inventory or query functionality, where participants can evaluate real tasks rather than fixed permission tools.

Design findings

Review finding	Selected resolution	Evidence and limits
Tenant-disable freshness and failures	Fresh flag, membership, permission-definition and effective-role lookups on every protected request; eight-second maximum authority.	Resolver and endpoint code plus hosted tests support this. Measure provider propagation and withdrawal before activation.
Lost consent attribution	Typed WorkOS `sid` preserved through MCP-only internal credentials and verified context.	Codec round-trip and distinct-consent tests pass in hosted CI; inspect live operational attribution before activation.
Permission-denial recovery	Stable `403` reasons and administrator guidance, separate from `401` renewal and dependency `503 mcp_unavailable`.	Endpoint tests and response-fixture captures support the distinction. Real OAuth cancellation, renewal and withdrawal remain outstanding.
Navigation-coupled permissions	Core catalog supplies navigation, MCP policy and deterministic bootstrap export. Definitions do not grant access.	Catalog, aliases and sorted JSON exporter inspected; hosted catalog/navigation tests pass. Target-environment provisioning remains deliberate.
Expiry after dispatch	Buffer the complete reply and check authority before and after the synchronous handler.	Hosted controlled-clock guard test withholds an expired result. Verify actual release behavior before activation.
HTTPS CIMD client identity	Accept a bounded, signed HTTPS metadata URL or existing opaque client ID; never fetch the URL.	Signed-token tests pass in hosted CI. Author reports the fix enabled real Codex OAuth and both desktop probe calls.

Approval and activation

Implementation evidence records the inspected commit, hosted results, author-reported trials and limitations. The library, revisions, authority lifetime and initial operating limits are no longer open design choices. The specification is approved as Ready. The implementation PR determines the final design; this specification can be updated afterward. Readiness does not establish ADR adoption, implementation merge or release acceptance.

Before activation, name the operational owner and exact release/environment/client baseline, complete renewal, withdrawal, two-tenant and browser checks, and verify ingress and operating signals. The Delivery plan and Verification keep those gates explicit.