[BUG] Cowork HTTP MCP plugins: silent connection drops, Authorization header dropped on tools/call, and GitHub-disconnect "fix" wipes plugins for the whole workspace

Reporter: Courtland Nicholas (Regal.ai) — courtland@regalvoice.com
Filed: 2026-05-04
Cowork client: desktop app, current as of filing date
Affected plugin: ask-reggie from Regal-Voice/claude-plugins
Backend: HTTP MCP server at https://claude-plugins-production.up.railway.app/mcp
Affected users: at least 2 members of our team confirmed; expect every team using HTTP-type MCP plugins on multi-user Cowork workspaces is affected.

Summary

Cowork's HTTP MCP client has at least four distinct, observable lifecycle issues with HTTP-type plugins. They stack: each one is reproducible on its own, and they compound to make HTTP MCP plugins unusable on multi-user workspaces without painful workarounds. Verified against ask-reggie over multiple sessions and confirmed by at least two members of our team.

The four issues:

1. Silent connection drops within a session, with no UI surface or auto-retry.
2. "Unauthorized" failure mode after plugin reinstall — handshake succeeds, but every tools/call arrives at the server without an Authorization header.
3. Connector status indicator in the Cowork UI is out of sync with actual transport state.
4. Disconnecting the workspace-shared GitHub connector (the plugin marketplace source) removes plugins for every workspace member, forcing all teammates to reinstall.

Environment

• Plugin manifest: Regal-Voice/claude-plugins/plugins/ask-reggie/.mcp.json — six MCP server entries, all "type": "http" pointing to the same Railway endpoint, with Authorization: Bearer <token> set in the headers block.
• Server: Express app on Railway, single /mcp POST endpoint serving JSON-RPC 2.0. initialize and tools/list are unauthenticated to support the Cowork Connect handshake; tools/call requires the bearer token.
• CORS: Restricted to https://claude.ai and *.claude.ai origins; CORS middleware runs before express.json().
• Marketplace: the plugin is installed via the Cowork plugin marketplace, sourced from a GitHub connector pointed at Regal-Voice/claude-plugins.

Issue 1: Silent connection drops within a single session

Symptom

The plugin's tools disappear from the deferred-tool list mid-session with no user-visible notification — no toast, no log entry, no retry indicator. Sometimes the tools come back on their own ~1–3 minutes later, often paired with another plugin reconnecting in the same system reminder. Sometimes they don't come back without intervention.

Repro

In a single ~15 minute Cowork session against ask-reggie, observed four flap cycles. The pattern in the system reminders:

[deferred tools: 24 ask-reggie tools available]
…work continues…
[deferred tools no longer available: 24 ask-reggie tools]
…wait 1–3 min…
[deferred tools now available: 24 ask-reggie tools]

Each disconnect/reconnect happened in the same system reminder where another plugin namespace (plugin_regal-marketing_*) reauthorized. Strongly suggests Cowork is rebuilding its MCP connection set and HTTP plugins are not always preserved across the rebuild.

Diagnostic evidence the drop is client-side

During every disconnect window:

• curl against the same /mcp endpoint with the bearer token returns HTTP 200 in ~1s with the expected payload.
• The same backend, accessed via a separate Slack bot transport, succeeds with no errors.
• Railway logs show zero connection errors, zero auth failures, zero crashes, zero restarts.
• The disconnect is not visible in any server-side log because Cowork doesn't reach the server during the window.

Expected behavior

HTTP MCP connections should either persist for the session lifetime or auto-retry with backoff and surface their state to the user.

Issue 2: "Unauthorized" failure mode — auth header dropped on tools/call

Symptom

After a fresh plugin install (or in a half-broken state after a reinstall), the connector appears connected — tools surface in the deferred-tool list, schemas load — but every tools/call returns:

Unauthorized: bearer token required for tools/call

This is distinct from Issue 1: the connection is up, the tools are listed, but the Authorization: Bearer <token> header from .mcp.json is not being attached to tools/call requests. The server only requires the header on tools/call (handshake methods are unauthenticated to support Cowork Connect), which is why the connector looks healthy until the user actually invokes a tool.

Repro

1. Install ask-reggie plugin from the marketplace.
2. Run any tool, e.g. list_tables.
3. Server returns Unauthorized: bearer token required for tools/call.

Diagnostic evidence

curl to the same endpoint with the same bearer token from .mcp.json returns the expected payload immediately. Token has not been rotated; .mcp.json is unchanged. The header is simply not arriving on Cowork-originated tools/call requests.

Expected behavior

Authorization headers declared in .mcp.json should be attached to every JSON-RPC method dispatched to the corresponding HTTP server, including tools/call.

Issue 3: Connector status UI out of sync with transport state

The Cowork UI shows the connector as connected (icon lit, no error indicator) during windows where the underlying connection has actually dropped or where calls are failing. Conversely, on at least one occasion the icon was not lit during a successful tool call, and then the connection dropped seconds later. The UI is unreliable as a signal of real connection state.

Issue 4: GitHub connector disconnect blast-radius across workspace

This is the most operationally painful issue. The GitHub connector in Cowork serves as the plugin marketplace source for the workspace. Multiple support paths today recommend "disconnect and reconnect GitHub" as a fix for Issue 2. Disconnecting GitHub removes the plugin marketplace and the installed plugins for every member of the workspace, not just the user performing the action. All other workspace members must reinstall their plugins. There is no warning dialog, no scope-clarification, no per-user fallback.

This turns what looks like a local self-help action into a team-wide outage. Two members of our team have hit Issue 2 in May 2026; cycling GitHub fixed each user but re-broke everyone else.

Expected behavior

Either: (a) GitHub connector state should be per-user, not workspace-wide; (b) disconnecting should require a confirm dialog explaining the workspace-wide impact; or (c) the underlying auth-header bug (Issue 2) should be fixed so the GitHub-disconnect "fix" is no longer recommended.

Suggested fixes

In rough order of impact:

• Fix Issue 2 by re-reading the headers block in .mcp.json on every tools/call dispatch, or attaching the static headers at HTTP transport construction time and persisting them across the connection lifetime.
• Fix Issue 1 by adding auto-retry with exponential backoff for HTTP MCP connection drops, and surface the retry state in the connector UI.
• Fix Issue 3 by tying the connector status indicator to real transport state rather than to the last handshake result.
• Fix Issue 4 by either scoping GitHub state per-user or adding a confirm dialog with explicit "this will remove plugins for all N workspace members" text.

Reproducibility / scope

Not isolated to ask-reggie — the underlying issues affect any HTTP-type MCP plugin in Cowork on a multi-user workspace. We have a clean repro available on request.

Workarounds we currently use

In strict order of cost (do not skip ahead to the GitHub step):

1. Wait 1–3 minutes for Cowork to shuffle connections and self-recover.
2. Restart Cowork.
3. Reinstall the affected plugin from the marketplace.
4. Sign out and back in.
5. Full Cowork app uninstall/reinstall — local-only blast radius.
6. LAST RESORT, with team coordination only: disconnect/reconnect the GitHub connector — workspace-wide blast radius.

Contact

Courtland Nicholas — courtland@regalvoice.com — happy to provide the Railway endpoint, server source, plugin manifest, or a recorded session demonstrating the repro.