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

Resolved 💬 1 comment Opened Jul 13, 2026 by cameron-bales-telus-health Closed Jul 13, 2026

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

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.20186.1 (df1d8a) 2026-07-10T21:55:12.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗