You spawn five sub-agents in one turn, each hammering the same Jira MCP server with its own list of tickets. Everything “succeeds.” The agent reports the edits landed. You move on. Except — according to a fresh bug report — a meaningful fraction of those responses described a different ticket than the one the agent actually edited.
The issue
Issue #77039 (filed Jul 13, 2026, labeled bug, has repro, area:mcp, area:agents, area:cowork) reports that when multiple sub-agents call tools on the same connected MCP server concurrently, some responses come back with the key and content of an unrelated entity. Not an error — a fully-formed, schema-valid response for the wrong target.
The reporter verified the underlying read/write landed on the correct entity in every checked case. The danger is in the payload handed back to the calling agent: a getJiraIssue for ticket A returned ticket B’s data, and a editJiraIssue confirmation described a completely different issue than the one that was actually edited. With 5+ parallel sub-agents, roughly 30–50% of responses in some sub-agents mismatched. It is marked a regression against Claude 1.20186.1.
Are you affected?
If you use the Agent/Task tool with concurrent sub-agents hitting one MCP server, you are in the blast radius. Quick checks:
# Which version are you running? Regressed on 1.20186.1
claude --version
# Are you spawning parallel sub-agents against a shared MCP server?
grep -Rni "mcpServers" ~/.claude.json ~/.claude/settings.json 2>/dev/null
# After any MCP write, immediately re-read the target and compare IDs
# If the response's reported ID != requested ID, you've hit #77039The fix
- Don’t fan out >1 concurrent sub-agent against a single stateful MCP server until a fix ships.
- After every write through MCP, re-fetch and assert the returned entity ID matches the requested one before trusting downstream logic.
- For Jira/linear-style connectors, add a post-write verification step that fails the turn on ID mismatch.
- Downgrade to the last known-good Claude Code build if parallel MCP workflows are critical to you.
Why it happened
The symptom points to a response-correlation bug: with many in-flight tool calls against one server, the response is being matched to the wrong request/context. The underlying operation is correct (confirmed by immediate re-reads), so the fault is in how concurrent responses are routed back to their originating sub-agent — a classic race in multiplexed request/response handling.
FAQ
Q: Is my data actually being written to the wrong place? The reporter found the actual operations landed correctly; only the returned confirmation payload was mismatched. The risk is logic that trusts the response (e.g., “edit succeeded on ticket X”) acting on the wrong ID.
Q: Does this affect single-agent, sequential MCP use? Not in the repro — it requires concurrent calls from multiple sub-agents against the same server. Sequential use looked safe.
Q: Which MCP servers are vulnerable? Nothing suggests it’s Jira-specific. Any shared MCP server with ID-keyed read/write tools is a candidate.
Running multiple AI agents? Save on API costs and subscriptions at aiFiesta.