Claude Code's Cache Scare Needs Receipts

A new GitHub issue in the Anthropic Claude Code repository reports apparent session or cache leakage in an Enterprise ZDR-authenticated workspace. The reporter says Claude Code suddenly asked about materials for a Minecraft temple and then recapped the session as if it were building that temple. The issue was opened on July 4, 2026, and was labeled as a bug with area:security, area:core, and platform:macos when I inspected it.

My reaction is deliberately narrow: this is not proof of a cross-account leak, but it is also not the kind of bug report I would wave away as chatbot weirdness. If an enterprise coding agent can put unrelated task context into the working conversation, the responsible question is not "Was it hallucination?" The responsible question is "Which boundary failed, and can we prove it from logs?"

Answer Snapshot

Question	My read
What was reported?	A Claude Code user described unrelated Minecraft-temple context appearing in an Enterprise ZDR workspace while using Claude Code version 2.1.199 on macOS.
What makes it serious?	The reporter later said local transcript searches did not find the relevant temple or brick terms outside the affected session, and also reported a separate Claude Mobile case on the same Enterprise account.
What is not established?	The public issue does not prove a server-side cache leak, cross-account exposure, or a ZDR breach. It is a public report plus follow-up comments, not a completed incident report.
My thesis	For enterprise AI agents, unexplained context contamination needs evidence, containment, and a postmortem path, not vibes-based dismissal or panic.

The Report Has Two Different Risk Shapes

The original issue includes a caveat that matters. The reporter says they launched Claude Code from a directory unrelated to the actual task because that launch directory had a .claude directory with context they needed. They also say an earlier instance of directory confusion after compaction was probably caused by that setup.

That is the benign-looking explanation: local context, launch directory, memory, compaction, or transcript handling got confused on one machine. It would still be a real product bug, but it would not be the same thing as server-side cross-account data exposure.

The more serious shape is what remains after local evidence is checked. In the comments, one person suggested searching local Claude Code transcripts for the stray terms. The reporter replied that they found no relevant local match for the temple or brick context outside the affected session, aside from an unrelated minecraft.py filename in Pygments output. Later, the reporter added that a similar thing happened in a Claude Mobile session on the same Enterprise account, and pointed to Sonnet 5 plus a first response after a multi-minute pause as a possible common pattern.

A later commenter suggested plain hallucination as the explanation. That is possible, but it is not decisive by itself. The evidence question remains whether the off-topic material can be traced to local state, user-provided context, a product-layer summary, model behavior, or service-side routing and cache state.

I would not turn that into a root cause. I would turn it into an incident hypothesis. The difference matters. A hypothesis gets preserved, reproduced if possible, compared against client logs, compared against server-side request identifiers, and either killed or escalated.

ZDR Raises The Bar

Anthropic's Claude Code zero data retention documentation says ZDR is available to qualified Claude for Enterprise accounts and that, when enabled, prompts and model responses from Claude Code sessions are processed in real time and not stored by Anthropic after the response is returned, except where required for law or misuse handling. The same page is careful about scope: ZDR covers Claude Code inference on Claude for Enterprise, is enabled per organization, and does not automatically apply to everything around the product.

That scope is exactly why this report is worth taking seriously without exaggerating it. A ZDR promise is partly about retention, but users also experience it as an isolation promise. If a user sees unrelated context appear in a ZDR-authenticated workflow, the company needs to explain whether the contamination came from the local client, local memory, a transcript, the app layer, a routing issue, a model cache, or something else.

Anthropic's Claude Code data-usage page also says Claude Code clients store session transcripts locally in plaintext under ~/.claude/projects/ for 30 days by default to enable session resumption. That is not a hidden scandal. It is documented behavior. It also means a good investigation should first determine whether the suspicious content already existed locally before calling it a service-side event.

Memory Is Useful, So Scope Matters

Claude Code's memory documentation describes two persistent context mechanisms: CLAUDE.md files and auto memory. It also says those mechanisms are loaded as context rather than enforced configuration. That distinction matters because it means memory is part of the model's input surface, not a hard isolation mechanism.

The docs list project, user, organization, and local instruction locations, and explain that instructions are loaded into the context window at the start of a session. In ordinary use, that is convenient. In an incident investigation, it becomes a map of possible contamination points. Which directory launched the session? Which files were loaded? Which memories were active? Did compaction summarize the right project? Did the user move between worktrees, directories, accounts, or products?

My bias is that many alarming AI-agent failures will turn out to be mundane scope bugs. That does not make them harmless. A coding agent with the wrong context can edit the wrong files, reveal sensitive local material inside a prompt, or make the user believe the wrong task is being done. The security severity depends on where the wrong context came from and where it went next.

This Is Not The First Public Cache-Shaped Claim

A prior Claude Code GitHub issue, #26330, alleged prompt-cache cross-contamination after context compression and a long subagent operation. That issue was closed as not planned, and I am not using it as proof that the new report has the same cause. I bring it up because it shows the shape of concern is not new: users can sometimes observe outputs that look like continuations from unrelated conversations, then struggle to prove whether the source is local state, model behavior, prompt cache, or something else.

The public part of this problem is frustrating because the most decisive evidence is not public. Users can inspect local transcripts and screenshots. Providers can inspect routing, cache keys, product-layer logs, retention controls, and request metadata. A serious answer requires both sides.

That is also where agent-security writing is useful. Simon Willison's "lethal trifecta" framing is about private data, untrusted content, and external communication in tool-using AI systems. This GitHub issue is not, on its face, a prompt-injection story. But it lives in the same larger lesson: once an AI agent has access to private project context and tools, boundaries have to be engineered and audited, not merely assumed.

The Product Lesson

Claude Code's security docs say the tool uses read-only defaults, permission prompts, sandboxing options, and other safeguards. Those controls matter. But Anthropic's sandbox-environment docs also make a useful point: isolation can reduce local blast radius, but it does not change what prompts and read files are sent to the model provider. Local safety and model-side isolation are related, but they are not substitutes for each other.

That is the practical enterprise takeaway. Teams adopting agentic coding tools should track which account is active, which organization has ZDR enabled, where transcripts live, which memories and instruction files load, which directories are trusted, and what gets sent upstream. The boring controls are the controls that let a strange answer become an investigation instead of a debate.

I would also want providers to make this easier. If a user reports alien context, the client should expose a clean evidence bundle: session ID, model, org, local transcript path, loaded memory files, compaction events, cache-relevant metadata where safe to expose, and a clear support escalation path for enterprise accounts. A public GitHub issue should not be the best incident-response interface for a potential isolation bug.

My Bottom Line

I do not know whether issue #74066 is a local context bug, an app-layer bug, a model-cache problem, or an eventual false alarm. The public evidence is not enough to decide. But the report is specific enough, and the product surface is sensitive enough, that I would treat it as an incident candidate until proven otherwise.

For consumer chat, a weird off-topic answer can be a curiosity. For an enterprise coding agent running under a ZDR expectation, unexplained context contamination is a trust-boundary event. The answer should be receipts: what was loaded locally, what was sent, what was cached, what was retained, and why the wrong context appeared. Anything less leaves teams guessing where their supposedly isolated work actually begins and ends.