MCP OAuth workspace binding can be ambiguous 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 Claude Code / Claude connector MCP OAuth binding to point at the wrong workspace, while another local tool or CLI profile for the same provider still points at the correct one.

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

Environment

• Claude Code / Claude connectors
• Remote HTTP MCP server with OAuth
• Same provider host for multiple workspaces
• Provider CLI supports named profiles correctly
• Project MCP config may contain a shared server entry such as:

{
  "mcpServers": {
    "example": {
      "type": "http",
      "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.
• A Claude/Codex MCP binding for the same provider 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, not the browser window.
• 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
MCP search via shared connector/alias -> Client B workspace/projects

Expected behavior

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

1. Show the authenticated MCP workspace/account/org in /mcp, claude mcp list, and/or claude mcp get <server> when the server/provider exposes it.
2. Warn before re-auth changes an existing remote MCP binding for a server/connector.
3. Document the intended hard-isolation model for MCP OAuth: server alias, endpoint, account connector, CLAUDE_CONFIG_DIR, project .mcp.json, or app-support OAuth cache.
4. Provide a recommended workflow for consultants with one machine and multiple client workspaces.
5. If possible, support first-class per-MCP auth profiles or multiple instances of the same connector, each with a visible account/workspace label.

Current workaround

Hard isolation appears to require separate Claude Code configuration directories plus explicit MCP config, then a workspace probe after login:

CLAUDE_CONFIG_DIR=~/.claude-client-a claude --mcp-config /path/to/client-a.mcp.json --strict-mcp-config
CLAUDE_CONFIG_DIR=~/.claude-client-b claude --mcp-config /path/to/client-b.mcp.json --strict-mcp-config

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. In local investigation, Claude app support storage also appeared to contain OAuth token-cache state, so CLAUDE_CONFIG_DIR isolation should still be verified after login rather than assumed.

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:

• #27567 - multi-account MCP connectors in Cowork
• #33430 - CLAUDE_CONFIG_DIR documentation for multi-account setups
• #50062 - account-level MCP connectors auto-loaded into CLI sessions
• #24317 - concurrent Claude Code sessions and OAuth refresh-token race conditions

The missing piece in this report is the multi-client workspace-boundary risk: provider 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.