claude.ai connector MCP session silently wedges after ~15 min idle — no drop detected, no reconnect; fresh process succeeds on the same call simultaneously

TL;DR

On the first tool call after ~15+ minutes of MCP inactivity, a claude.ai cloud connector (Atlassian, via mcp-proxy.anthropic.com, transport claudeai-proxy) accepts the request and never responds. The client detects nothing (no drop event, no error) and waits out the full 300s idle timeout. After the abort, the client keeps reusing the same dead session — every subsequent call in the process hangs the same way. /mcp reconnect or a process restart fixes it instantly (~800ms handshake). Related to #60061 (client detects an SSE drop on a self-hosted server but never reconnects), #75572 (dead pooled connections after a network-path change; same recovery asymmetry), #75601 (init hang after idle), and #54136 (reconnect feature request) - but not a duplicate: this is the first-party connector path end-to-end, triggered by pure idle with no network event, and the client never logs any drop. Together these look like one missing behavior: the client never re-initializes a suspect transport.

Environment

• Claude Code 2.1.126, macOS (Darwin 25.4.0), VS Code extension
• MCP server: claude.ai cloud connector "Atlassian" (https://mcp-proxy.anthropic.com/v1/mcp/mcpsrv_<redacted>, transport claudeai-proxy, server atlassian-mcp-server 1.0.0)
• No user-side proxy involved; direct HTTPS to the Anthropic proxy
• Recurred in 4+ separate sessions (Jun 30, Jul 12, Jul 14, Jul 18 2026) with idle gaps of 6.9, 22.7, and 16.4 min before the hang; affects trivial reads (atlassianUserInfo, getAccessibleAtlassianResources) and writes alike

Reproduction

1. Use any claude.ai connector tool — calls complete in 0.5–2s.
2. Do non-MCP work (or idle) for ~15+ minutes.
3. Issue any tool call on that connector.
4. Call hangs with zero progress until the 300s idle-timeout abort.
5. Retry: sometimes recovers (observed in two prior sessions), sometimes every subsequent call hangs identically for the life of the process (this session — 4 consecutive hangs; see trace).

Full traces (verbatim from ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-claude-ai-Atlassian/, only the connector id and our Atlassian site hostname redacted)

The first file is the wedged session. Note the timeline inside it: connection established 17:07:40; two fast well-formed error responses at 17:11:22/17:11:30 (bad cloudId — proving the error path responds in <1s); 8 successful calls through 17:23:59; then a 16.4-minute gap with no MCP traffic; then every call from 17:40:20 onward hangs with zero progress events. The remote-cancel failures are the user pressing Esc.

The second and third files are fresh processes started by the same user on the same machine while the first was wedged — each connects in ~800ms and completes atlassianUserInfo in ~500ms. The third file's success at 18:01:02.656 overlaps the first file's identical call dispatched 17:58:20, which was still silent and was cancelled at 18:01:49.

===== 2026-07-18T17-07-39-497Z.jsonl =====
2026-07-18T17:07:40.165Z [] Initializing claude.ai proxy transport for server mcpsrv_<redacted>
2026-07-18T17:07:40.165Z [] Using claude.ai proxy at https://mcp-proxy.anthropic.com/v1/mcp/mcpsrv_<redacted>
2026-07-18T17:07:40.165Z [] claude.ai proxy transport created successfully
2026-07-18T17:07:40.166Z [] Starting connection with timeout of 30000ms
2026-07-18T17:07:40.995Z [] Successfully connected (transport: claudeai-proxy) in 830ms
2026-07-18T17:07:40.996Z [] Connection established with capabilities: {"hasTools":true,"hasPrompts":false,"hasResources":true,"hasResourceSubscribe":false,"serverVersion":{"name":"atlassian-mcp-server","version":"1.0.0"}}
2026-07-18T17:11:22.041Z [] Calling MCP tool: searchJiraIssuesUsingJql
2026-07-18T17:11:22.594Z [] {"error":true,"message":"Failed to fetch tenant info for cloud ID: <redacted>.atlassian.net. Status: 404"}
2026-07-18T17:11:22.595Z [] Tool 'searchJiraIssuesUsingJql' failed after 0s: {"error":true,"message":"Failed to fetch tenant info for cloud ID: <redacted>.atlassian.net. Status: 404"}
2026-07-18T17:11:30.197Z [] Calling MCP tool: getVisibleJiraProjects
2026-07-18T17:11:30.819Z [] {"error":true,"message":"Failed to fetch tenant info for cloud ID: <redacted>.atlassian.net. Status: 404"}
2026-07-18T17:11:30.819Z [] Tool 'getVisibleJiraProjects' failed after 0s: {"error":true,"message":"Failed to fetch tenant info for cloud ID: <redacted>.atlassian.net. Status: 404"}
2026-07-18T17:11:43.830Z [] Calling MCP tool: getAccessibleAtlassianResources
2026-07-18T17:11:44.466Z [] Tool 'getAccessibleAtlassianResources' completed successfully in 636ms
2026-07-18T17:11:49.886Z [] Calling MCP tool: getJiraIssue
2026-07-18T17:11:50.528Z [] Tool 'getJiraIssue' completed successfully in 641ms
2026-07-18T17:12:30.751Z [] Calling MCP tool: createJiraIssue
2026-07-18T17:12:32.606Z [] Tool 'createJiraIssue' completed successfully in 1s
2026-07-18T17:13:40.876Z [] Calling MCP tool: editJiraIssue
2026-07-18T17:13:42.352Z [] Tool 'editJiraIssue' completed successfully in 1s
2026-07-18T17:13:42.360Z [] Calling MCP tool: getTransitionsForJiraIssue
2026-07-18T17:13:43.048Z [] Tool 'getTransitionsForJiraIssue' completed successfully in 687ms
2026-07-18T17:13:47.944Z [] Calling MCP tool: transitionJiraIssue
2026-07-18T17:13:49.199Z [] Tool 'transitionJiraIssue' completed successfully in 1s
2026-07-18T17:21:16.375Z [] Calling MCP tool: addCommentToJiraIssue
2026-07-18T17:21:18.570Z [] Tool 'addCommentToJiraIssue' completed successfully in 2s
2026-07-18T17:23:58.434Z [] Calling MCP tool: addCommentToJiraIssue
2026-07-18T17:23:59.359Z [] Tool 'addCommentToJiraIssue' completed successfully in 925ms
2026-07-18T17:40:20.339Z [] Calling MCP tool: createJiraIssue
2026-07-18T17:40:50.343Z [] Tool 'createJiraIssue' still running (30s elapsed)
2026-07-18T17:41:20.342Z [] Tool 'createJiraIssue' still running (60s elapsed)
2026-07-18T17:41:50.344Z [] Tool 'createJiraIssue' still running (90s elapsed)
2026-07-18T17:42:20.345Z [] Tool 'createJiraIssue' still running (120s elapsed)
2026-07-18T17:42:50.346Z [] Tool 'createJiraIssue' still running (150s elapsed)
2026-07-18T17:43:20.347Z [] Tool 'createJiraIssue' still running (180s elapsed)
2026-07-18T17:43:50.347Z [] Tool 'createJiraIssue' still running (210s elapsed)
2026-07-18T17:44:20.350Z [] Tool 'createJiraIssue' still running (240s elapsed)
2026-07-18T17:44:50.401Z [] Tool 'createJiraIssue' still running (270s elapsed)
2026-07-18T17:45:20.403Z [] Tool 'createJiraIssue' still running (300s elapsed)
2026-07-18T17:45:20.403Z [] Tool 'createJiraIssue' aborting: no response or progress notification for 300s (idle timeout 300s)
2026-07-18T17:45:20.406Z [] Tool 'createJiraIssue' failed after 300s: MCP server "claude.ai Atlassian" tool "createJiraIssue" sent no response or progress for 300s; aborting. If this server is configured in your MCP settings, set a per-server "timeout" (ms) to allow longer silent runs for just this server; otherwise set CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT (ms) globally (0 disables).
2026-07-18T17:45:27.928Z [] Calling MCP tool: searchJiraIssuesUsingJql
2026-07-18T17:45:57.930Z [] Tool 'searchJiraIssuesUsingJql' still running (30s elapsed)
2026-07-18T17:46:27.935Z [] Tool 'searchJiraIssuesUsingJql' still running (60s elapsed)
2026-07-18T17:46:57.940Z [] Tool 'searchJiraIssuesUsingJql' still running (90s elapsed)
2026-07-18T17:47:27.945Z [] Tool 'searchJiraIssuesUsingJql' still running (120s elapsed)
2026-07-18T17:47:57.951Z [] Tool 'searchJiraIssuesUsingJql' still running (150s elapsed)
2026-07-18T17:48:17.557Z [] Tool 'searchJiraIssuesUsingJql' failed after 169s: MCP error -32001: AbortError: remote-cancel
2026-07-18T17:48:31.049Z [] Calling MCP tool: atlassianUserInfo
2026-07-18T17:49:01.052Z [] Tool 'atlassianUserInfo' still running (30s elapsed)
2026-07-18T17:49:31.051Z [] Tool 'atlassianUserInfo' still running (60s elapsed)
2026-07-18T17:50:01.053Z [] Tool 'atlassianUserInfo' still running (90s elapsed)
2026-07-18T17:50:18.555Z [] Tool 'atlassianUserInfo' failed after 107s: MCP error -32001: AbortError: remote-cancel
2026-07-18T17:58:20.237Z [] Calling MCP tool: atlassianUserInfo
2026-07-18T17:58:50.240Z [] Tool 'atlassianUserInfo' still running (30s elapsed)
2026-07-18T17:59:20.240Z [] Tool 'atlassianUserInfo' still running (60s elapsed)
2026-07-18T17:59:50.240Z [] Tool 'atlassianUserInfo' still running (90s elapsed)
2026-07-18T18:00:20.245Z [] Tool 'atlassianUserInfo' still running (120s elapsed)
2026-07-18T18:00:50.250Z [] Tool 'atlassianUserInfo' still running (150s elapsed)
2026-07-18T18:01:20.256Z [] Tool 'atlassianUserInfo' still running (180s elapsed)
2026-07-18T18:01:49.008Z [] Tool 'atlassianUserInfo' failed after 208s: MCP error -32001: AbortError: remote-cancel
2026-07-18T18:09:51.437Z [] CLAUDEAI-PROXY connection closed after 3730s (cleanly)
2026-07-18T18:09:51.437Z [] Cleared connection cache for reconnection
===== 2026-07-18T17-47-49-391Z.jsonl =====
2026-07-18T17:47:49.935Z [] Initializing claude.ai proxy transport for server mcpsrv_<redacted>
2026-07-18T17:47:49.935Z [] Using claude.ai proxy at https://mcp-proxy.anthropic.com/v1/mcp/mcpsrv_<redacted>
2026-07-18T17:47:49.935Z [] claude.ai proxy transport created successfully
2026-07-18T17:47:49.935Z [] Starting connection with timeout of 30000ms
2026-07-18T17:47:50.754Z [] Successfully connected (transport: claudeai-proxy) in 819ms
2026-07-18T17:47:50.754Z [] Connection established with capabilities: {"hasTools":true,"hasPrompts":false,"hasResources":true,"hasResourceSubscribe":false,"serverVersion":{"name":"atlassian-mcp-server","version":"1.0.0"}}
2026-07-18T17:47:59.061Z [] Calling MCP tool: atlassianUserInfo
2026-07-18T17:47:59.530Z [] Tool 'atlassianUserInfo' completed successfully in 470ms
2026-07-18T18:09:51.498Z [] CLAUDEAI-PROXY connection closed after 1320s (cleanly)
2026-07-18T18:09:51.508Z [] Cleared connection cache for reconnection
===== 2026-07-18T17-55-32-535Z.jsonl =====
2026-07-18T17:55:33.468Z [] Initializing claude.ai proxy transport for server mcpsrv_<redacted>
2026-07-18T17:55:33.468Z [] Using claude.ai proxy at https://mcp-proxy.anthropic.com/v1/mcp/mcpsrv_<redacted>
2026-07-18T17:55:33.468Z [] claude.ai proxy transport created successfully
2026-07-18T17:55:33.469Z [] Starting connection with timeout of 30000ms
2026-07-18T17:55:34.249Z [] Successfully connected (transport: claudeai-proxy) in 781ms
2026-07-18T17:55:34.249Z [] Connection established with capabilities: {"hasTools":true,"hasPrompts":false,"hasResources":true,"hasResourceSubscribe":false,"serverVersion":{"name":"atlassian-mcp-server","version":"1.0.0"}}
2026-07-18T18:01:02.138Z [] Calling MCP tool: atlassianUserInfo
2026-07-18T18:01:02.656Z [] Tool 'atlassianUserInfo' completed successfully in 519ms
2026-07-18T18:09:51.442Z [] CLAUDEAI-PROXY connection closed after 857s (cleanly)
2026-07-18T18:09:51.443Z [] Cleared connection cache for reconnection

Analysis

The upstream trigger is one of two mechanisms - the client-side logs cannot distinguish them, and both are consistent with the traces:

• Stale MCP session: after ~15 min idle the proxy/upstream expires the session state but accepts requests on the dead session and never answers (per the MCP streamable-http spec it should reject them, e.g. HTTP 404, letting the client re-initialize transparently). Compare the bad-cloudId calls at 17:11 (clean sub-second error - the error path is fast) with the post-idle calls at 17:40+ (infinite silence).
• Dead pooled TCP connection: an intermediary silently dropped the idle flow and the runtime keeps writing requests into the dead socket - the same mechanism demonstrated at the runtime layer in #75572.

Either way, the client bug is the same and is the actionable part: after the 300s idle-timeout abort (17:45:20) and two user cancels, Claude Code does not tear down and re-initialize the transport - the next call reuses the dead session/connection and hangs identically (17:45:27, 17:48:31, 17:58:20). The Cleared connection cache for reconnection line appears only at process shutdown (18:09:51) in all three files, confirming the reconnect path exists but is never triggered mid-session by an abort.

Also note the write-safety consequence: an aborted createJiraIssue leaves the user unsure whether the write landed server-side (in our case it had not, but only a manual JQL search could confirm).

Suggested fixes

• Client (this repo): after an MCP idle-timeout abort or user cancel of an in-flight call, mark the transport suspect and re-initialize it before (or on) the next call - i.e., the mid-session equivalent of /mcp reconnect. This masks the upstream behavior regardless of which mechanism it is. Would also fix #60061, mitigate the MCP half of #75572, and satisfy #54136.
• Proxy (mcp-proxy.anthropic.com): if the stale-session mechanism is confirmed server-side, return an explicit session-expired error instead of silence.

Workarounds we use meanwhile

• CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT=30000 so a wedge costs 30s, not 5 min
• A cheap read probe (atlassianUserInfo) before any important write after an idle gap
• /mcp reconnect / process restart to unwedge