上周末，一个 GitHub issue 让不少开发者后背发凉。
有人发现 Claude Code 的插件市场刷新机制，每隔 10 分钟会执行一次 git fetch origin + git reset --hard origin/main。正常情况下，这些命令应该跑在 Claude Code 自己的插件缓存目录里。但如果那个目录的 .git 文件夹丢了（这种情况并不罕见），这些 git 命令就会”漂移”到你当前的工作目录，也就是你正在写代码的项目仓库。
后果是什么？你所有未提交的修改，每 10 分钟被静默清除一次。
这不是理论推演。issue #40701 的作者贴出了完整的 git reflog，95 条以上的 reset: moving to origin/main 记录，时间间隔精确到 10 分钟，跨越 4 个 session、持续 36 小时。他做了实时复现：修改一个 tracked 文件，等 10 分钟，改动消失。untracked 文件倒是活了下来，因为 git reset --hard 只杀 tracked 文件。他甚至用 fswatch 监控 .git/ 目录，在每次 reset 的精确时刻捕捉到了锁文件操作，确认这些 git 命令是 Claude Code 的 Node.js 进程内部执行的，连外部 git 二进制都没调用。
这个 bug 的根因说起来很蠢：插件市场的刷新函数在调用 git 命令时，没有传 cwd 参数。当目标目录不是有效的 git 仓库时，命令就落到了进程的当前工作目录。一个缺失的参数，让用户的代码仓库变成了插件更新的靶子。
不止一个坑
这不是 Claude Code 第一次在 git 操作上翻车。
更早的 issue #32793 记录了另一个同源问题：运行 claude install 会把你项目的 origin remote URL 直接改成 https://github.com/anthropics/claude-plugins-official.git，同时往 .git/config 里注入重复的 refspec，导致后续的 git fetch 直接报错。原因一模一样，插件市场的 git 操作没指定目标路径，落到了用户的项目目录。
还有 issue #39859，一个用户报告 Claude Code 在明知存在未暂存修改的情况下，直接执行了 git reset --hard，销毁了无法恢复的工作成果。这次不是后台机制的 bug，而是 AI agent 本身的判断失误。用户的原话很直白：它应该识别出 git reset --hard 是破坏性操作，应该先 git stash，应该在执行前告知用户。四个该做的事，一个都没做。
然后是上周的 issue #40714：Claude Code 从 2.1.86 自动更新到 2.1.87 时，静默清空了用户的 ~/.claude/settings.json、settings.local.json（包含 MCP server 配置和权限设置），以及所有插件的激活状态。更讽刺的是，Claude Code 的备份机制只备份 .claude.json 这个内部状态文件，用户的配置文件根本不在备份范围内。也就是说，你的 MCP 配置、权限白名单、插件设置，全靠自己记忆手动重建。
把这几个 issue 放在一起看，画面就很清晰了：Claude Code 拥有对文件系统和 git 的完整操作权限，但它的权限边界管理，从后台机制到 AI 决策层面，都存在系统性的缺陷。
四款工具，四种信任模型
Claude Code 的问题不是孤例，它代表了 AI 编程工具在权限设计上的一个极端。把当前主流的四款工具放在一起比较，能看到非常不同的设计哲学。
Claude Code 走的是”全权委托”路线。它直接运行在你的终端里，能读写任意文件、执行任意 shell 命令、操作 git。这种设计的好处是能力上限高，它可以真正地帮你跑测试、改配置、管理依赖。代价是信任成本极高。你给它的权限，本质上等同于你给一个 junior 开发者 sudo 权限然后去吃午饭。上面那些 bug 之所以能造成破坏，正是因为 Claude Code 有权限做这些事，而且做的时候不需要问你。
Cursor 选择了编辑器沙盒的路线。AI 的操作被限制在 VS Code 的编辑器框架内，它可以读你的代码、建议修改、甚至帮你重构，但这些修改需要你在编辑器里确认。它不会直接碰你的文件系统，不会自己跑 shell 命令。Cursor 的 Agent 模式确实在扩展权限边界，允许执行终端命令，但整体上还是在编辑器的管控范围内。这种设计牺牲了一些自动化能力，换来的是更可控的风险面。你不太可能遇到”AI 偷偷 reset 了我的仓库”这种事。
GitHub Copilot 是权限最小的一个。它的核心功能是代码补全和聊天，本质上是一个只读+建议的角色。Copilot 不会修改你的文件（除非你接受建议），不会执行命令，不会碰 git。Copilot Workspace 和 Copilot Agent 在逐步扩展能力边界，但 GitHub 的策略明显偏保守，每一步扩展都带着明确的用户确认机制。权限小意味着能力也受限，你不能让 Copilot 帮你跑完整个 CI 流程，但它也不会在你不知情的情况下搞坏任何东西。
OpenAI 的 Codex 走了一条中间路线。云端版本（Codex Web）在完全隔离的沙盒环境中运行，每个任务有独立的容器，预装你的代码库副本。它可以读写文件、跑命令、执行测试，但所有操作都在沙盒里，不会影响你的本地环境。任务完成后，你审查结果，决定是否合并。本地版本（Codex CLI）也提供了沙盒模式，通过网络隔离和目录限制来控制风险。这种设计的思路是：给 AI 足够的能力去完成复杂任务，但把”生效”的决定权留给人类。
这四种模型可以画成一条光谱：
Copilot（只读建议）→ Cursor（编辑器沙盒）→ Codex（隔离沙盒）→ Claude Code（全权访问）
从左到右，能力递增，风险也递增。没有哪个位置是绝对正确的，但你需要清楚自己用的工具在光谱的哪个位置，以及你是否准备好了承担对应的风险。
信任的真正问题
讨论到这里，很容易滑向”Claude Code 不安全，别用了”的结论。但这不是重点。
重点是：我们正在进入一个 AI agent 需要越来越多系统权限的时代，而整个行业还没有建立起成熟的信任框架。
Claude Code 的那些 bug，技术上都不复杂。缺一个 cwd 参数，自动更新没做配置迁移，AI 决策时没识别破坏性操作。这些都是工程质量问题，会被修复。但更深层的问题是：当我们给 AI 工具越来越大的权限时，我们的安全假设是什么？
传统软件的权限模型建立在”确定性”之上。一个程序要么有权限做某件事，要么没有。你可以审计它的代码，预测它的行为。但 AI agent 的行为是概率性的。同样的输入，不同的 context，可能产生完全不同的操作序列。Claude Code 的 system prompt 里写着”measure twice, cut once”，要求在执行破坏性操作前确认。但 issue #39859 证明了，这种基于 prompt 的约束是脆弱的。AI 可以”知道”规则，但在特定 context 下”忘记”遵守。
这就是信任的核心矛盾：我们需要 AI agent 有足够的权限来真正帮上忙，但我们还没有可靠的机制来确保它们在所有情况下都正确使用这些权限。
Anthropic 显然意识到了这个问题。Claude Code 有权限提示机制，首次执行某类操作时会请求用户确认。但一旦你点了”允许”，后续同类操作就不再询问。这是一个实用的折中，但也意味着一次授权可能覆盖了你没预料到的场景。
OpenAI 的 Codex 用沙盒解决了一部分问题，但沙盒也有代价。完全隔离意味着 AI 无法与你的真实开发环境交互，无法访问本地服务、数据库、私有 registry。对于很多实际开发场景，这是个硬伤。
目前没有完美的答案。但有一些方向值得关注：分层权限（读/写/执行分开授权）、操作审计（所有 AI 操作可追溯）、破坏性操作的硬性拦截（不依赖 AI 自己的判断）、以及可回滚的执行环境。这些不是新概念，操作系统和数据库领域早就有成熟实践，只是还没被系统性地应用到 AI 编程工具上。
现在就能做的事
等工具厂商完善信任机制可能要等很久。作为开发者，有一些立刻可以做的事情来保护自己。
git 分支策略是最基本的防线。永远不要在 main 分支上让 AI 直接操作。创建专门的工作分支，AI 的所有修改都在分支上进行，合并前人工 review。这样即使 AI 搞砸了，你的 main 分支是安全的。如果你用 Claude Code，issue #40701 的作者发现 git worktree 不受那个 10 分钟 reset bug 的影响，这也是一个值得考虑的工作方式。
频繁提交。这听起来像废话，但很多人在用 AI 编程工具时会进入一种”让它跑”的状态，半小时甚至一小时不提交。在 AI 可能随时 reset 你的仓库的世界里，这是在赌运气。每完成一个有意义的改动就 commit，哪怕 commit message 写得很随意。
配置备份。Claude Code 的 issue #40714 告诉我们，工具自己的备份机制不一定覆盖你关心的文件。把你的 settings.json、MCP 配置、插件列表单独备份，或者干脆用 dotfiles 仓库管理。被清空一次还能恢复，被清空一次还不知道原来是什么配置，那就真的很痛苦了。
了解你的工具的权限模型。这不是说要读完所有文档，而是搞清楚几个关键问题：它能不能执行 shell 命令？它能不能修改 git？它的操作是在沙盒里还是直接在你的文件系统上？它有没有后台进程在做你不知道的事？Claude Code 的插件市场刷新就是一个”后台进程做你不知道的事”的典型案例。
最后一点，也是最容易被忽略的：保持怀疑。AI 编程工具的营销话术都在强调”让 AI 帮你写代码”、”10x 效率提升”。这些可能是真的，但效率提升不应该以放弃控制权为代价。你可以信任 AI 的代码建议，但不应该信任它对你文件系统的无监督访问。
这个行业还在早期。工具会变好，信任机制会成熟，权限模型会完善。但在那之前，把 AI 编程工具当成一个能力很强但偶尔会犯低级错误的实习生来对待，大概是最务实的态度。给它足够的空间发挥，但别把 root 密码告诉它。
