MCP tool responses intermittently return a different tool call's data under concurrent parallel sub-agent load

Open 💬 0 comments Opened Jul 9, 2026 by cameron-bales-telus-health

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?

When multiple sub-agents each independently call tools on the same connected MCP server concurrently, a fraction of tool call responses come back containing the key and content of a different, unrelated entity than the one requested — not an error, a fully-formed, schema-valid response, just for the wrong target. Reproduced with an Atlassian (Jira) MCP connector: requesting one issue's data returned another issue's data, and a write operation's confirmation response described a completely different issue than the one actually edited. Verified by immediately re-fetching each target afterward: the underlying read/write itself landed on the correct entity in every checked case, but the response payload handed back to the calling agent did not match the request.

What Should Happen?

Each tool call's response should always correspond to the exact request that produced it, regardless of how many other tool calls are in flight concurrently from other sub-agent sessions against the same connected server.

Error Messages/Logs

Steps to Reproduce

  1. In Cowork, connect an MCP server with a "read" and a "write" tool keyed by a unique entity ID (reproduced with an Atlassian/Jira connector's getJiraIssue / editJiraIssue, but nothing suggests it's Jira-specific).
  2. Use the Agent/Task tool to spawn 5+ parallel sub-agents in a single turn, each with a distinct, non-overlapping list of entity IDs to process.
  3. Have each sub-agent independently call the read tool, then the write tool, for each ID in its list, with no explicit rate limiting or sequencing between sub-agents.
  4. Compare each response's own reported ID/key against the ID/key actually requested.
  5. Observe that a meaningful fraction of responses (~30-50% in some sub-agents) report a different ID/key and content than requested, even though the underlying operation completed correctly (confirmed via an immediate follow-up read).

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.202 (sandbox-reported); latest available at time of filing: 2.1.204

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Reproduced with 7 parallel sub-agents against an Atlassian (Jira Cloud) MCP connector, ~35-55 tool calls per sub-agent over 4-9 minutes. Every sub-agent adopted an ad hoc mitigation (re-fetch by key after every write, verify before trusting) and confirmed zero cross-entity writes occurred — the bug is confined to response-payload correlation, not the underlying operation.

Environment note: encountered in Cowork (the Claude desktop app), not the CLI terminal — so the Terminal/Shell field above isn't strictly applicable. The Claude Code version 2.1.202 is what the Cowork sandbox reported; 2.1.204 was the latest available at time of filing.

Searched existing issues before filing — three related-but-different issues turned up (#45880, #68375, #20632), but none describe a well-formed response silently containing another call's data, so this appears to be a new report.

View original on GitHub ↗