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.
What this looks like in practice
Say you have three sub-agents each editing a different Jira ticket through the same MCP server. Agent A requests ticket PROJ-101, Agent B requests PROJ-202, Agent C requests PROJ-303. Each one issues an editJiraIssue call. When the responses come back, Agent A might receive the confirmation payload for PROJ-202 instead of PROJ-101. The actual edit on the Jira side landed correctly on PROJ-101 — but the agent now believes it edited the wrong ticket. Any downstream logic that uses the response (logging, chaining edits, updating a summary doc) will operate on incorrect assumptions.
This is especially dangerous in automated pipelines. If your Claude Code workflow runs a triage agent that reads a ticket, edits it, and then posts a summary comment based on the response payload, a mismatched response means the summary comment references the wrong ticket entirely — a silent data-quality failure that’s hard to catch without explicit ID assertions.
Detection pattern for any MCP server
The mismatch is only dangerous when you trust the response without verifying. Here’s a portable pattern you can wrap around any MCP tool call:
# After any write, immediately re-read and compare
# 1. Issue the write (e.g., editJiraIssue for PROJ-101)
# 2. Issue a read for the same ID (getJiraIssue for PROJ-101)
# 3. Assert the read-back matches what you expected
# Quick shell check: if your MCP server exposes a CLI
# read-after-write verification script:
EXPECTED_ID="PROJ-101"
RETURNED_ID=$(your-mcp-cli get-issue $EXPECTED_ID | jq -r '.id')
if [ "$RETURNED_ID" != "$EXPECTED_ID" ]; then
echo "MISMATCH: requested $EXPECTED_ID, got $RETURNED_ID"
echo "Likely hit claude-code#77039 — do not trust downstream logic"
fiWhy 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.