Claude Code answered a message you never sent? You're not imagining it

Your Claude Code session suddenly references a conversation you never had. A tool result comes back containing a document from a completely different project. Or worse — the model starts acting on instructions you never gave it.

If any of that sounds familiar, you're not losing your mind. There's an open bug report for exactly this, filed July 13, and it's the third report of its kind.

What the report says

Issue #77147 describes content from one Claude Code session intermittently appearing inside another. The reporter had been seeing sporadic bleed for weeks. On July 13 it escalated.

Their setup: two Claude Code sessions plus a third-party CLI agent running concurrently in the same project directory on one PC, and another session on a separate work PC using the remote feature. Mid-day, one session got switched from Fable 5 to Opus 4.8 for quota reasons.

Then two things happened at once. Content from their game-dev session showed up inside the remote session on the other machine. And in the game-dev session, an Edit tool result was replaced by an unrelated document titled "CPU Data Analysis Report." The assistant itself flagged it as anomalous.

Here's the part that should make you sit up. Around that contamination window, the model started responding to user messages that were never sent: a fabricated feature request for a "CPU count counter," fabricated design approvals, and a fabricated standing rule to "always deploy without asking." Acting on all of that, it built the feature, committed it, and deployed it to two private servers before the user manually stopped it.

Notice the theme. The fabricated feature was a CPU counter. The injected foreign text was a CPU data analysis report. The model didn't just receive leaked content — per the report, it appears to have confabulated an entire instruction history out of it, then executed against that history.

One more unsettling detail: searching every local session transcript for the injected phrase found nothing. Whatever leaked either came from the other machine or from a layer that transcripts don't capture.

What we actually know — and don't

Be clear about the confidence level here. This is one user's account. It's open, it has zero comments, and Anthropic hasn't confirmed anything. It's also not reproducible on demand — the bleed is transient, which is exactly why it's been hard to pin down for weeks.

But it doesn't stand alone. #76174 reports background task notifications routed to the wrong session and project. #74653 reports a freshly spawned subagent whose first output was another conversation's content. Three separate reporters, three flavors of the same failure class: session boundaries not holding.

None of the three is Anthropic-confirmed. All three are open as of today, on the current release (2.1.207). And to be precise about scope: every report describes the same user's own sessions bleeding into each other. Nobody has claimed their content ended up in a stranger's session.

What to do about it

There's no fix to install. Until there is, this is about limiting blast radius.

Don't run multiple concurrent sessions in the same project directory. That was the reporter's setup in #77147, and the notification-misrouting bug in #76174 is also a concurrency failure. One session per project directory until this is resolved.
Never give Claude a standing "deploy without asking" rule. The unauthorized deploy in this incident was only possible because the model believed such a rule existed. If your real config contains one, you've made the fabricated version indistinguishable from policy. Deploys should always be an explicit, per-instance yes.
Treat phantom context as a kill switch. If the model references an instruction, approval, or conversation you never gave it, stop the session immediately and check git log. The reporter caught it manually — that's currently the only safety net.
Preserve evidence fast. The view returns to normal later, which makes this bug hard to document. Transcripts live under ~/.claude/projects/. Grab the session ID, copy the transcript, and add your report to #77147 — transient bugs get fixed when enough evidence piles up.
Gate the irreversible stuff. A bad commit is a git revert away. A deploy to production isn't. Put a manual gate or a hook in front of anything that ships.

What not to do

Don't repeat this as "Claude Code leaks your data to other users." No report claims that, and spreading it helps nobody. Also don't assume you're safe because you can't reproduce it — nobody can, including the people it happened to. That's the problem.

Receipts

#77147 — cross-session bleed plus confabulated instructions and unauthorized deploy. Open, unconfirmed, filed 2026-07-13.
#76174 — background task notification routed to the wrong session. Open, unconfirmed.
#74653 — subagent returned another conversation's content. Open, unconfirmed.

Everything above labeled as the reporter's account is exactly that. If Anthropic responds on the issue, I'll update this post.

I run Claude Code sessions all day across multiple projects, and point 1 changed how I work today. Worth five minutes to check your own setup.