Support custom stdio MCP servers in 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

Cowork sessions cannot use custom stdio-based MCP servers. Organizations with private MCP ecosystems (e.g., internal GitHub, Jira, or CI/CD integrations published as stdio Node packages) have no way to connect them to Cowork. The built-in connectors cover common SaaS tools, but they can't replace organization-specific integrations that wrap internal APIs or enforce corporate auth flows.
This means Cowork users who need data from internal tools must leave Cowork entirely and use Claude Code in the terminal, or manually copy-paste information between systems. The same MCP servers work fine in Claude Code and other MCP-compatible tools (e.g., Cline) — only Cowork is missing this capability.

Proposed Solution

Allow Cowork sessions to register and connect to custom stdio-based MCP servers, similar to how Claude Code supports them via mcpServers in settings.
A possible approach:

Let users define custom MCP servers in Cowork settings (command, args, env vars) — the same format Claude Code already uses.
Cowork launches the stdio process in a sandboxed or user-scoped context and exposes the server's tools to the session.
Optionally, support an "approved servers" list at the organization level so IT teams can allowlist specific packages.

This would bring Cowork to parity with Claude Code for MCP support and make it viable for enterprise users who depend on internal integrations.

Alternative Solutions

Use Claude Code instead of Cowork — works today, but Cowork's UI and file/tool integration is better suited for non-developer workflows. Forcing users to the terminal defeats the purpose of Cowork.
Wrap stdio servers in an SSE/HTTP bridge — technically possible but adds infrastructure overhead and maintenance burden that shouldn't be necessary.
Wait for built-in connectors to cover every use case — not realistic for private/internal tools that will never be in Anthropic's connector catalogue.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

Our organization publishes internal MCP servers as private npm packages (e.g., @telus/mcp-github-pr, @telus/mcp-jira-server). These servers wrap our GitHub Enterprise and Jira instances with corporate SSO auth.
Concrete workflow that's currently broken in Cowork:

A Jira ticket references a GitHub PR by branch name (e.g., PSS-42095)
I need to look up the corresponding PR to identify the developer and review status
Our mcp-github-pr server can do this lookup — it works in Claude Code via gh pr view 6812 --repo org/repo
In Cowork, I can't connect this server, so I have to switch to a terminal, run the command manually, and paste the result back

With custom MCP support in Cowork, the server's tools would be available directly in the session, and the assistant could look up PRs, read Jira attachments, and trace code changes without leaving the conversation.

Additional Context

The GitHub connector (#23775) was filed as a bug and is now closed/locked — it acknowledged Cowork support was missing but no resolution was provided.
This affects any organization with private MCP servers — not just GitHub integrations. Internal Jira, Confluence, CI/CD, observability, and custom API wrappers all fall into this gap.
Claude Code already supports the exact config format needed (mcpServers with command/args/env). Reusing that schema in Cowork would minimize implementation effort and user confusion.
Google Drive connector (#30457) is also broken in Cowork — the pattern of connectors not working in Cowork seems broader than one tool.