工作流
Codex 如何同时修改前后端两个仓库？目录、规则与逐库验证
前端与后端分在两个 repo，怎样让 Codex 一起修改？按桌面多文件夹与 CLI --add-dir 选择入口，核对主目录、写权限、另一库规则与依赖，再逐库检查 diff、测试和接口兼容，避免只改一边或验错目录。
前端在 web 仓库，后端在 api 仓库。你想让 Codex 增加一个接口字段，再把它接到页面上，却发现只改了一边，另一边能读不能写，或两边测试都绿了但联调仍失败。先把两个库的实际目录、可写范围、规则和验收条件分别确认，再安排同一次任务中的关联修改。把目录加进来，只解决了其中一部分。
本文处理 Codex 同时改前后端两个仓库、codex add-dir multiple repos 和额外目录写入权限。以同一执行主机上两个相关的本地 Git 仓库为例；桌面端与 CLI 分开操作。不是把两库合并成 monorepo，也不要求为了协作移动目录、重建 Git 或扩大到整个用户目录。
先分清四件事
| 你需要确认的事 | 什么才算确认 |
|---|---|
| 两库在哪里 | 任务实际主机、绝对路径、各自 Git 根与分支／提交对得上 |
| 哪些目录能改 | 当前执行端的有效权限允许本次所需操作；能读取不等于能写入 |
| 用哪套规则和工具 | 两库相关规则已核对，各自安装与测试命令明确；附加目录不等于自动加载配置 |
| 两边是否一起做完 | 每库改动和测试分别通过，接口约定及需要的联调也通过 |
如果两个路径其实属于同一个仓库，先按子项目处理；若是同一仓库的不同 worktree，先看 worktree 定位与改动检查。下面不把它们当成两个独立仓库。
1. 记录两库的真实位置和改前状态
适用条件： 还没开始修改，或不确定 Codex 打开的是哪份前后端代码。
先确认任务在本机、WSL、容器还是远程主机执行。路径必须属于那个执行环境；本机存在的目录不会因为写进提示词就自动出现在远端。下面是示意布局，路径换成自己的实际位置，含空格时保留引号：
/work/product/web/ 前端 Git 仓库
/work/product/api/ 后端 Git 仓库在实际执行环境的终端分别查看：
git -C "/work/product/web" rev-parse --show-toplevel
git -C "/work/product/web" rev-parse --path-format=absolute --git-common-dir
git -C "/work/product/web" --no-optional-locks status --short --branch --untracked-files=all
git -C "/work/product/api" rev-parse --show-toplevel
git -C "/work/product/api" rev-parse --path-format=absolute --git-common-dir
git -C "/work/product/api" --no-optional-locks status --short --branch --untracked-files=all这里的 Git -C 指定这一条 Git 命令的执行目录；与后面的 Codex -C 分别属于各自程序。rev-parse 的第一项查看工作树根，第二项查看公共 Git 目录。预期结果： 根路径对应预期位置，并记录各自分支及原有修改。根相同通常是同库子目录；根不同但公共 Git 目录相同，说明关联工作树，不应按两个独立库安排提交。如果路径不存在或 checkout 不符，先纠正目录；共同父目录还可能被识别为别的外层仓库，不在其中盲目操作 Git。
普通 status 不完整展示忽略文件的内容，也不会保存编辑器里未落盘的修改。开始前保全必要的用户修改、未跟踪／忽略文件和未保存缓冲区；分支相同或工作区干净都不是完整备份。已有改动不要求先清空，后面只修改可明确归属于本任务的部分；不能分离时按保留原有修改的处理边界保留现状再人工核对。
2. 按执行端添加第二个目录，保留需要的权限边界
桌面端：添加文件夹，并确认哪个是主文件夹
适用条件： 本地桌面项目提供多文件夹入口，两个库都在该主机可访问的位置。
按官方 Projects 说明，打开项目菜单的 Edit project，用 Add folder 添加另一个库；需要调整默认工作目录时，在对应文件夹上选择 Make primary。然后从这个项目新开聊天，核对项目显示的两个目录及主文件夹。没有该入口时先记录客户端版本与项目类型，不照搬 CLI 参数到聊天框里。
主文件夹决定新聊天的起始目录、默认 Git 操作和 AGENTS.md、Skills、config.toml 的自动发现。第二文件夹可以参与搜索、读取与编辑，这些规则文件不会仅因它被附加就自动发现。远程项目当前只支持一个文件夹，不能把本地多文件夹步骤直接套上去。
预期结果： 当前项目确实附加了这两个相关目录，主文件夹正确。文件夹组织与沙箱权限是两层控制；仍需核当前权限和任务实际访问结果，不能仅凭项目列表判断任何文件都能修改。
另外，官方说明桌面审查面板可显示附加仓库的改动，但 PR 和 worktree 操作面向主仓库。主仓库进入 worktree 时其他文件夹仍附加着，不能假定后端也获得了新的独立 worktree。并行任务可能仍改到同一份后端 checkout；需要隔离时分别规划两库的工作目录和改动归属，再开始任务。
CLI：区分主工作目录与 --add-dir
适用条件： 使用本地 Codex CLI，确实需要它修改第二个库，且当前组织策略允许这些目录。
先在终端检查当前安装的 codex --help 是否包含 --cd、--add-dir、--sandbox 和 --ask-for-approval。下面命令用于启动一次会话，会进入 Codex，不是聊天框内的斜杠命令：
codex -C "/work/product/web" --add-dir "/work/product/api" --sandbox workspace-write --ask-for-approval on-requestWindows PowerShell 使用实际 Windows 路径，例如：
codex -C "C:\work\product\web" --add-dir "C:\work\product\api" --sandbox workspace-write --ask-for-approval on-request按 CLI 官方参考，-C／--cd 设置主工作目录，--add-dir 为主工作区之外的目录增加写入范围，可重复指定。建议使用已核实的绝对路径，减少不同启动目录带来的歧义；绝对路径不是这个参数唯一允许的形式。
这里保留 workspace-write 和按需审批，不把 Full access 或关闭审批作为双库工作的默认前提。只需要参考后端代码时，不必为了“让 Codex 看见”就先授予写权限；先检查是否已经能读取。长期固定目录的 writable_roots 配置另见配置路径与生效检查，单次任务不必先改全局设置。
启动后，可在支持的 CLI 输入框用 /status 核当前目录、权限及可写范围，再请任务只读报告两个路径的 Git 根。预期结果： 会话以 web 开始，所需第二目录出现在有效范围中。权限显示仍不能替代后续实际写入验证；参数不支持、配置覆盖或策略拒绝时，保留原错误并查本机帮助和配置来源，不继续放大范围。
3. 单独核对第二库规则与依赖，不把读过当加载过
适用条件： 两库已能访问，准备让同一个聊天跨库修改。
AGENTS.md 官方发现规则围绕全局指导、项目根到当前目录建立启动指令链。--add-dir 改变写入范围，不会替你建立另一仓库的启动规则链，也不会把另一库的配置、技能或依赖环境搬过来。
在首次编辑之前，请 Codex 明确读取两个库中与本次路径有关的规则和项目说明，列出文件路径、适用目录、测试命令及冲突项。核对第二库根及目标子目录的 AGENTS.md／AGENTS.override.md；有自定义回退文件名时按实际配置检查。不要把两份规则简单复制成一个全局文件，也不让前端的格式化或安装命令自动作用于后端。
可先发送这个只读请求；占位项应替换成实际路径和需求，任务调用仍可能消耗额度：
先只读核对，不修改文件、不安装依赖、不提交、不联网写入。
前端：[实际路径]；后端：[实际路径]；主工作目录：[路径]。
本次需求：[具体接口与页面行为]。
请分别核对 Git 根、当前分支/提交与已有修改，
读取各库对本次目标路径适用的规则、README 和依赖/测试声明。
列出规则来源及作用范围、准备运行的准确命令、冲突或缺失条件。
区分启动时自动加载与本轮显式读取，不把第二库配置当成已激活。
暂不输出密钥、完整环境变量或与本任务无关的代码。验证方法： 打开它列出的规则文件和项目声明，检查摘要是否对应原文、测试脚本是否真实存在，并在之后的命令记录中核对实际执行目录。模型说“规则已生效”只能作为线索；显式读了第二库的指导，不代表运行时自动发现链或配置优先级已改变。需要以第二库作为主项目加载配置／技能时，另开正确目录的会话再核对，不靠一句“按这份配置执行”替代加载。
两库还应各自确认运行时、锁文件、依赖安装方式和必要的本地服务。依赖确需安装时，先审阅项目规定的命令、安装脚本、联网条件与本任务授权，再在对应库执行；一库安装成功不能证明另一库已就绪。不复制 node_modules、虚拟环境或凭据来冒充环境准备。遇到任务内找不到 Node／Python 等问题，转到任务环境排查。
如果规则冲突或来源不清： 先列出冲突、各自范围及允许执行的部分；不能通过扩大目录权限解决指令冲突或绕过管理要求。安全边界按官方沙箱说明和当前执行端的有效策略判断。
4. 用一个接口变化约束两边的修改
适用条件： 路径、权限、规则和依赖条件已明确，可以实施原任务。
例如，项目约定给 /api/profile 响应新增可选字符串 displayName，保留已有 name；前端优先显示非空 displayName，缺失或为空时回退到 name。这是示例约定，不代表你的 API 已有这些路径或字段，应替换为真实需求。
先共同确认下面的验收关系，再修改两边：
| 这一侧要做的事 | 对应验收 |
|---|---|
| 后端返回新字段，保留旧字段与原权限行为 | 在规定测试中检查字段类型、兼容响应与原有用例 |
| 前端读取新字段并保留回退 | 检查新响应、旧响应缺字段、空字符串这三种显示结果 |
| 两边接在一起 | 确认前端实际请求的是刚核对的后端版本，响应与页面显示一致 |
把接口方法、请求参数、响应类型、错误情况和改动允许范围写清。尤其核对开发代理、API 基址、端口和服务启动目录：前端连接旧后端时，两边文件都改对也不会得到预期结果。只读查看相关配置时不输出含密钥的完整 .env；本地服务或集成请求按项目规定使用最小测试数据。
实施请求可这样写：
按刚确认的接口约定完成两个仓库的关联修改。
前端允许修改：[路径/行为]；后端允许修改：[路径/行为]。
保留现有用户修改，各库遵守已核对的适用规则。
先完成约定的兼容接口与对应前端处理，再按各库原有命令验证，
最后核对实际接口响应与页面行为；报告命令、目录、退出状态和结果。
不要修改无关仓库、凭据、全局配置或部署设置。
不自动提交、推送或创建 PR；缺权限或约定有冲突时说明具体阻塞。按依赖关系安排顺序，不要求必须开两个代理或并行编辑。契约尚未确定就让两边各自猜测，往往会得到两个分别通过、合起来不兼容的实现。
5. 逐库审阅改动，再做接口验收
适用条件： Codex 回复修改完成，准备确认是否真的交付。
先在两个实际路径分别查看改动，而不是只看主仓库的状态：
git -C "/work/product/web" --no-optional-locks status --short --branch --untracked-files=all
git -C "/work/product/web" --no-pager diff --no-ext-diff --no-textconv --
git -C "/work/product/web" --no-pager diff --cached --no-ext-diff --no-textconv --
git -C "/work/product/api" --no-optional-locks status --short --branch --untracked-files=all
git -C "/work/product/api" --no-pager diff --no-ext-diff --no-textconv --
git -C "/work/product/api" --no-pager diff --cached --no-ext-diff --no-textconv --按 Git status 与 Git diff 的范围，两份 diff 分别展示未暂存与已暂存的已跟踪改动；新文件从 status 找出后另看正文，忽略文件和已提交历史另核。diff 不会标明修改作者；与第 1 步的改前记录比较，不能把现有用户工作归给这次任务。空 diff 也不证明已完成或没修改。
接着在各库自己的目录运行第 3 步确认过的测试。下面仅示范两个均已定义 test:contract 脚本、依赖已准备好的 Node 项目；不存在该脚本时，使用原项目真实命令，不新建空脚本凑通过：
(cd "/work/product/api" && npm run test:contract)
(cd "/work/product/web" && npm run test:contract)请逐条单独运行，记录每次工具返回的退出状态与本次输出，再执行下一条；不能拿整个代码块最后的状态代替两个结果。子 shell 中的 cd 不会把下一条命令悄悄留在上一个库。Python 或其他项目同样按各自解释器与原命令执行，不因前端用 npm 就强行统一工具。
成功标准： 两库预期文件与差异正确，未覆盖原有工作；测试确实收集到相关用例并通过；原有相关检查没有被删弱；接口契约及必要联调通过。前端若只用 mock，还需核 mock 是否与本次后端的真实类型、状态码和响应一致，不能以两边各自退出 0 代替接口验证。
一边失败时： 记录哪一库、哪条命令、哪个约定不符，保留已完成的另一边及用户修改。先处理对应依赖、实现或契约错误，再运行受影响的检查；无法完成联调时明确写“单库检查通过，联调未验证”和缺少的条件，不把任务标成双库完成。
6. 常见边界：能读不能写、只看到一份 diff、只建了一个 PR
- 第二库能读不能写： 核实际执行端、目标解析后的路径、有效可写范围、系统权限与管理策略；错误指向
.git/index.lock时看 Git 提交权限排查。额外目录写权限不等于所有受保护控制目录可写，不默认使用 sudo、全盘授权或关闭沙箱来验证。 - 文件或规则仍找不到： 先核真实路径、当前 checkout 与本轮实际读取；文件问题看列表与实际读取验证，自动规则链问题看 AGENTS.md 加载排查。两类证据不能互相代替。
- 主库有 diff，另一库没有： 用上面的
git -C单独检查另一库，核目标文件、未跟踪／暂存状态及已提交内容；不立刻重做同一修改。桌面 worktree 任务尤其要核第二目录是否仍是原 checkout。 - 任务还要求提交或 PR： 两库各有暂存区、提交、远端和 PR，不存在一个跨独立仓库的 Git 原子提交。只在明确要求时分别审阅、选择本次文件并交付，记录两个提交与依赖关系；桌面的主仓库 PR 按钮不代表后端也已交付。分别验远端与 PR 可参考推送和 PR 完成检查。
跨库发布顺序也要遵守原项目流程：先支持兼容的新后端，再切换依赖它的前端，或按已确认的其他兼容方案安排；修改代码不自动授权部署两套生产服务。无法分离混合改动时保留现场，不能用整库 reset／clean 把任一侧“恢复干净”。
核验范围
本文于 2026-10-20 核对 OpenAI 的多文件夹项目、CLI、沙箱与 AGENTS.md 文档及 Git 官方资料，并在 macOS 的隔离双仓库中验证路径检查、逐库差异和测试命令，用本地回环接口对照单库测试与联调结果。本机 CLI 帮助核对了示例选项；没有调用真实模型、改变用户目录授权、复现所有桌面／Windows 行为或向真实仓库提交推送。读者仍应在实际任务中分别确认权限、规则读取、文件改动和接口结果，不把离线命令检查当作双库任务已经成功。