claude.ai connector wedges permanently in long-lived process: upstream returns 200+isError for every tools/call; /mcp reconnect rebuilds transport but not broker state; /mcp shows Connected throughout

Summary

In a long-running Claude Code process, a claude.ai account connector (enterprise-internal MCP server built on the official C# SDK, reached via mcp-proxy.anthropic.com) entered a state where every tools/call returns the connector's generic isError result (An error occurred invoking '<tool>'.) in 0.4–1.8s — 13/13 calls over 7+ hours — while:

• /mcp and claude mcp list showed Connected the entire time (initialize + tools/list succeed)
• an in-place /mcp reconnect fully re-initialized the transport (fresh claudeai-proxy connect in 1054ms, server capabilities returned) and the very next tool call still failed 10 seconds later
• the same connector worked simultaneously from Claude desktop and from a fresh claude -p process on the same machine and account
• a full process restart resolves it (third occurrence of this pattern here; previously 2026-07-14 and 2026-07-22)

Environment

• Claude Code 2.1.220 (native install), macOS (Darwin 25.5)
• Connector: claude.ai account connector, claudeai-proxy transport, server id mcpsrv_01U6x3GZTiLAwcqDEhqiY6wW
• Wedged process uptime ~2 days at failure onset; wedge survives /clear and /mcp reconnect

Timeline (all UTC, from the per-server mcp-logs jsonl)

| Time | Event |
|---|---|
| Jul 29 16:42:43 | Process start; Using claude.ai proxy at https://mcp-proxy.anthropic.com/v1/mcp/mcpsrv_01U6x…; connected in 1140ms |
| Jul 30 11:58:29 | Last successful tools/call from this process ("completed successfully in 2s") |
| Jul 31 18:57:51 | First failure; 13/13 failures from here on |
| Aug 1 01:36:57 | /mcp reconnect: "Successfully connected (transport: claudeai-proxy) in 1054ms", capabilities returned |
| Aug 1 01:37:08 | Next tools/call fails (~0.6s) |
| Aug 1 01:56:57 | Claude desktop, same account: success |
| Aug 1 01:58:17 | Fresh claude -p headless process, same machine: success |

Sample log lines (paths/session ids trimmed, server name redacted):

{"debug":"Initializing claude.ai proxy transport for server mcpsrv_01U6x3GZTiLAwcqDEhqiY6wW","timestamp":"2026-08-01T01:36:56.756Z"}
{"debug":"Successfully connected (transport: claudeai-proxy) in 1054ms","timestamp":"2026-08-01T01:36:57.810Z"}
{"debug":"Connection established with capabilities: {\"hasTools\":true,...,\"serverVersion\":{\"name\":\"[redacted internal C# server]\",\"version\":\"1.0.0.0\"}}","timestamp":"2026-08-01T01:36:57.810Z"}
{"debug":"Calling MCP tool: search_delinea_expertise","timestamp":"2026-08-01T01:37:07.931Z"}
{"error":"An error occurred invoking 'search_delinea_expertise'.","timestamp":"2026-08-01T01:37:08.579Z"}

Analysis

Server-side RCA (worked with the connector's owning team): the upstream server is built on the official C# MCP SDK, which by design returns tool-handler exceptions as HTTP 200 + CallToolResult{isError:true} with a sanitized generic message (modelcontextprotocol/csharp-sdk#635). The upstream session/state the broker holds for this client had died server-side; forwarded calls still reach the tool handler and throw. Because the failure surfaces as a successful tool result, none of the client's recovery machinery fires (401 → token refresh; 404/session-invalid → re-initialize). Treating an isError tool result as a tool-level error is arguably conformant client behavior — this issue is about the two gaps around it:

1. /mcp reconnect is not equivalent to a process restart for connector state. The reconnect demonstrably rebuilt the transport and completed a fresh initialize end to end, yet whatever broker-side upstream binding was stale survived it — while a fresh process (new client session) got a working binding immediately. Reconnect should mint the same fresh state a new process gets.
2. No health surfacing. /mcp reported Connected across 7+ hours of 100% tool-call failure. Connected currently attests to initialize/tools-list only. A tool-call failure-streak indicator (or a lightweight probe in claude mcp list) would make this class visible instead of silent.

A contributing asymmetry documented on the claude.ai MCP tracker: long-lived Claude Code clients hold a single upstream session while desktop/web create a fresh session per tool call (anthropics/claude-ai-mcp#583) — which matches why only the long-lived CLI process wedges.

Related

#65036, #46328, #75976; anthropics/claude-ai-mcp#450, #539, #583

Exact timestamps above are UTC and precise to the second if broker-side tracing is possible; happy to provide more detail.