Claude Code每10分钟硬重置代码库|code|git|代码库|电子表格

一个Git仓库的reflog（引用日志）在36小时内被写满了95条相同的记录，时间戳精确到每10分钟一次。这不是攻击脚本，是Anthropic官方CLI工具Claude Code的"正常"行为。

用户johnmathews在3月29日提交的issue #40710显示，这款84.2k星标的AI编程助手，正在用git reset --hard origin/main自动覆盖用户的本地代码——且没有任何提示。

更讽刺的是，触发条件简单到荒谬：只要你在项目目录里启动了Claude Code，它就会开始这个10分钟周期的自我清洗。未提交的代码改动被直接抹除，像是从未存在过。

10分钟定时炸弹：一个可复现的数据销毁机制

johnmathews的排查过程堪称教科书级的故障分析。他首先注意到.git/logs/HEAD里的异常模式：每次reset都指向origin/main，间隔固定在600秒左右，但起始偏移在不同会话中随机变化（:08、:36、:41、:09）。

这暴露了一个关键特征：定时器绑定于会话启动时间，而非整点触发。换句话说，你几点打开Claude Code，决定了你的代码会在什么分钟数被覆盖。

他用fswatch监控.git/目录，在23:59:10.349秒捕获到精确的三连击：origin/HEAD.lock创建→HEAD日志更新→main分支锁文件生成。这是git fetch origin + git reset --hard origin/main的标准指纹。

但诡异的是，lsof显示当时只有Claude Code进程（PID 70111，带--dangerously-skip-permissions参数）在该仓库工作。0.1秒间隔的进程监控确认：reset发生时没有任何外部git进程被创建。

结论很明确：Anthropic把完整的Git操作逻辑嵌进了Claude Code本体，通过libgit2这类库直接操作，绕过了用户可见的git命令行。

这种设计选择让问题更难被发现——你不会在进程列表里看到可疑的git进程，系统监控工具对此完全失明。

为什么Git worktree能逃过一劫

johnmathews的测试揭示了一个有趣的免疫机制：Git worktree（工作树）完全不受影响。主仓库的reflog被reset记录塞满时，worktree的reflog干干净净。

这指向了Claude Code的实现细节：它只针对"主工作目录"执行强制同步，可能是为了确保AI始终基于远程最新代码工作。但这种"洁癖"式的设计，完全无视了用户可能正在进行的本地开发。

issue标签里的data-loss（数据丢失）和has repro（可复现）是用户自己打的。Anthropic团队在7小时后回复，确认这是bug而非预期行为，但截至发稿，修复版本尚未发布。

值得玩味的是--dangerously-skip-permissions这个启动参数。johnmathews当时使用了它，但后续测试证明，即使用标准权限启动，reset行为依旧发生。参数名字里的"dangerously"暗示了开发团队对权限绕过的警惕，却没防住更基础的数据安全漏洞。

AI工具的数据边界：当"智能"越过用户控制

Claude Code的定位是"代理式编程助手"——它能读写文件、执行命令、甚至提交代码。但这次事件暴露了一个设计哲学的裂缝：Anthropic默认AI需要"干净"的代码状态，为此不惜定期强制同步远程。

这种假设在单人快速迭代场景或许成立，但在真实开发 workflow 中堪称灾难。开发者可能正在：调试一个临时方案、保存实验性改动、或者只是暂时没commit的WIP（进行中工作）。10分钟的窗口期，短到不够泡一杯咖啡，长到足以摧毁数小时的探索性编码。

johnmathews的原始报告里有个细节被很多人忽略：untracked files survive（未跟踪文件幸存）。只有被Git索引的已跟踪文件会被reset影响，新建文件、.gitignore排除的内容会留下。这几乎像是某种"善意"的残留——但混合了版本控制与非版本控制的内容后，用户更难理清自己到底丢了什么。

Git社区对reset --hard的共识是"危险操作，需二次确认"。把它写进定时任务，且不加任何提示，相当于把链锯的保险拆掉交给用户。