Before you start
Affected area
Not sure / other
Skill name (if it's about a skill)
No response
What happened?
Calling createJiraIssue to create a new Jira issue returned a ~131KB response body. The oversized payload wasn't corrupted or garbled — it was a complete, well-formed JSON representation of a different, pre-existing, unrelated issue in the same project (a closed Epic), including that Epic's own issue links to yet another unrelated ticket.
Trusting the key found in that response, a follow-up createIssueLink call was made — which succeeded, adding a link to the real, unrelated, closed Epic that had nothing to do with the original request. The actual issue created by the original request did exist, with all fields correct, but under a completely different key, discoverable only via a separate JQL search by summary text.
What did you expect instead?
createJiraIssue should return a small response containing only the newly created issue's own fields (id, key, self — a few hundred bytes), and any follow-up action using that key should act on the issue that was actually just created, not an unrelated one.
Steps to reproduce
Not a clean deterministic repro — this occurred twice, but the conditions were:
Have multiple concurrent Claude Code sessions open, all authenticated through the same Atlassian MCP connector/OAuth session.
In one session, call createJiraIssue to create a new issue.
In the other session, query jira to find existing tickets concurrently. (searchJiraIssuesUsingJql)
Observe an anomalously large response body.
Inspect it: it contains a different, pre-existing issue's full data instead of (or alongside) the new issue's confirmation.
Separately confirm the real created issue exists, under a different key, by searching for its summary text.
Suspected trigger condition is concurrency — two or more sessions hitting the connector close together in time — rather than sequential reuse within one session.
MCP client and version (if it's relevant)
Claude Desktop (claude-desktop entrypoint), Claude Code 2.1.168, Agent SDK 0.3.209
Anything else?
Distinction from #23 ("MCP server uses cached OAuth token from wrong Atlassian account"): related shape of bug, different mechanism. #23 was a stale OAuth token read from a local on-disk cache (~/.mcp-auth/), closed as client-side (mcp-remote) behavior. This is not a stale token — it's a live response body (a full, current, valid issue JSON payload) delivered to the wrong concurrent request, which points at request/response handling, not a local file cache.
Also related: #132 (createJiraIssue creates duplicate issues on every call) — same tool, different but adjacent reliability problem, also open and unaddressed.
Impact: this is worse than an outright failure. A silent identity mismatch means an agent (or human) trusting the returned key mutates unrelated data with no error surfaced.
Before you start
Affected area
Not sure / other
Skill name (if it's about a skill)
No response
What happened?
Calling createJiraIssue to create a new Jira issue returned a ~131KB response body. The oversized payload wasn't corrupted or garbled — it was a complete, well-formed JSON representation of a different, pre-existing, unrelated issue in the same project (a closed Epic), including that Epic's own issue links to yet another unrelated ticket.
Trusting the key found in that response, a follow-up createIssueLink call was made — which succeeded, adding a link to the real, unrelated, closed Epic that had nothing to do with the original request. The actual issue created by the original request did exist, with all fields correct, but under a completely different key, discoverable only via a separate JQL search by summary text.
What did you expect instead?
createJiraIssue should return a small response containing only the newly created issue's own fields (id, key, self — a few hundred bytes), and any follow-up action using that key should act on the issue that was actually just created, not an unrelated one.
Steps to reproduce
Not a clean deterministic repro — this occurred twice, but the conditions were:
Have multiple concurrent Claude Code sessions open, all authenticated through the same Atlassian MCP connector/OAuth session.
In one session, call createJiraIssue to create a new issue.
In the other session, query jira to find existing tickets concurrently. (searchJiraIssuesUsingJql)
Observe an anomalously large response body.
Inspect it: it contains a different, pre-existing issue's full data instead of (or alongside) the new issue's confirmation.
Separately confirm the real created issue exists, under a different key, by searching for its summary text.
Suspected trigger condition is concurrency — two or more sessions hitting the connector close together in time — rather than sequential reuse within one session.
MCP client and version (if it's relevant)
Claude Desktop (claude-desktop entrypoint), Claude Code 2.1.168, Agent SDK 0.3.209
Anything else?
Distinction from #23 ("MCP server uses cached OAuth token from wrong Atlassian account"): related shape of bug, different mechanism. #23 was a stale OAuth token read from a local on-disk cache (~/.mcp-auth/), closed as client-side (mcp-remote) behavior. This is not a stale token — it's a live response body (a full, current, valid issue JSON payload) delivered to the wrong concurrent request, which points at request/response handling, not a local file cache.
Also related: #132 (createJiraIssue creates duplicate issues on every call) — same tool, different but adjacent reliability problem, also open and unaddressed.
Impact: this is worse than an outright failure. A silent identity mismatch means an agent (or human) trusting the returned key mutates unrelated data with no error surfaced.