[FEATURE] Bridge local stdio MCP servers into cloud Cowork sessions
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Related to #20377, #23424, #26259, #48909 and #73410, filed separately because none of them raises the aspect below. If you judge it a duplicate anyway, please close it and carry the argument over to whichever thread is canonical.
In cloud Cowork sessions, HTTP remote MCP servers work and local stdio MCP servers do not. The existing threads frame this as a feature-parity gap: #20377 (closed), #23424 (closed as duplicate), #26259 (closed as not planned), #48909 (closed as duplicate). #73410 covers the adjacent but different case of internal HTTP MCP servers.
The aspect none of them covers: this is not only a parity gap, it is a mitigation for three open and unresolved OAuth defects.
The forced path
Because stdio is unavailable, anyone who needs an MCP server in a cloud session must use the remote HTTP path. That path routes OAuth through mcp-proxy.anthropic.com, which currently does not refresh tokens:
- anthropics/claude-ai-mcp#228 - the proxy reconnects but never calls
/token, refresh is not attempted. Open since 2026-04-24. - anthropics/claude-code#65036 - the refresh token is stored but never used proactively. A manual "Connect" completes the same exchange in about 200 ms. Open since 2026-06-03.
- anthropics/claude-ai-mcp#308 - affects even the first-party M365 connector: MFA re-auth every 1 to 2 days despite a 90-day tenant sign-in policy. Open.
The only transport Cowork offers in the cloud is therefore the one with the known token-lifecycle defect.
Evidence from an instrumented deployment
Microsoft 365, April 2026. I run a self-hosted Softeria ms-365-mcp-server behind an OAuth 2.1 endpoint, with token-hash and header logging in both the auth middleware and the Graph client. Findings over a full debug day:
- The client never sends
x-microsoft-refresh-token.has_rt=falseon every request, so the server cannot refresh on the client's behalf either. - The access token hash stays constant for more than an hour. No silent rotation occurs.
- No
/tokencall reaches the OAuth endpoint after the initial authorization. - Two server builds (npm 0.79.6 and HEAD with a server-side token store patch) behave identically. That rules out the MCP server as the cause.
- Manual reconnect in the client is the only thing that restores access. Reproduced six times in one day.
The same server binary run locally over stdio is stable indefinitely: the token lives in the OS credential store, one process, one consumer, no rotation race.
Proposed Solution
Bridge local stdio MCP servers into cloud Cowork sessions over the device connection that already exists.
A cloud Cowork session already holds a live channel to the user's machine and already uses it to list directories, stage files into the container, and commit files back. Proxying a local stdio server's JSON-RPC over that same channel would not require a new transport or a new trust boundary.
Concretely, the local stdio servers already configured on the desktop (shown as "Local Dev" connectors) would appear in a cloud session with their tools available, the same way they do when the session runs on the machine itself.
The security property is the point: the refresh token stays in the OS credential store on the user's machine and never traverses mcp-proxy.anthropic.com. That sidesteps #228 and #65036 rather than waiting for them to be fixed, and it also serves the enterprise case in #73410 where the MCP server must not be reachable from the public internet.
If bridging local stdio servers is architecturally out of scope, an explicit statement to that effect would still help. #26259 was closed as not planned without one, and the same request keeps being filed.
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_