AI 编程提交会泄露哪些本机痕迹
作者通过 GitHub 搜索和人工抽样发现，编程 Agent 会把本机账户名、项目绝对路径和会话链接带入公开文件及提交记录。这些信息通常不属于密钥，难以被常规秘密扫描发现，且搜索统计存在覆盖与计数限制。
AI 深度解读
AI 编程代理提交到公共仓库里的，可能不只有代码，还有本机用户名、项目绝对路径和会话链接。这些内容通常不算密钥，却能把开发者的机器环境、账号和不同仓库里的活动串起来。
作者用 GitHub 搜索和人工抽样检查了这类痕迹。结论值得关注，但数据要分开看：泄露确实存在，搜索结果却不足以说明有多少开发者受到影响。对经常让代理写文档、提交代码的程序员，这是一份实用的自查提示。
代理为什么会把本机信息带进仓库
作者指出了三条传播路径。
第一条是项目记忆文件。CLAUDE.md 和 AGENTS.md 用来给后续会话共享项目知识，代理可能把仓库、相邻 checkout、日志目录的绝对路径写进去。文件需要共享，路径也就跟着进入 Git。像 /Users/taro/src/app 这样的路径，直接包含了本机登录名。
第二条更隐蔽：路径被转换成了项目标识。Claude Code 把项目状态保存在 ~/.claude/projects/ 下，目录名来自绝对路径。例如 /Users/taro/src/app 会变成 -Users-taro-src-app。代理将调试输出或日志粘进仓库时，这种变形后的路径也可能一起出现。
第三条是会话链接。有些代理配置会在提交末尾添加 Claude-Session: https://claude.ai/code/session_…，或在 PR 正文附上任务链接。作者关注的是关联性：链接把提交和代理会话绑定起来，也可能将跨仓库的提交联系起来。原文没有证明，公开这些链接就能读取完整会话。
不是密钥，不代表没有身份关联价值。
搜索证明了存在，没证明普遍程度
作者在 2026-11-04 使用 gh api 查询了两类内容。
文件侧，搜索条件包括 "/Users/" filename:CLAUDE.md、"/Users/" filename:AGENTS.md 和 "-Users-" ".claude/projects"，每组取前 300 条结果，再用正则检查文本匹配片段，排除 /Users/you/、/Users/username/、/Users/<user>/ 等占位符。约三分之一到一半的命中保留下来，被判定包含真实账号名。
提交侧，作者搜索 claude.ai/code/session_ 和 chatgpt.com/codex/tasks，按最新排序各取 500 条，检查提交消息。对于 Claude 会话链接，最新的 500 条结果确实都包含链接。
但 GitHub 显示的该链接提交总量，在一个下午从 180 万到 1080 万之间变动。这个数字不适合拿来估算影响规模。
还有两个边界：代码搜索只覆盖已索引仓库的默认分支，文件数量只是下限；抽样来自搜索结果前几页，并非随机抽样。因此，这些结果能证明问题存在，不能推出全部公共仓库中的发生比例。作者也没有公开仓库或个人身份，只提供聚合描述。
已经提交的要查，下一次写入也要拦
可以先检查自己的公开提交和文件。作者给出的查询分别是 gh search commits "claude.ai/code/session_" --author <your-github-login> 和 gh search code "/Users/<your-login>/" --owner <your-github-login>。
本地检查则使用 kwangmyong，覆盖历史中已删除的文件和提交元数据：
brew install --cask kanywst/tap/kwangmyong
kwangmyong init
kwangmyong scan --history .
要留意最后一行的 --history，它把检查范围扩展到了历史记录。
作者还给出了 Claude Code 的写入前拦截配置：
{
"hooks": {
"PreToolUse": [
{ "matcher": "Bash|Write|Edit|MultiEdit|NotebookEdit|mcp__github__.*", "hooks": [{ "type": "command", "command": "kwangmyong hook claude" }] }
]
}
}
关键是 matcher：它覆盖的不只是 Shell，还包括文件写入和 GitHub MCP 调用。
按原文描述，kwangmyong hook claude 会检查姓名、登录名、邮箱、主机名和 home 路径，拦截携带这些值的 git commit、git push、gh 正文、文件写入及 GitHub MCP 调用，并在反馈中遮蔽命中值。原文还称 Codex、Gemini CLI、Cursor、Copilot、Windsurf、Kiro 和 Devin 有对应适配器，但没有展示它们各自的配置和验证结果。
我的判断
作者说得对的地方，是把注意力从密钥扩展到了身份痕迹。传统 secret scanner 没报警，并不能回答 README 里该不该出现本机路径。
拦截点放在代理执行工具之前，也有实际价值。和只在提交时检查相比，它有机会覆盖 PR 正文、远程 API 等不一定经过本地提交的出口。
不过，原文没有提供误报率、漏报率，也没有与其他扫描器做对照。工具能否识别各种路径变形、是否影响正常文档写作，都没说清。演示说明了工作方式，不能替代全面验证。
用户名和公开邮箱也未必需要全部禁止。对一般团队，更合适的是先明确哪些信息允许公开，再选择检测规则。否则，连正常的作者署名也可能成为阻断项。