Claude Code 的缓存疑云需要证据说话

Anthropic Claude Code 仓库最近有一个 GitHub issue，报告了一个 Enterprise ZDR 认证工作区里疑似会话或缓存泄漏的情况。报告者说 Claude Code 突然问起 Minecraft 神庙的素材，随后又把整个会话总结成它正在建那座神庙。这个 issue 于 2026 年 7 月 4 日创建，我查看时已被标记为 bug，并打上了 area:security、area:core 和 platform:macos 标签。

我刻意保持审慎：这还不能证明存在跨账户泄漏，但也不是那种可以一句"聊天机器人抽风"就打发掉的 bug 报告。如果一个企业级编码代理能把无关任务的上下文塞进当前对话，该问的不是"这是不是幻觉"，而是"哪个边界出了问题，日志能不能证明"。

答案快照

问题	我的判断
报告了什么？	一位 Claude Code 用户描述，在 macOS 上使用 Claude Code 2.1.199 的 Enterprise ZDR 工作区里，出现了无关的 Minecraft 神庙上下文。
为什么严重？	报告者后来表示，在本地会话记录中搜索不到受影响会话之外的神庙或砖块相关内容，并且在同一 Enterprise 账户下的 Claude Mobile 也报告了类似情况。
什么还没有定论？	这个公开 issue 并不能证明存在服务端缓存泄漏、跨账户暴露或 ZDR 被突破。它只是一份公开报告加上后续评论，不是完整的事后分析报告。
我的核心观点	对企业 AI 代理来说，无法解释的上下文污染需要证据、隔离和事后排查路径，而不是凭感觉否定或恐慌。

这份报告有两种不同的风险形态

原始 issue 里有一个值得注意的前提。报告者说，他们是从一个跟实际任务无关的目录启动 Claude Code 的，因为那个目录里有一个 .claude 文件夹，装着他们需要的上下文。他们还说，之前上下文压缩后出现的目录混淆，可能就和这种启动方式有关。

这是一种看起来无害的解释：本地上下文、启动目录、记忆、压缩或会话记录处理在某台机器上出了错。这依然是真实的产品 bug，但性质跟服务端跨账户数据暴露完全不同。

更严重的情况，是排除本地因素后剩下的可能。评论区有人建议搜索本地 Claude Code 记录里的那些异常词汇，报告者回复说，在受影响的会话之外，本地找不到与神庙或砖块相关的内容——除了 Pygments 输出里一个无关的 minecraft.py 文件名。后来报告者又补充说，同一 Enterprise 账户下的 Claude Mobile 会话也出现了类似情况，并把 Sonnet 5 以及多分钟停顿后的首条回复列为可能的共同特征。

后面有评论者认为这就是普通的幻觉。这种可能性的确存在，但仅凭这一点并不能定论。真正需要回答的是：这些跑偏的内容到底来自本地状态、用户提供的上下文、产品层的摘要、模型行为，还是服务端的路由和缓存？

我不会把这当成最终结论，而是当成一个事件假设。区别很关键。假设要被保留、尽可能复现、跟客户端日志比对、跟服务端的请求标识比对，最后要么排除，要么升级处理。

ZDR 抬高了门槛

Anthropic 的 Claude Code 零数据保留文档说明，ZDR 面向符合条件的 Claude for Enterprise 账户开放；启用后，Claude Code 会话中的提示词和模型响应会实时处理，Anthropic 在返回响应后不会存储这些数据，法律要求或滥用处理除外。同一页面也仔细划定了范围：ZDR 覆盖的是 Claude for Enterprise 上的 Claude Code 推理，按组织启用，也不会自动覆盖产品的所有其他环节。

正是这个范围，让这份报告值得认真对待，又不必夸大。ZDR 的承诺一部分关于数据保留，但用户也会把它视作一种隔离承诺。如果用户在 ZDR 认证的工作流里看到了无关上下文，提供方需要解释这些污染内容到底来自本地客户端、本地记忆、会话记录、应用层、路由问题、模型缓存，还是别的地方。

Anthropic 的 Claude Code 数据使用页面还提到，Claude Code 客户端默认会在 ~/.claude/projects/ 下以明文存储会话记录 30 天，用于支持会话恢复。这不是什么隐藏的问题，而是文档里写明的行为。这也意味着，一次像样的调查应该先搞清楚可疑内容是不是本来就存在于本地，然后再判断它是不是一次服务端事件。

记忆功能有用，所以范围界定很关键

Claude Code 的 记忆文档描述了两种持久化上下文机制：CLAUDE.md 文件和自动记忆。文档也说明，这些机制是作为上下文加载的，而不是作为强制配置执行的。这个区别很重要——记忆是模型输入的一部分，不是一道硬性隔离机制。

文档列出了项目、用户、组织和本地指令的位置，并解释指令会在会话开始时被加载进上下文窗口。日常使用时，这很方便。但在事件调查里，这就是一张可能的污染点地图：是哪个目录启动了会话？加载了哪些文件？哪些记忆处于激活状态？压缩有没有总结到正确的项目？用户是不是在工作树、目录、账户或产品之间切换过？

我倾向于认为，很多看起来吓人的 AI 代理故障，最后都会被证明是普通的作用域 bug。但这不代表它们无害。一个上下文搞错了的编码代理，可能编辑错误的文件、在提示词里暴露敏感的本地内容，或者让用户误以为正在执行错误的任务。安全严重程度取决于错误的上下文从哪来、又去了哪。

这不是第一次公开的缓存类指控

此前 Claude Code 的另一个 GitHub issue #26330，曾指控上下文压缩和一次长时间的子代理操作之后出现了提示缓存交叉污染。那个 issue 最终以"不计划修复"关闭，我也不会拿它来证明新报告有同样的原因。之所以提到它，是因为这类担忧并不新鲜：用户有时会看到像是从无关对话延续过来的输出，然后很难证明源头到底是本地状态、模型行为、提示缓存，还是别的东西。

这个问题在公开层面让人头疼，因为最有决定性的证据往往不在公开范围内。用户能查的是本地记录和截图；提供方能查的是路由、缓存键、产品层日志、保留控制和请求元数据。一个严肃的结论需要双方配合。

这也是代理安全领域的讨论有价值的地方。Simon Willison 的 "致命三合一"框架讨论的是使用工具的 AI 系统中的私有数据、不可信内容和外部通信。这个 GitHub issue 表面上看不是一个提示注入案例，但它指向同一个更大的教训：一旦 AI 代理能够访问私有项目上下文和工具，边界就必须被工程化设计和审计，而不是想当然。

产品层面的启示

Claude Code 的 安全文档提到，该工具使用只读默认值、权限提示、沙箱选项等保护措施。这些控制很重要。但 Anthropic 的 沙箱环境文档也说得很清楚：沙箱可以缩小本地的爆炸半径，但不会改变哪些提示词和文件会被发送给模型提供方。本地安全和模型侧的隔离有关联，但不能互相替代。

这就是企业场景下的实际启示。采用代理编码工具的团队，应该跟踪哪些账户处于活跃状态、哪些组织启用了 ZDR、会话记录存放在哪里、哪些记忆和指令文件会被加载、哪些目录被信任，以及什么内容会被发送到上游。这些看似无聊的控制，才是让一个奇怪回答能变成一次调查、而不是一场口水仗的关键。

我也希望提供方能把这些事做得更简单。如果用户报告了异常上下文，客户端应该能导出一份干净的证据包：会话 ID、模型、组织、本地记录路径、加载的记忆文件、压缩事件、在安全范围内可暴露的缓存相关元数据，以及企业账户的明确支持升级路径。一个潜在的隔离 bug，不该靠公开 GitHub issue 来做事件响应。

我的结论

我不知道 issue #74066 到底是本地上下文 bug、应用层 bug、模型缓存问题，还是最终虚惊一场。公开的证据还不够下结论。但这份报告足够具体，产品面也足够敏感，我会把它当作一个待排查的事件来对待，直到被证明不是。

对于普通聊天产品，一个奇怪的离题回答可能只是个趣闻。但对于运行在 ZDR 承诺下的企业编码代理，无法解释的上下文污染就是一次信任边界事件。答案需要证据：本地加载了什么、发送了什么、缓存了什么、保留了什么，以及为什么错误的上下文会出现。否则，团队永远搞不清他们自认为已隔离的工作，到底从哪里开始、在哪里结束。