MCP OAuth workspace binding can silently diverge from CLI profiles in multi-client workflows

Summary

I work as one consultant across multiple client workspaces. The same remote MCP provider can represent different client data environments. Today it is too easy for a Codex MCP OAuth binding to silently point at the wrong workspace, while the provider CLI profile still points at the correct one.

This creates a real data-boundary risk for consultants and agencies: one shared MCP alias can be re-authenticated to Client B, then a later task for Client A can appear authenticated but search/query the wrong workspace.

Environment

• Codex Desktop / Codex CLI
• Remote HTTP MCP server with OAuth
• Same provider host for multiple workspaces
• Provider CLI supports named profiles correctly
• Codex MCP config has a shared server entry such as:

[mcp_servers.example]
url = "https://example.com/mcp"

Observed behavior

In a real local setup, with client names and workspace IDs redacted:

• The provider CLI profile remained logged into Client A.
• The Codex MCP server alias returned Client B projects after a separate OAuth flow.
• Browser incognito only controlled the workspace selected during OAuth. After callback, the durable binding belonged to the MCP client/server alias/auth store.
• A user can reasonably think "I authenticated in a separate browser/session" means the workspaces are isolated, but they are not.

In practice this meant:

provider CLI profile -> Client A workspace
Codex MCP search via shared alias -> Client B workspace/projects

Expected behavior

Codex should make multi-workspace MCP auth safer and more explicit. Ideally:

1. Show the authenticated MCP workspace/account/org in codex mcp list and/or codex mcp get <server> when the server/provider exposes it.
2. Warn before re-auth overwrites or changes an existing remote MCP binding.
3. Support first-class per-MCP auth profiles, similar to provider CLI profiles.
4. Document whether OAuth tokens are keyed by server alias, endpoint, OAuth resource, client registration, or CODEX_HOME.
5. Provide a clear recommended workflow for consultants with one machine and multiple client workspaces.

Current workaround

Hard isolation appears to require separate Codex homes:

CODEX_HOME=~/.codex-client-a codex mcp login example
CODEX_HOME=~/.codex-client-b codex mcp login example

Alias-only isolation may work in some clients, but it is not a safe assumption because MCP token storage is client-specific and some clients/providers can deduplicate by endpoint or connector identity.

Why this matters

This is not just convenience. For consultants and agencies, querying the wrong client workspace is a data-boundary incident. The product should make the active MCP identity visible and hard to confuse.

Related issues

This is related to, but more specific than:

• #4432 - first-class multi-account auth
• #23453 - Codex Desktop MCP settings list does not show OAuth login/status per server
• #14144 - active session can keep stale MCP auth after reauth
• #17265 - routed MCP OAuth token refresh problems
• #13891 - OAuth resource indicator / token audience issues

The missing piece in this report is the multi-client workspace-boundary risk: CLI profiles and MCP OAuth bindings can diverge, and the active MCP workspace is not visible enough to catch that before a tool call uses the wrong client context.