Remote MCP connector: response delivered to wrong concurrent tool call (cross-subagent payload misdelivery); rightful caller times out after 180s

Summary

When multiple subagents in one Claude Code session make concurrent tool calls to the same remote (claude.ai) MCP connector, a response payload can be delivered as the result of a different pending tool call. The rightful caller then fails with Tool call timed out waiting for server response. after 180s and typically re-issues the request. The wrong recipient receives a completely valid-looking payload for a URL/query it never asked for — no error signal whatsoever, i.e. silent data corruption for any pipeline consuming tool output.

This was initially suspected to be a cache-key collision in the "large tool output saved to file" (tool-results/mcp-*.txt) mechanism. Local forensics exonerates the offload writer and points to request/response correlation in the connector transport chain (shared MCP client in the harness ↔ claude.ai connector gateway ↔ hosted MCP server). Which of those three layers misroutes cannot be determined from client-side logs (no JSON-RPC frame ids are logged).

Environment

• Claude Code desktop app (macOS, Darwin 27.0.0), app version 1.24012.9, 2026-08-03
• Remote MCP connector: Bright Data (claude.ai connector, server key 57df35a1-0660-4347-b8cf-697e66d1ab46), tools scrape_as_markdown, search_engine, ask_brightdata_assistant
• Session 9949d5ea-3d12-42ce-84d2-d1f6e586965e running parallel subagents:
• agent-af290a1049e23b1f9 ("donor"): mass Amazon-SERP sweep, bursts of 3 concurrent scrape_as_markdown calls
• agent-a76282493b27fbcc2 ("victim"): off-Amazon collection (Google SERP via search_engine, reddit, walmart.com, bodyglide.com)
• All timestamps below are UTC (2026-08-03T01:xx), from session transcripts (~/.claude/projects/<proj>/<session>/subagents/*.jsonl) and connector log (~/Library/Caches/claude-cli-nodejs/<proj>/mcp-logs-57df35a1-*/2026-08-03T01-11-05-805Z.jsonl).

Confirmed misdeliveries (4/4 with matched "starved" sibling)

Every wrong payload the victim received corresponds exactly to a request the donor had in flight seconds earlier — and that donor call then timed out at 180s and had to be re-issued:

| # | Donor burst (in flight) | Victim call (2–8 s later) | Victim receives | Starved donor call |
|---|---|---|---|---|
| 1 | 01:13:44 amazon.com/s?k=blister+stick p1/p2/p3 | 01:13:52 search_engine "site:reddit.com blister stick running" (google) | 01:14:02, 426,555 ch, Amazon "blister stick" SERP → ...-1785719642255.txt | p2 times out 01:16:51; re-requested 01:25:00 (times out again, see #2), succeeds 3rd try 01:28:53 |
| 2 | 01:25:00–02 blister+stick p2, blister+sticks p1/p2/p3 | 01:25:04 ask_brightdata_assistant (question about scraping a reddit thread) | 01:25:14, 388,656 ch, Amazon "blister stick" SERP → ...-1785720314616.txt | blister+stick p2 times out 01:28:00; succeeds on retry 01:28:45→01:28:53 (385,084 ch) |
| 3 | 01:36:02 foot+glide p1/p2/p3 | 01:36:07 walmart.com/search?q=blister%20stick | 01:36:13, 284,247 ch, Amazon "foot glide" SERP → ...-1785720973106.txt | p1 times out 01:39:02; re-requested 01:39:43, succeeds 01:39:50 with 284,286 ch (fresh render, 39 ch different) |
| 4 | 01:40:27–28 anti+chafe+stick+feet p1/p2/p3 | 01:40:32 bodyglide.com/product/foot-glide/ | 01:40:48, 307,177 ch, Amazon "anti chafe stick feet" SERP → ...-1785721247997.txt | p1 times out 01:43:27; re-requested 01:44:09, succeeds 01:44:22 (286,605 ch) |

Connector log shows 9 Tool 'X' failed after 180s: Tool call timed out waiting for server response. events in this window (01:16:51, 01:19:22, 01:24:14, 01:25:17, 01:28:00, 01:31:14, 01:39:02, 01:43:27, 01:48:37). 4 are traced above; the rest are either genuine upstream timeouts or misdeliveries whose recipient I could not identify from files (a stolen payload delivered inline leaves no file to audit).

Historical scale: local mcp-logs-57df35a1-* across projects contain ~115 such 180s-timeout events (95 in this project alone, spanning at least Jul 30–Aug 3). Each one is a potential misdelivery twin. No other connector's logs (e.g. SellerSprite c48d608f-*) contain this timeout — plausibly because only Bright Data returns multi-hundred-KB responses with 7–25 s latency, maximizing the in-flight overlap window.

Why it is NOT the large-output offload writer

The "exceeds maximum allowed tokens → saved to tool-results/mcp-<server>-<tool>-<epochms>.txt" mechanism writes exactly the bytes it received:

• The char count in the notice (Error: result (284,247 characters across 2,571 lines) exceeds maximum allowed tokens...) equals the written file size byte-for-byte in all 4 cases → corruption pre-dates the offload step.
• 52 of 56 offloaded files in the session match their requests exactly (including 8 amazon.co.uk/.ca/.de SERPs requested by third subagents).
• The 4 wrong payloads are byte-unique across all 219 tool-result files on disk (payload hashed after stripping the per-delivery security-notice wrapper). They are not replays of any previously stored response.

Why it is NOT an upstream content/cache substitution ("stale cache" theory)

The wrong payloads are correct, fresh answers to the sibling's URL issued seconds earlier — not stale content: in case 3 the starved sibling's retry 3.5 min later returned a near-identical but distinct render of the same page (284,286 vs 284,247 ch). The upstream scraper did its job; the response was handed to the wrong waiter. (A server-side JSON-RPC id mix-up cannot be excluded from client-side data alone — see next section.)

Where to look

Client-side logs contain no frame-level JSON-RPC ids, so I cannot tell which layer mismatched:

1. Harness shared MCP client: request-id allocation / response correlation when multiple subagents issue concurrent calls over one connector session (id collision? pending-map rebuild on SSE reconnect matching a late big response to a newer pending request?).
2. claude.ai connector gateway: response routing across concurrently proxied calls of one session.
3. Hosted MCP server (Bright Data): emitting a response with the wrong request id under concurrency. If Anthropic-side traces show the wire frame already carried the wrong id, loop in Bright Data.

Suggestion regardless of root cause: log JSON-RPC request/response ids in mcp-logs-* debug entries so field diagnosis of correlation bugs becomes possible.

Reproduction sketch

1. One session, two parallel subagents, same remote connector (Bright Data via claude.ai connector).
2. Agent A bursts 3 concurrent scrape_as_markdown calls for slow, large pages (Amazon SERPs, 300–470 KB, 7–25 s latency).
3. Agent B issues any call to the same connector 2–8 s later.
4. Observed failure rate: 4 misdeliveries per ~120 calls in one morning. Signature: B's result arrives suspiciously fast with A's content; one of A's calls later fails with failed after 180s and is re-issued.

Detection heuristic for affected users: any Tool call timed out waiting for server response. on a remote connector should be treated as a flag that another concurrent call in the same session may have received the timed-out call's payload. Verify large tool outputs against the requested URL/query (e.g. grep the saved file for the expected domain/keyword) before trusting them.

Impact

• Silent wrong-data injection into agent pipelines (the substituted payload is a plausible, well-formed page — an agent that doesn't cross-check domain/keywords will happily "analyze" it).
• Availability: rightful callers burn 180 s each, then re-fetch (double upstream cost).
• Data-boundary adjacency: all observed misdeliveries stayed within one user/session (own concurrent requests). But if the correlation bug lives server-side, the blast radius question (cross-session/cross-tenant) deserves a check by whoever owns that layer. No evidence of cross-tenant delivery in this data set.

Evidence files (available on request)

• Session transcripts: ~/.claude/projects/-Users-zhuangtongxue-Documents-Claude/9949d5ea-3d12-42ce-84d2-d1f6e586965e/subagents/agent-{af290a1049e23b1f9,a76282493b27fbcc2}.jsonl
• Misdelivered payload files: .../9949d5ea-.../tool-results/mcp-57df35a1-...-{1785719642255,1785720314616,1785720973106,1785721247997}.txt
• Connector log: ~/Library/Caches/claude-cli-nodejs/-Users-zhuangtongxue-Documents-Claude/mcp-logs-57df35a1-0660-4347-b8cf-697e66d1ab46/2026-08-03T01-11-05-805Z.jsonl

(No existing issue found searching anthropics/claude-code for "tool call timed out" + misdelivery/mismatch phrasings; apologies if this duplicates one filed under different wording.)