本文揭示 Claude Code 在切换工作区或消费账户时，未正确清理会话与缓存，导致敏感数据跨用户泄漏的严重安全缺陷。

漏洞概述

Anthropic 的 Claude Code 工具（CLI 版本）被发现存在一个严重的安全问题：当用户在同一个终端会话中切换工作区实例或切换消费账户（consumer account）时，前一个会话的认证令牌、缓存数据、会话状态等敏感信息会被意外泄漏给新的工作区或账户。该问题在 GitHub 上以 Issue #74066 提交，获得 236 分的高热度，并引发 114 条讨论，说明社区对此高度关注。

技术背景：Claude Code 的工作区与账户模型

Claude Code 是 Anthropic 推出的命令行 AI 编程助手，类似于 GitHub Copilot 的 CLI 模式。它允许用户创建多个工作区（workspace instances），每个工作区可以关联不同的项目、配置和消费账户。消费账户通常指用户用于支付 API 费用的组织或个人账户。

在正常设计下，每个工作区实例应当拥有独立的运行环境，包括：

• 认证令牌（auth tokens）
• API 密钥
• 缓存数据（如对话历史、代码补全上下文）
• 会话状态（当前对话的上下文窗口）
• 环境变量

当用户切换工作区或切换消费账户时，系统应当执行彻底的清理和隔离操作，确保新会话不继承任何旧会话的敏感数据。

漏洞具体表现

根据 Issue 中的报告，该漏洞在以下场景中可以被触发：

场景一：同一终端中切换工作区

用户在终端中启动 Claude Code 并关联项目 A 的工作区，进行了一些操作（包括身份认证、API 调用等）。然后用户在不关闭终端的情况下，通过某种方式切换到项目 B 的工作区。此时，项目 B 的工作区可能会读取到项目 A 的缓存数据，包括：

• 项目 A 的 API 认证令牌
• 项目 A 的对话历史
• 项目 A 的配置文件内容（可能包含敏感路径或密钥）

场景二：切换消费账户

用户使用个人账户登录 Claude Code 并工作，然后切换到组织账户（例如为了使用不同的 API 配额或计费方式）。在切换后，新账户的操作仍然可能使用旧账户的认证令牌，导致 API 调用被错误地路由到旧账户，或者旧账户的缓存数据被新账户访问。

技术根因分析

虽然 Issue 中没有提供完整的源代码分析，但根据社区讨论和类似 CLI 工具的经验，问题可能出在以下几个方面：

1. 全局状态管理不当

Claude Code 可能使用了一个全局的会话管理器（singleton pattern），该管理器在进程生命周期内保持状态。当工作区切换时，代码只更新了部分状态字段，但没有完全重置所有内部数据结构。例如：

python

伪代码示例

class SessionManager:
_instance = None

def __new__(cls):
    if cls._instance is None:
        cls._instance = super().__new__(cls)
        cls._instance.cache = {}
        cls._instance.auth_token = None
    return cls._instance

def switch_workspace(self, new_workspace_id):
    # 只更新了 workspace_id，但未清理 cache 和 auth_token
    self.current_workspace_id = new_workspace_id

2. 文件系统缓存未隔离

Claude Code 可能将缓存数据存储在共享的文件系统路径下（如 ~/.claude/cache/），但不同工作区的缓存文件命名方式没有包含足够多的区分信息。当切换工作区时，缓存键（cache key）的生成逻辑可能只考虑了部分上下文，导致不同工作区的缓存键发生冲突。

3. 进程环境变量泄漏

在 CLI 工具中，环境变量是进程级别的。如果 Claude Code 通过修改环境变量来切换账户（例如设置 ANTHROPIC_API_KEY），那么同一进程内的所有后续操作都会受到影响。更隐蔽的是，子进程可能继承父进程的环境变量，导致泄漏范围扩大。

4. 异步操作中的竞态条件

Claude Code 可能使用异步 I/O 处理缓存读写。当切换操作发生时，如果前一个工作区的异步缓存写入操作尚未完成，新工作区可能会错误地读取到正在写入的中间数据，或者写入操作覆盖了新工作区的数据。

安全影响评估

该漏洞的安全影响等级应为 高（High），理由如下：

1. 敏感数据暴露：认证令牌和 API 密钥是访问控制的核心凭证，泄漏后攻击者可以冒充用户调用 Claude API，产生费用或窃取模型输出。

2. 横向移动：在多租户环境中（如 CI/CD 系统或共享开发机），一个用户的工作区数据可能被另一个用户的工作区访问，导致组织内部数据泄漏。

3. 持久性：缓存数据通常不会随着会话结束而自动清除，这意味着即使切换回原工作区，泄漏的数据可能仍然存在于新工作区的缓存中。

4. 利用难度低：攻击者只需要在同一个终端中切换工作区即可触发漏洞，无需特殊权限。

缓解与修复建议

临时缓解措施

1. 每次切换工作区后手动重启 Claude Code 进程：这是最彻底但最影响体验的方法。
2. 使用不同的终端窗口或 tab 运行不同工作区：物理隔离可以避免进程内状态泄漏。
3. 在切换前手动清除缓存目录：例如执行 rm -rf ~/.claude/cache/*。

长期修复方案

1. 实现完整的状态隔离：每个工作区实例应当拥有独立的 SessionManager 实例，而不是共享全局单例。

2. 缓存键加盐：在缓存键中引入工作区 ID 和账户 ID 作为命名空间，确保不同工作区的缓存不会冲突。

3. 切换时执行深度清理：在 switch_workspace() 方法中，不仅要更新 current_workspace_id，还要重置所有内部状态变量，包括 auth_token、cache、conversation_history 等。

4. 使用子进程隔离：对于不同工作区，考虑使用子进程（subprocess）或容器（如 Docker）进行物理隔离，而不是在同一进程中切换上下文。

5. 增加审计日志：记录所有工作区切换操作，包括切换前后的账户信息，便于事后追溯。

社区讨论中的其他发现

在 114 条评论中，社区成员还报告了以下相关问题：

• 缓存文件权限问题：Claude Code 创建的缓存文件默认权限为 644（全局可读），在多用户系统上可能导致不同用户之间的数据泄漏。
• 环境变量未清理：当用户通过 export ANTHROPIC_API_KEY=xxx 设置密钥后，即使切账户，该环境变量仍然生效。
• SSO 令牌持久化：使用 SSO 登录后，令牌被写入磁盘且未设置过期时间，导致长期泄漏风险。

行业对比：其他工具的实践

其他类似的 AI 编程助手在隔离方面的做法值得参考：

• GitHub Copilot：每个项目使用独立的 .vscode 配置，且认证令牌存储在操作系统的密钥链（keychain）中，而非文件系统。
• Tabnine：使用进程级隔离，每个 IDE 实例启动独立的子进程，避免状态共享。
• Amazon CodeWhisperer：强制要求每次切换 AWS 配置文件时重新认证。

总结

Claude Code 的工作区/账户隔离漏洞是一个典型的状态管理问题，源于 CLI 工具开发中常见的“单例模式滥用”和“缓存设计疏忽”。对于 Anthropic 来说，这是一个需要优先修复的安全问题，尤其是在 Claude Code 被越来越多企业采用用于生产环境开发的背景下。对于用户而言，在官方修复发布之前，应当避免在同一个终端会话中切换工作区或账户，并定期清理缓存文件。

原文链接：https://github.com/anthropics/claude-code/issues/74066