GitHub上anthropics/claude-code仓库这几天多了一条编号为#74066的issue,标题不轻:「工作区实例或消费者账户之间可能存在会话/缓存泄露」。提交者是一名企业ZDR(零数据留存)工作区用户,他说Claude Code在一次对话里突然主动问他"想用什么砖块搭Minecraft神庙",还在任务小结里一本正经地写"正在建造Minecraft神庙"——问题是,他压根没让Agent干这活儿。
标题里那个"Potential"(潜在)很关键。这条issue提交于2026年7月4日,目前只是一名用户的疑似报告,Anthropic官方还没有公开回应或确认。但把它放进Claude Code过去一年的issue历史里看,这更像是一连串账户隔离缺陷积累到一定量之后,终于撞上了"跨账户内容泄露"这条更严重的红线。
一次异常对话,一个企业最怕听到的词
报告人自己也说清楚了场景:他在一个目录里启动会话是因为那里有需要的.claude上下文,实际干活却在另一个目录,期间还触发过一次/compact压缩对话。他承认"提前污染"那部分是自己配置导致的,但Minecraft神庙这段"完全是另一回事"。
企业ZDR的卖点就是承诺数据不留存、不跨租户,一旦真的验证是服务器端跨账户泄露,影响的就不只是这一个用户的尴尬,而是企业客户签合规协议时最看重的那条底线。
这不是孤例,是一年攒下的旧账
翻一遍Claude Code的issue记录会发现,"账户切不干净"这件事早就有迹可循:#28585反映VS Code扩展换账户后依然粘在旧账户上,#24963请求原生支持多账户/多profile,#53728报告ANTHROPIC_API_KEY环境变量会静默覆盖Max订阅认证,用户以为登录对了实际用错了模式。第三方仓库cc-switch的#1435,则指向~/.claude/auth.json的认证状态持久化冲突。
社区应对的方式,是自己动手补丁:用CLAUDE_CONFIG_DIR环境变量隔离配置目录,用git worktree拆分工作区,或者干脆{"title": "Claude Code疑似泄露他人会话：一个Minecraft提问，掀出账户隔离旧疾", "en_title": "claude-code-session-leak-issue-74066", "summary": "一名企业ZDR工作区用户发现Claude Code突然聊起“建Minecraft神庙”，怀疑会话在账户或工作区间串了线；GitHub issue #74066本身信息稀薄、官方未表态，但连上过去一年多起账户切换、认证粘滞的老issue看，这更像是多账户架构长期缺隔离机制的一次集中暴露，而非孤立事故。", "event": "Anthropic | Claude Code被曝疑似跨workspace/账户会话泄露", "conclusion": "篱笆不牢，鸡犬难安——隔离若靠用户自己拼凑，迟早撞上更贵的账。", "image_prompt": "Close-up shot of a laptop screen displaying a terminal window filled with code and a highlighted security warning message, dim office lighting, shallow depth of field, realistic photography, developer desk with coffee mug and notebook nearby, moody tech workspace atmosphere, no visible logos, journalistic photo style", "images": []}
===XNEWS-CONTENT-BEGIN===
2026年7月4日，GitHub上anthropics/claude-code仓库多了一条标题扎眼的issue：#74066，标题是「Potential session/cache leakage between workspace instances or consumer accounts」。提交者是一名企业ZDR（零数据保留）工作区用户，他的Claude Code agent突然开始追问他“Minecraft神庙想用哪种砖块”，还在任务小结里自信宣称自己正在建一座Minecraft神庙——问题是，他压根没让它干这个。
这条issue本身信息量不大，页面只留下标题、一张被签名保护的截图，没有官方回应，也没人证实这究竟是不是真的泄露。但把它放进Claude Code过去一年的issue列表里对照，画风就变了：这已经不是第一次有人发现账户和工作区之间的边界不太牢靠。
神庙从哪来的，没人能马上说清
提交者的场景有点绕：他在目录A启动会话（那里有他需要的.claude上下文），实际工作却在目录B，中途还发生过一次/compact压缩对话。他猜测要么是同事在拿token建神庙玩，要么更严重——消费者账户的内容渗进了企业ZDR会话，那对企业客户就是另一个量级的问题。
另一位用户yurukusa给出了排查思路：Claude Code每个会话的完整收发内容都写在本地~/.claude/projects/<encoded-cwd>/<session-id>.jsonl里，用grep搜关键词就能判断——如果本地文件里能搜到“minecraft”，说明是本机不同会话的上下文串了线，不是服务端泄露；如果本地什么都搜不到，那问题就落在模型或服务端一侧，对标榜零数据保留的企业workspace来说，这才是真正的麻烦。
这个诊断方法本身说明一件事：连社区都清楚“本地上下文串门”和“跨账户服务端泄露”是两种完全不同量级的问题。而截至目前，包括提交者自己在内，没人公开证实到底是哪一种。
这不是第一次，是一条老账
Claude Code过去一年，围绕“账户到底切没切干净”反复被投诉：VS Code扩展曾被指切换账户后仍粘滞在旧登录状态（#28585）；有用户专门开issue要求原生支持多账户/多profile，好把工作账户和个人账户分开（#24963）；ANTHROPIC_API_KEY环境变量被发现会静默覆盖Max订阅的登录方式，用户以为自己用的是订阅账户，实际早就切到了别的认证模式（#53728）；第三方工具cc-switch的issue里，也描述过~/.claude/auth.json认证与模型状态持久化冲突、粘滞不清的问题。
这些历史投诉大多是“体验不便”，还没上升到“内容跨账户泄露”这种更严重的措辞。也正因为官方一直没做好workspace级别的原生隔离，社区才不得不用CLAUDE_CONFIG_DIR环境变量、独立git worktree，甚至claude-swap、ccswitch这类第三方切换工具，自己给自己拼一套隔离方案。
官方没做的隔离，社区一直在用环境变量替它打补丁。
#74066放在这条时间线末端，更像是同一个结构性问题换了一层更重的说法：从“切换不流畅”滑向了“疑似内容泄露”。
谁该盯紧，接下来看什么
截至目前，Anthropic没有公开回应或确认这条issue，也没有安全公告或补丁说明，issue仍处于open状态。几个关键问题都还悬着：泄露范围到底是UI显示错乱，还是真的涉及对话历史甚至认证凭证；影响的是本地CLI、云端workspace，还是消费者Max订阅；这次是不是和历史那些认证粘滞问题同源，还是全新的回归缺陷。
- 风险.如果确认是服务端跨账户泄露，对承诺“零数据保留”的企业ZDR客户而言，这直接触及合规底线，采购决策会受影响。
对同时用工作账户和个人账户跑Claude Code的开发者来说，短期内更现实的做法是自己用CLAUDE_CONFIG_DIR分目录、或者干脆分设备/分容器隔离，而不是等官方来修——毕竟从#28585到#74066，这条队排了一年多，还没轮到。