背景
刚开始使用 Codex 做代码任务时，很容易把“工作树”理解成一个更复杂的运行环境：像虚拟机、容器，或者某种独立沙盒。实际上，它更接近 Git 提供的一套并行工作目录机制。
这轮对话要解决的问题很直接：Codex 中的工作树到底是干什么的？答案可以先压缩成一句话：它是一份独立的代码工作目录，让某个任务可以在自己的分支和文件状态里推进，不打乱你当前正在看的那份代码。
这次解决了什么
这次把 Codex 工作树的核心作用拆成了四点：
- 隔离修改：Codex 可以在独立目录里改代码、跑验证、准备提交，不影响主工作区里的未提交内容。
- 支持并行：多个任务可以分别占用不同工作树，一个修 bug，一个做新功能，彼此不抢同一份检出文件。
- 方便审查：每个工作树通常对应一个独立分支，后续可以看 diff、提交、合并，或者丢弃整个工作树。
- 节省空间：Git worktree 不是重新 clone 一份完整仓库，而是复用同一套 Git 对象，只多出独立的文件检出目录。
它解决的是“同一个仓库里同时推进多个代码状态”的问题，而不是“把所有外部影响都隔离起来”的问题。
关键过程
理解工作树时，可以把它想成“同一个仓库的另一张工作台”。主工作区仍然保留当前状态；新的工作树可以检出另一个分支，Codex 在里面执行文件修改和验证。
这个模型适合 Codex 的自动化任务，因为它降低了互相干扰的风险。比如当前目录里有你手动改到一半的文件，另一个 Codex 任务如果直接在同一目录里修改，就可能让状态混在一起。工作树把这两件事拆开：你继续保留原来的现场，Codex 在另一处完成它的任务。
但它也有清晰边界。工作树隔离的是代码目录、分支和文件状态；它不是虚拟机，也不是 Docker。数据库、环境变量、端口、远程 API、线上服务这些资源仍然可能被多个工作树共享。
踩坑
最大的误解，是把工作树当成完整运行沙盒。
如果一个任务会连接共享数据库、发送真实通知、写入线上资源，单独开工作树并不能自动消除副作用。代码文件不会混在一起，但外部资源仍然可能被同一套配置触发。对这类任务，仍然要单独确认环境变量、测试库、dry-run 开关、发送开关和服务端权限。
另一个容易忽略的点是：工作树适合代码变更任务，不一定适合所有 Codex 对话。只是解释概念、查一段代码、读日志、回答问题时，直接在当前工作区完成通常更轻。
最后方案
可以按下面这套判断来使用 Codex 工作树：
- 要做功能、修 bug、重构、跑测试，尤其当前目录已有未提交修改时，优先使用工作树。
- 要让多个 Codex 任务并行推进同一仓库的不同分支时，使用工作树。
- 要保留清晰 diff、独立提交和可回滚边界时，使用工作树。
- 只是问答、解释、只读排查或轻量检索时，不必强行开工作树。
把它看作“Git 层面的并行工作空间”最准确：它让代码现场更清楚，但不替你隔离一切运行时副作用。
以后怎么做
以后遇到 Codex 是否需要工作树，可以先问三个问题：
- 这个任务会不会改文件？
- 当前工作区有没有不想被打扰的状态？
- 这个任务是否需要独立分支、独立验证或独立提交？
只要其中一个答案是“是”，工作树通常就值得使用。反过来，如果只是问一个概念、看一个命令输出，直接在当前会话里完成就够了。
最后要记住边界：工作树保护的是代码现场，不是外部世界。凡是涉及数据库、线上接口、真实发送或生产资源的任务，都要另外设置安全开关和验证路径。