编程助手本地会话记录中的密钥隐患

你没有把 API Key 提交进 Git，也可能已经留下了另一份明文副本：AI 编程助手的本地会话记录。粘贴进对话的密钥、终端输出里的凭据，以及工具读取的 .env 内容，都可能跟着会话落盘，再被备份或同步带走。

原文给出的处理顺序很明确：先轮换凭据，再清理记录，最后阻止新秘密进入会话。它值得程序员读的地方，是把排查对象从聊天窗口扩展到了电脑、备份和采集系统；但其中的产品防护能力，需要和工具原始日志分开理解。

密钥没进 Git，为什么还要查本地会话

AI 编程工具需要保存上下文，会话记录通常采用 JSONL，也就是每行一个 JSON 对象。风险不只来自用户主动粘贴：Agent 读取配置文件、执行命令、接收 CI 日志时，中间工具输出也可能被写进去。

因此，关闭聊天窗口不等于删除记录，服务商后台看不到某段输出，也不能说明电脑里没有副本。

原文引用 GitGuardian 的 2026 年分析：与 Claude Code 辅助相关的公开提交，秘密泄露率为 3.2%，全部公开提交的基线为 1.5%。这只能说明相关性，不能证明 Claude Code 导致泄露，更不能拿来推算本地会话里有多少密钥。

排查时，应先认清文件位置。输入中的路径信息可以整理为：

工具	需要检查的位置
Claude Code	~/.claude/projects/ 下的 JSONL 会话文件
Codex	~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
Cursor	~/.cursor/projects
Copilot	~/.copilot/session-state
Antigravity	原文只提到 brain logs，没有给出完整路径

Codex 的 ~/.codex/history.jsonl 是提示词索引，不是完整会话，也不在 ReclaimLLM 的 rclm-sync 历史导入范围内。只扫描它，会漏掉完整工具输出。

原文称这些目录来自他们生产环境的历史导入规则，并与厂商文档对齐。这是产品实践说明，不代表覆盖了所有版本和安装方式。尤其是 Antigravity，会话目录仍需补查；文中给出的 ~/.gemini/antigravity/mcp_oauth_tokens.json 是 OAuth 令牌文件，不能拿它代替会话日志。

还要检查副本。Time Machine、企业终端备份、电脑镜像，以及同步主目录的 iCloud、OneDrive、Dropbox，都可能复制这些文件。误提交的 dotfile 仓库和共享会话链接，也会扩大清理范围。

扫描只是定位，先轮换才能让旧密钥失效

原文建议先用假凭据测试扫描链路，例如把 AKIAFAKEFAKEFAKEFAKE 放进一次性文件，确认扫描器能够报告它，再扫描真实目录。

这里有个操作缺口：测试文件必须位于扫描范围内，原文没有明确说明放在哪里，也没有提供实际检测输出。这个样例能否命中，还取决于扫描器的规则和配置；没命中时，应先查扫描链路。

下面两条命令分别演示扫描 Claude Code 和 Codex 的目录：

gitleaks dir ~/.claude/projects --no-git

trufflehog filesystem ~/.codex/sessions

要留意目录参数：它们指向本地会话文件。第一条中的 --no-git 也应按原文保留，但原文没有注明扫描器版本，实际使用前仍需确认当前命令是否接受该参数。

团队混用多个助手，就要逐个扫描；扫描范围较大时，可以通过工具支持的忽略规则排除 node_modules 和构建产物，减少噪声。发现的真实密钥不要直接贴进工单或 Slack，否则排查又制造了一份副本。

发现真实凭据后，第一步是去签发方轮换，而不是先删日志。

原因很直接：本地文件删掉了，备份和同步副本可能还在。先到云平台、SaaS 管理后台或数据库侧让旧值失效，再删除受影响会话的 JSONL，或者通过厂商设置缩短保留时间，才有意义。

工单记录事件类别、涉及会话和处理结果即可，不要附上密钥原文。扫描结果为空，也只能说明这次扫描没有发现，不能证明内容从未上传或从未被复制。

脱敏成功，不代表原始文件已经干净

原文来自 ReclaimLLM，介绍了它通过 hook 处理敏感内容的方式：对识别出的 .env 读取进行脱敏或拒绝。但防护存在两个边界。

首先，hook 崩溃或超时后可能放行。原文明确说，其安装器不会替用户配置 Claude 的 onFailure: "block" 或 Cursor 的 failClosed。是否阻断，需要检查厂商侧的失败处理设置。

其次，ReclaimLLM 采集内容时做了脱敏，不代表助手自己写下的文件被改过。原文明确表示，它不会删除或重写厂商拥有的本地会话文件。

新内容的脱敏、历史文件的清理、已泄露凭据的轮换，是三件独立的事。

上传流程也不能混为一谈。按原文转述的 Anthropic 数据使用说明，/feedback、/bug、/share 报告保留五年，标准上传路径没有承诺秘密脱敏。会话结束后的授权调查则不同：选择 Yes 后，会先清理已知 API Key 和 token 模式，但源代码、文件内容和其他对话仍按原样上传，最多保留六个月。

此外，第三方提供商缺少 Anthropic 凭据时，/feedback 回退生成本地归档，会先清理已知密钥和 token 模式。这些都是特定流程的描述，不能推导成所有上传都有相同保护。

对于新增的采集副本，原文称 ReclaimLLM 的 Paid/Enterprise 会话存储支持加密和组织恢复密钥，2026 年 6 月已有公告，但并非零知识方案；存储区域仅支持美国或欧盟，不支持自托管。其 SOC 2 Type II 目标是 2027 年初，按原文状态尚未认证。保留策略、法律保全，以及配置后的 30 天延迟账户删除，也都需要单独管理。

我的判断

把会话记录纳入凭据管理，我认为是合理的。以前检查 .env、Git 和 CI 日志，现在多了一个可能长期保存工具输出的文件层。只盯着用户输入框，会漏掉 Agent 自动读取和执行带来的内容。

但作者所说的「真正泄露面通常是本地副本」，没有给出本地与云端事故占比的对照数据。这是风险判断，不能据此降低对服务商存储和共享流程的关注。3.2% 与 1.5% 的提交数据，也支撑不了这个比较。

与只做 Git 提交前扫描相比，会话扫描补上了未提交文件和工具输出这部分缺口；与读取前阻断相比，它又属于事后发现。两者适合配合使用。ReclaimLLM 的 AD-004 告警可以帮助定位会话，hook 覆盖告警可以提示防护消失，但它们都不能替代本地清理。

原文没有给出扫描器或 hook 的误报率、漏报率和对照实验，因此不能把识别已知密钥模式理解成覆盖所有秘密。

能拿来做什么

• 检查日常使用的每个 AI 编程助手，把完整会话目录加入本地敏感文件扫描范围；使用 Codex 时，优先检查 sessions，不要只查 history.jsonl。
• 在前端或 Node 排障时，把带凭据的 .env、CI 输出和请求日志视为敏感输入，先移除真实值，再交给助手分析，减少秘密进入工具输出链的机会。
• 为团队写清处理顺序：先轮换凭据，再清理会话和核查备份，工单只保留定位信息；部署 hook 时，同时检查失败后的放行或阻断配置。
• 在离职和设备转交流程里加入会话扫描、MCP OAuth 令牌清理和备份范围核查。原文还建议轮换离职者最近 90 天能接触的组织秘密，这个窗口应结合实际权限与凭据有效期确定。