当本地同时维护多个项目时，Codex 并不是通过一个全局界面来切换项目，而是把当前 shell 的工作目录作为默认根目录。理解这一点后，多项目目录管理就可以拆成两个问题：如何快速进入目标目录，以及如何让项目级配置随目录自动生效。下面从目录机制、终端会话、项目配置和并行隔离几个角度展开。
理解 Codex 的工作目录机制
Codex CLI 在启动时会读取当前终端所在目录，把它作为项目根目录。之后模型查看文件、搜索符号、执行命令和生成补丁，都默认在这个根目录范围内进行。也就是说，在 ~/dev/api-server 目录启动 Codex，和在 ~/dev/web-admin 启动，模型看到的文件树完全不同，前者不会主动去修改后者的前端代码。
这就是多项目目录管理最基础的隔离方式：一个项目一个目录，启动前先进入对应目录。对于简单的两三个项目，可以直接在终端里执行：
cd ~/dev/api-server codex
如果 Codex 版本支持显式指定目录，也可以通过 codex --help | grep project 查看类似 --project 或 --root 的参数。不同版本参数可能不同，建议以当前安装版本的帮助信息为准。显式指定目录的好处是不需要改变当前 shell 的目录，适合在脚本或自动化任务中固定项目路径。
需要特别注意的是，不要在一个项目的子目录里反复启动 Codex 却期望它自动识别上层仓库边界。虽然 Codex 通常会向上查找 Git 仓库，但明确进入项目根目录仍然是最稳妥的做法，能避免模型在错误的层级创建文件。
用终端会话和工作区快速切换项目
当项目数量变多时，只靠手动 cd 会非常低效。更实用的做法是给每个项目分配独立的终端会话。比如在 Windows Terminal、iTerm2 或 GNOME Terminal 中，为后端 API 开一个标签页，为后台管理开一个标签页，为算法服务开一个标签页。每个标签页都处于对应项目根目录，随时可以直接运行 Codex，互不干扰。
在单个终端窗口内，可以使用 pushd、popd 和 dirs 维护目录栈，快速在最近使用的几个项目之间切换。下面是一个典型用法：
pushd ~/dev/api-server codex popd pushd ~/dev/web-admin codex popd
如果希望并行查看多个项目的输出，可以使用 tmux 或 screen。tmux 可以创建多个窗口和面板，每个窗口位于不同目录，启动独立的 Codex 会话。这样即使一个 Codex 正在执行长任务，也不影响另一个项目的交互。
这种终端会话管理方式的优点是零配置、直观，项目之间的隔离由操作系统进程和目录保证。缺点是需要手动维护每个会话的路径，重启终端后要重新进入对应目录。对于需要频繁切换的开发者，可以结合下一节的项目级配置减少重复工作。
通过 .codex 目录和 AGENTS.md 固化项目规则
每个项目目录内都可以放置 Codex 的项目级配置文件，最常用的是 AGENTS.md 文件。Codex 在启动后会读取当前目录下的 AGENTS.md，将里面的内容作为该项目的长期指令。这样当你在多个项目之间切换时，不需要每次重新告诉模型“这个项目用 TypeScript”“测试命令是 npm run test”“不要修改生成文件”等规则。
一个后端项目的 AGENTS.md 可以这样写：
# 项目指令 - 使用 TypeScript 严格模式，禁止 any 类型 - 测试命令：npm run test - 数据库迁移文件在 db/migrations/，不要手动修改 - 提交信息格式：type(scope): description
此外，Codex 的配置也可以通过项目根目录下的 .codex 目录或全局配置文件管理。如果项目需要单独的模型选择、审批策略或沙箱行为，可以在项目配置文件中声明。每个项目目录保持独立的 .codex 目录后，项目配置会随着目录一起被版本管理，换一台机器克隆仓库后，Codex 启动时就能自动恢复该项目的规则。
多项目环境下，建议每个项目仓库都维护一份 AGENTS.md，并把它提交到 Git。这样即使从零开始克隆项目，也能保证 Codex 获得一致的上下文。团队协作时，AGENTS.md 还可以作为开发规范文档，让新成员快速了解项目约束。
使用脚本和 Git worktree 统一项目入口
如果项目目录分散在不同磁盘或路径较长，可以编写一个 shell 函数或别名，把项目名称映射到对应路径并启动 Codex。这样不需要记住完整路径，输入一个简短命令即可进入目标项目。下面是一个 bash 函数示例：
codex-proj() {
local proj="$1"
case "$proj" in
api) cd ~/dev/api-server && codex ;;
web) cd ~/dev/web-admin && codex ;;
algo) cd ~/dev/algorithm-service && codex ;;
*) echo "未知项目: $proj" ;;
esac
}
将这段代码放入 ~/.bashrc 或 ~/.zshrc 后，执行 codex-proj api 就会自动进入后端目录并启动 Codex。也可以在函数中结合 fzf 做交互式选择，从项目列表里模糊搜索。
对于同一个 Git 仓库需要同时维护多个功能分支的场景，可以使用 git worktree 创建多个工作树目录，每个工作树对应一个分支。这样 Codex 可以在不同目录之间并行处理不同分支的任务，避免在一个目录里频繁切换分支。创建 worktree 的示例：
git worktree add ../api-hotfix hotfix/20250901 cd ../api-hotfix codex
Windows 下路径同样遵循工作目录机制，例如在 cmd 或 PowerShell 中执行：
cd C:\dev\api-server codex
这种方式把项目路径固定到脚本或终端配置中，可以减少输入错误，特别适合项目数量多但路径相对固定的开发环境。
并行管理多个项目时的隔离与注意事项
多个 Codex 实例同时运行时，如果分别位于不同项目目录，通常不会相互影响，因为它们的文件写入范围受各自根目录限制。但要注意，某些全局资源可能共享，例如全局 npm 缓存、Python 虚拟环境或 Docker 容器。如果两个项目使用相同的依赖版本但需要不同配置，最好在项目内使用本地虚拟环境，避免全局污染。
当 Codex 生成命令需要执行时，建议启用沙箱或审批模式，特别是在多个项目并行的情况下。沙箱可以限制 Codex 对项目目录之外文件的写入，审批模式则可以在执行危险命令前暂停等待确认。这样即使模型误解了某个指令，也不容易把文件写到其他项目目录。
最后，多项目目录管理的核心原则是：始终让 Codex 在正确的根目录启动，并让项目级配置跟随目录走。配合终端会话、脚本入口和 Git worktree，可以显著降低路径混淆的概率。如果团队规模较大，还可以把项目目录结构和启动方式写入团队文档，让所有成员采用一致的目录约定。