Git worktrees ≠ 隔离

Git worktrees 根本不是 coding agents 的隔离边界——这个结论我花了三天调试才认下来。
当时图省事：用 Claude Code 和 Cursor 分别维护同一仓库的两个 feature，想着 git worktree add 各占一个目录，agent 们各改各的，完美。结果是 A agent 做了 git fetch --prune，B agent 那边的 reflog 直接乱掉；B agent 往 Git hooks 里写了个验证脚本，A agent 运行测试时莫名其妙被卡住。折腾一圈发现：worktrees 只隔离了 working tree 和 index，其他全部共享——同一个 .git 目录、同一套 refs、同一个 stash 栈、同一条 config。这对人来说分得清，但 agent 不知道边界在哪。

具体来说，三个坑最致命：

• Ref 污染：两个 agent 都基于 main 开新分支，worktree 是独立的，但远程追踪分支、HEAD 引用全写在一份 .git/refs 里。Agent A 把本地分支 force push 了，agent B 的 git status 立刻显示超前/落后，它可能就自作主张去 rebase。
• Stash 乱入：Agent B 在它的 worktree 里 git stash，agent A 的 worktree 里 git stash list 也能看到，而且 git stash pop 能弹出别人的暂存项。一个 agent 的变更可能被另一个意外恢复或覆盖。
• Hooks 和 config：core.hooksPath、include.path 作用于整个仓库，agent 一改 hook，另一个的工作流直接受影响。我遇到的是 agent A 加了 commit-msg 校验，agent B 提交时频频失败，调试了半天才发现问题出在共享的 hook 上。

所以如果你的 coding agent 会在多个分支之间来回切、做 git stash、改 hook 或者执行 git pull --rebase——跟另一个 agent 同仓库、不同 worktree，迟早出事。我最后的方案是回归最笨的办法：完全独立的 clone。或者用 git clone --separate-git-dir 创建互不干扰的工作目录和仓库实体，每个 agent 拥有一整份 .git，谁也不欠谁。虽然占用磁盘翻倍，但比半夜被集成报错喊醒值。

记一笔，给打算用 worktree 给 AI 编程工具“划地盘”的各位提个醒：worktree 是工作区隔离，不是安全隔离。