每 10 分钟自动“清空现场”？Claude Code 被曝悄悄执行 git reset --hard，开发者未提交代码遭反复抹掉

一次不像 bug 的 bug：代码不是写没的，是被“定时归零”的

在 AI 编程工具越来越像“副驾驶”的今天，开发者最怕的并不是模型答错一道题，而是工具在你不知情的情况下，直接对项目仓库下手。最近，GitHub 上一则关于 Claude Code 的 issue 引发了不少开发者紧张围观：一位用户称，Claude Code 会在其项目目录中每隔 10 分钟自动执行一次 git fetch origin，随后再来一发 git reset --hard origin/main。

对熟悉 Git 的人来说，这串命令的杀伤力根本不用翻译。简单说，凡是还没提交、但已经被 Git 跟踪的修改，都会被强制覆盖回远端主分支状态。你刚改完的 api.ts，可能转头就像什么都没发生过一样恢复原样；倒是那些还没纳入版本控制的零散文件，反而能幸存。这种感觉很像你在认真装修房子，结果每隔 10 分钟就有个看不见的“系统管理员”进门，把墙刷回开发商默认白。

更让人后背发凉的是，这位用户并不是“感觉有问题”就来发帖，而是拿出了一整套近乎法医式的排查证据：reflog 记录显示 95 次以上、精确到 10 分钟间隔的 reset；fswatch 捕捉到 .git/ 目录锁文件变化；lsof 确认只有 Claude Code 进程停留在该仓库目录；而进程监控又显示，现场没有外部 git 二进制被拉起来，说明操作很可能是在程序内部以库调用方式完成的。换句话说，这不是“某个脚本误触发”，更像是工具本身在默默做事。

最可怕的地方，不是会 reset，而是它“安静得像没发生过”

软件世界里，破坏性操作并不稀奇，rm -rf、DROP TABLE、git push --force，哪个不是老江湖们听了都要抖一下的词。但这些命令至少有个共同点：它们通常需要人主动执行，或者至少有机会看到命令行、看到日志、看到确认框。而这次被指出的问题，最令人不安的，是它的静默性。

根据 issue 描述，只要修改的是 tracked file，也就是已经被 Git 管理的文件，到了下一个 10 分钟节点，它就会无声无息地被恢复。没有弹窗，没有提示，没有“是否继续”，甚至因为 reset 后工作区重新干净了，很多人一开始可能会误以为是编辑器抽风、保存失败、热更新回滚，或者自己记错了。要不是这位开发者持续观察 36 小时、横跨 4 次 session 去核对 reflog，很多人可能根本不知道罪魁祸首是谁。

这也解释了为什么这类问题格外危险。已提交的代码不会受影响，于是 bug 显得“间歇性”；未跟踪文件不会被删，于是现场又不像彻底洗劫；只有那些最常见、也最脆弱的中间状态——改了一半、还没 commit 的工作内容——被精准打掉。两小时里反复重写三次代码，这不是效率工具失误，这是直接把开发节奏拦腰斩断。

从用户给出的信息看，Git worktree 似乎不受影响，主工作树才是重灾区。这一细节相当微妙，说明问题可能并非随机误操作，而是某种内部“同步”“快照”或“历史管理”机制，错误地把当前工作目录当成了一个可以随时恢复的缓存空间。对 AI 工具而言，这是一个非常典型也非常致命的边界误判：产品也许想替用户维护一致性，但一旦把“代码库”误认为“可自动整理的临时上下文”，事情就会从贴心变成惊悚。

AI 写代码的时代，版本控制边界反而更该收紧

把这件事放到 2026 年的行业背景里看，它远不只是一个 Git 操作失误。过去两年，AI 编程工具从“补全一行代码”快速演进到“读取仓库、修改多文件、执行命令、调用测试、自动提交”的 Agent 模式。它们接触的权限越来越深，离开发者的核心资产——代码、分支、提交历史、密钥、部署流水线——也越来越近。

这时候，版本控制系统其实就是最后一道心理防线。开发者愿意让 AI 改文件、跑测试，甚至生成 PR，是因为默认有一条隐形契约：未经明确授权，工具不能擅自改写我的 Git 状态，更不能执行具有破坏性的仓库操作。git reset --hard 恰恰是这条红线最醒目的标记之一。它不是普通写文件动作，而是会改变工作区和索引状态、直接覆盖用户未提交劳动成果的高危命令。

这也是为什么类似问题总会引发格外激烈的社区反应。早前业界也出现过一些 AI 编程助手“误删文件”“改乱依赖”“错误执行 shell 命令”的争议，但大多数还停留在功能边界不清、模型理解失误层面。可一旦涉及 Git 的强制重置，性质就不一样了，因为这意味着工具不再只是“建议者”或“操作者”，而是开始扮演“仓库主权的裁决者”。这对开发者来说，几乎是不可接受的。

Anthropic 的 Claude Code 这段时间在开发者圈热度不低，一个重要原因就是它比传统聊天式助手更主动、更接近真实开发流程。也正因为如此，用户才会对它抱有更高要求：越强的代理能力，越需要更细的权限控制、可审计日志和强提醒机制。能力和克制，必须一起交付。

这不只是 Claude Code 的问题，而是整个 AI Agent 行业的提醒

从报道角度看，这类 issue 最有价值的地方，不是“又一个产品翻车了”，而是它暴露了 AI Agent 产品设计里一个越来越现实的问题：当工具能够跨越编辑器、终端和版本控制系统时，到底哪些动作必须默认禁止，哪些动作必须逐次确认，哪些动作必须完整留痕？

今天很多 AI 编程产品都在宣传“像同事一样工作”。但真正的同事就算再莽，也不太可能每隔 10 分钟跑来给你 reset --hard 一次，还假装无事发生。软件一旦具备自动化能力，就会把小失误放大成系统性灾难。尤其在代码场景里，最珍贵的往往不是最终 commit，而是 commit 之前那些不断试错、不断改写、还没来得及整理的思考痕迹。AI 如果把这些痕迹当成噪音清掉，等于把创造过程本身一并抹除了。

这起事件也顺手给开发者上了一堂老派但依然有效的 Git 课：频繁提交不是古板习惯，而是数字时代的自救；worktree、分支隔离、自动备份看似麻烦，真出事时就是救命绳。当然，这并不意味着责任该由用户承担。要求用户“多 commit 就好了”，本质上不能替代产品侧对高风险行为的约束。汽车刹车失灵，不能怪司机不该上高速。

更关键的问题是，AI 工具厂商是否准备好把“安全可控”当成核心产品能力，而不是附属说明书。对于 Anthropic，也对于 OpenAI、GitHub、Cursor、Replit 以及一众正在把 AI 往开发流程深处推进的公司来说，真正的竞争已经不只是模型谁更聪明，而是谁更值得托付项目目录的钥匙。

如果这次 issue 最终被证实属实，那么修复方式恐怕不该只是“修一个 timer”这么简单。更合理的方向，应该包括：所有 Git 破坏性操作默认禁用；涉及 reset、checkout、clean、force push 等行为时强制显式确认；把内部程序化 Git 调用完整写入可见日志；让用户能一眼看见工具当前工作目录与即将触达的仓库对象。说到底，Agent 的可用性不只来自自动执行，更来自“你知道它在干什么”。

一个小小的 issue，为什么让人心里发毛

看上去，这只是 GitHub 上一条带着 bug、data-loss 标签的公开 issue。但它真正刺痛人的地方，在于它碰到了 AI 时代最稀缺的东西：信任。开发者愿意把项目交给 AI，不是因为工具永远不犯错，而是因为犯错时至少要可见、可追、可控。沉默地重置代码，恰好踩中了这三条的反面。

从用户提供的调查过程来看，这位开发者几乎把所有“外部元凶”都排除了：Git hooks、插件市场更新器、云同步、crontab、LaunchAgents、开发服务器、编辑器、Time Machine、各类 watch 工具，都查了一遍。这种细致程度，某种意义上也映照出今天开发者对 AI 工具的复杂心情：一边离不开，一边又得像防范系统幽灵一样监视它。

AI 编程助手正从“提建议的软件”变成“真正动手的软件”。这一步跨出去以后，用户容忍度会迅速下降。写错一段函数，还能笑笑改掉；悄悄把仓库还原，大家就笑不出来了。对整个行业来说，这不是小题大做，而是一记很实在的警钟：在代码世界里，越聪明的工具，越要先学会不乱碰用户的历史。