Git worktree 能隔离代码，却隔离不了 Agent：共享的 .git 目录仍然可以改钩子和引用

据开发者 Fletch 的 技术分析，越来越多 AI 编程工具用 git worktree 为并行 Agent 创建独立工作目录。这能防止多个 Agent 同时改写同一份工作文件，却不是安全隔离：所有工作树仍共享同一个 Git 对象库和大量仓库元数据。

一句话结论：worktree 是很好的并发工具，却不是对不可信 Agent 的权限边界；如果一个 Agent 可以写共享 .git，它就可能影响其他工作树、后续 Git 命令乃至主仓库。

git worktree 的设计目标从来不是安全。它让一个仓库同时检出多个分支，每个目录拥有独立文件和索引，但提交对象、引用、配置及工作树管理信息仍来自共同仓库。对可信开发者来说，这种共享非常高效；对能执行任意命令的 Agent 来说，它也留下了横向影响路径。

例如，Agent 可以修改仓库级配置，改变提交身份、代理、过滤器或远程地址；可以操作 refs、标签和 stash，让其他工作树看到不同历史；某些钩子和辅助脚本也可能在后续 commit、merge 或 checkout 时执行。即使主工作区的源文件没有被直接触碰，共享控制面仍然可能被污染。

这并不意味着所有并行 Agent 都该放弃 worktree。若 Agent 受信任、任务风险低，而且每次合并前都有审查，worktree 仍是成本最低的文件级隔离。它解决了“两个进程同时写同一文件”的冲突，也让分支清理更简单。问题是不能把它宣传成容器或虚拟机。

完整 clone 会分离 refs、配置、索引和钩子，边界更清楚，但普通 clone 会复制对象库并增加磁盘与网络成本。git clone --shared 可以复用对象存储，却仍会形成对象依赖，原仓库清理对象时可能影响克隆，并不等同于完全独立。高风险任务更稳妥的做法是普通 clone，再配合容器、最小凭据和受控网络。

运行时资源也要单独隔离。不同工作树依然可能连接同一数据库、占用同一端口、使用同一云凭据和构建缓存。Agent 如果能访问 Docker socket 或用户主目录，源代码分开也挡不住更大的权限。代码隔离、进程隔离、秘密隔离和网络隔离是四个问题。

关键事实

• 来源：Fletch 技术分析、Git 官方文档
• 涉及工具：Git worktree、clone、代码 Agent
• 核心风险：共享 .git 元数据、refs、配置、钩子及外部运行时资源
• 适用边界：worktree 适合并发文件操作，不适合作为不可信代码的安全沙箱

OC 判断

这才是开发者真正会撞上的地方。并行 Agent 的主要风险不只是合并冲突，而是一个任务能否修改另一个任务依赖的控制面。可以继续用 worktree 提高吞吐，但必须把它标成“文件级并发隔离”。涉及陌生仓库、供应链检查或自动执行测试时，应升级到独立 clone、容器和短期凭据。

为什么重要

• 对开发者：不要向 worktree 中的 Agent 暴露主仓库凭据、发布令牌和不必要的网络权限。
• 对团队：Agent 平台应明确隔离层级，并记录对 .git、钩子和远程地址的修改。
• 对工具厂商：默认创建 worktree 不能替代沙箱、容器或虚拟机。

参考来源

• Git worktrees are not an isolation boundary for coding agents
• Git worktree documentation
• Git clone documentation