Custom MCP connector wedges silently after MCP server restart (requires full remove+re-add to recover)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

A custom MCP connector registered in Claude desktop (Cowork mode) silently wedges every time the underlying MCP server process restarts. All tool invocations return "Tool execution failed" with no diagnostic output. The server-side OAuth state is properly persisted to disk and survives the restart, so every other client (Chrome with pasted tokens, curl) works fine. Only the Cowork connector is stuck.

Environment

• Claude desktop app (Cowork mode)
• - OS: Windows 11 (Geekcom AX8 Max desktop)
• - - Plan: Max
• - - - Custom MCP server: self-hosted Node.js/Express at https://mcp.dailybreadagent.com/mcp, registered as "FGF Monitor"
• - - - - MCP transport: Streamable HTTP
• - - - - - Auth: OAuth 2.0 with dynamic client registration (per spec)

Reproduction

1. Register a custom MCP connector in Claude desktop Settings > Connectors. Use OAuth / DCR.
2. 2. Successfully use the connector's tools from Cowork (no issues).
3. 3. Restart the underlying MCP server process. Server's OAuth state (clients, access tokens, refresh tokens, auth codes) IS persisted to disk and survives the restart. Confirm with server logs.
4. 4. From Cowork, call any tool on that connector.
5. 5. Observe: "Tool execution failed" with no further detail. No WWW-Authenticate prompt, no clear indication that re-auth is needed.

Expected Behavior

Either:

• (a) Connector silently refreshes its access token via the stored refresh token when it detects a 401, then retries. This is standard OAuth 2.0 behavior.
• - (b) Connector surfaces a clear "reconnect" prompt or detailed error instead of silently returning "Tool execution failed".

Actual Behavior

Connector silently fails with no remediation path from within Cowork. The only recovery is manual:

1. Settings > Connectors > [connector] > three-dot menu > Remove
2. 2. Re-add with the same URL (triggers fresh DCR + OAuth flow)

Recovery attempts that DO NOT work (empirically tested multiple times)

• Toggling the connector off and back on in Settings > Connectors
• - Fully closing and relaunching the Claude desktop app
• - - Waiting for self-recovery (observed no recovery over 45+ minutes)

Impact

Two hour-long manual recovery sessions on 2026-04-23 and 2026-04-24. Every legitimate server restart (code deploy, config change, credential rotation) requires walking through the full remove/re-add dance. This effectively blocks agentic workflows that involve rotating server-side secrets.

Server-side evidence that persistence is working

In my MCP server's state directory, all four persistence files are updated on restart and restored on boot:

• oauth-clients.json (DCR registrations)
• - oauth-access-tokens.json
• - - oauth-refresh-tokens.json
• - - - oauth-codes.json

On each restart, server logs: {"level":"info","msg":"oauth_provider_loaded","clients":3,"access":3,"refresh":3,"codes":0}.

A non-Cowork client (curl with master bearer token via query string) continues to work through the restart without any issue.

Suggested fix direction

Investigate the client-side MCP transport's handling of 401 responses after a server restart:

• Does the client attempt a refresh_token grant at /token?
• - If so, does it surface the refresh failure to the user with actionable information?
• - - If not, why does the client keep using a stale access_token instead of refreshing?

Happy to share full diagnostic output including server logs, OAuth provider logs, and a timeline of the failure mode. File is at 2026-04-24-FULL-SESSION-RECAP.md on my end.

What Should Happen?

Either (a) the connector silently refreshes its access token via the stored refresh token when it gets a 401, per standard OAuth 2.0 behavior, or (b) it surfaces a clear re-authenticate prompt instead of returning 'Tool execution failed' with no detail."

Error Messages/Logs

Steps to Reproduce

1. Register a custom MCP connector in Claude desktop Settings → Connectors. Use OAuth with dynamic client registration. The server should run /register, /authorize, /token endpoints per the MCP auth spec.

1. Successfully use the connector's tools from Cowork. Verify everything works — tools respond, no errors.

1. Restart the underlying MCP server process (e.g., Restart-Service on Windows, or systemctl, or just kill -9 and let the supervisor relaunch). The server's OAuth state — registered clients, access tokens, refresh tokens, auth codes — IS persisted to disk and survives the restart. Confirm via server logs (e.g., oauth_provider_loaded clients=3 access=3 refresh=3).

1. From Cowork, call any tool exposed by that connector.

1. Observe: every tool call returns "Tool execution failed" with no further detail. No WWW-Authenticate prompt is surfaced. The user has no in-app indication that re-authentication is required.

1. Try toggling the connector off and back on in Settings → Connectors. Tools still fail.

1. Fully close and relaunch the Claude desktop app. Tools still fail.

1. Wait. Observed no self-recovery over 45+ minutes.

1. Recovery only works by removing the connector entirely (three-dot menu → Remove) and re-adding it with the same URL. New DCR registration runs, new OAuth flow runs, then tools work — until the next server restart.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.119.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_