团队里第一个用上 Codex 的工程师，写了一份不错的 AGENTS.md，调好一套自己信得过的审批策略，接上两个 MCP 服务器。Agent 开始像个有用的同事。然后第二个工程师装了 Codex，第三个也装了，一周之内你有了三个版本的「同一个」Agent。一个跑在全自动，老是去碰没人让它碰的文件；一个根本没有项目说明，每个任务都重新发明你们的约定。经典的「在我机器上能跑」，悄悄变成了「这个 Agent 在我机器上能跑」。
这几乎和模型质量无关。Codex 很擅长执行任务。问题在于 Codex 的配置就是配置，而配置一旦不止一个人持有副本，就会漂移。让工程师共用一套配置，是工作流问题，不是模型问题：怎么让每个工程师的 Codex 加载同一套说明、护栏和上下文，又不让最先搭它的那个人从此全职维护？
你已经有 Codex。本文回答的是团队怎么跑一套 Codex 配置，而不是 N 套各自漂移的。其中一部分是纯粹的 Git 纪律，应该先做。剩下的部分，也就是任务和审阅多到没人看得过来时开始崩的部分，是 HiFox 这类共享层的位置。HiFox 在 Agent 之上：Codex 执行，HiFox 托住共享的角色、规则、上下文和审阅。下面一步步走手工版，指出每一步的失败模式，再说明基于文件的做法在哪儿不够用。
「一套 Codex 配置」到底包含什么
要共享一套配置，先得知道配置是什么。一套 Codex 配置其实是四样东西，工程师常常把它们当成一样：
- 项目说明放在仓库根目录的
AGENTS.md：你们的约定、跑测试的命令、Agent 绝不能碰的东西。这是 AGENTS.md 标准，Codex 每次运行都会读。 - 行为配置放在
~/.codex/config.toml：默认模型、approval_policy、sandbox_mode，以及按工作类型命名的[profiles.*]。 - 工具访问放在同一个配置的
[mcp_servers.*]条目里，把 Codex 指向你们的内部 API、数据库或搜索。 - 提示词和任务描述，也就是工程师实际敲进去的内容，几乎从来没有被写下来过。
漂移来自这些东西放在哪。项目说明在仓库里，所以会跟着克隆走。其余默认在各人的主目录；Codex 也支持受信任项目里的 .codex/config.toml，但 profiles、模型供应商等仍要放在用户级，团队共享仍需要约定。这个分裂是主要问题，也告诉你先修什么。
把配置放进仓库，一步一步来
不管后面还采用什么，基于文件的修法都值得做。每一步都把配置的一部分从私人机器搬进仓库，让审阅和版本历史生效。
第一步：提交 AGENTS.md，把它当代码对待。在仓库根目录放一份真正的 AGENTS.md，写清构建和测试命令、目录约定、硬边界。像审 CI 配置一样，在 pull request 里审它的改动。
失败模式：一份只写愿望、不写命令的 AGENTS.md。如果它写「遵循我们的风格」，而不是「结束前跑 npm run lint」，每个工程师的 Codex 会用不同方式补空，你绕一圈又回到漂移，还多了几步。
第二步：把共享配置档签进仓库。Codex 默认读每个用户自己的 ~/.codex/config.toml，也支持受信任项目里的 .codex/config.toml，但 profiles、模型供应商等仍要放在用户级。你可以把一份参考 codex/config.toml 提交到仓库，让每个工程师复制或软链该一致的部分。固定模型，定义命名配置档，让「审阅档」对每个人都意味着同一件事。
命名配置档也可以放在 ~/.codex/<name>.config.toml，用 codex --profile <name> 选择；本文的 [profiles.*] 写法以 Codex 当前文档为准。模型名以团队订阅和 Codex 当前 Models 页为准。只有明确无人值守的运行才用 approval_policy = "never"，代价是不再逐次拦截危险操作。
# codex/config.toml: committed reference, symlinked into ~/.codex/
model = "gpt-6.1-sol"
[profiles.review]
approval_policy = "on-request"
sandbox_mode = "read-only"
[profiles.build]
approval_policy = "on-request"
sandbox_mode = "workspace-write"
失败模式：某个工程师为了快，在本地跑 danger-full-access 沙箱或 approval_policy = "never"。共享文件没有任何强制力，于是团队里最松的那套配置，最终会交付没人审过的东西。键名以 Codex 当前文档为准；CLI 变得很快，过期的键会悄悄不生效。
第三步：给 MCP 服务器做版本化。把 [mcp_servers.*] 定义放进同一份提交的参考配置，让每个工程师的 Codex 接到同样的工具。密钥放在配置读取的环境变量里，绝不写进文件本身。
失败模式：一半人有内部文档 MCP 服务器，一半人没有，于是 Codex 对同一个问题给出两种答案，谁也说不出为什么。
第四步：用 worktree 隔离每个人的运行。几个人把 Codex 指向同一个仓库后，并发编辑就会撞。给每个 Codex 任务自己的 git worktree，避免并发运行直接写同一个目录；两个任务改同一文件时，合并阶段仍要处理冲突。这也是并行 Agent 的 worktree 隔离的常规做法，具体机制见面向 AI 编程 Agent 的 git worktree。
失败模式：两个 Agent 在同一个目录里，一次 stash，然后花一个下午重建哪个改动来自哪个任务。
基于文件的做法从哪儿不够用
四步都做完，你解决了配置共享。每个工程师的 Codex 现在加载同样的说明、护栏和工具。你没解决的是工作共享，而这个天花板比多数团队预想的来得快。
Git 共享文件，不共享正在运行的工作的状态。团队一天派发几个 Codex 任务之后，吃掉你时间的问题不在任何配置文件里：
- 现在哪个 Agent 在跑哪个任务，跑在谁的机器上？
- 你开会时什么完成了，什么在等人？
- 哪次运行碰了支付模块，到底有没有人审过它的 diff？
- 两个工程师给 Codex 派了重叠的任务，谁在合并冲突之前发现？
这些活在零散的终端、私人的提示词历史和一条 Slack 线程里。提交了的 AGENTS.md 一个都回答不了，因为缺的产物是工作的共享记录，不是配置的。这是团队规模越过的那个点，再整齐的 TOML 也修不好。
共享任务层补上什么
这就是 HiFox 的位置，边界值得说准。HiFox 不替代 Codex；它是 Codex 外面的共享任务、电脑、上下文和审阅层。Codex 仍然执行，HiFox 让这次执行可以被全队分配和审阅。
任务是 HiFox 里工作的基本单位，把目标、diff、讨论和审阅放在一个地方，而不是拆散在私人提示词和终端里。Agent 是一份可复用的工作配置：它把过去散在各人 AGENTS.md 里的说明和规则保存成一份共享配置，对全队一致、可检查；版本管理仍在 Git 里。Codex 跑一个任务时，执行、阻塞和结果都回到那个任务，于是「什么完成了、什么需要人」不再是你去 Slack 里问的问题。
要守住的是分工。Agent 调研、执行、测试、汇报；人定方向、授权、验收结果。自动化停在需要团队判断的地方。任务级的审批门和人工审阅变成共享工作流的一部分；Codex 自己的 approval_policy 仍由每个工程师的本机配置决定，团队要用清单和审计去对齐。
诚实的判断：如果团队只有一两个工程师、在一个仓库上跑 Codex，上面那套基于文件的配置就够了，共享任务层还是你暂时不需要的开销。当你跨许多任务和仓库跑多个 Agent、审阅 Agent 产出成了瓶颈，或者你希望工作流能熬过下一个最好的 Agent 时，等式就变了。HiFox 对供应商中立：同一个任务和审阅模型，今天跑 Codex，下个季度跑别的，都成立。如果团队正往这个方向走，HiFox 的并行 Agent 管理就是围绕这个问题做的；Agent 怎么承载项目配置也有单独说明。
今天就能跑的清单
按顺序往下做。前四步一个下午能做完；后两步是你已经超出文件能力的信号。
- 写一份真正带命令、不带愿望的
AGENTS.md，放进 pull request 审阅。 - 提交一份参考
config.toml，固定模型，给审阅和构建分别命名配置档。 - 把 MCP 服务器定义搬进这份提交的配置；密钥留在环境变量里。
- 给每个 Codex 任务自己的 worktree，避免并发运行直接写同一个目录；两个任务改同一文件时，合并阶段仍要处理冲突。
- 审计有没有人在跑比团队约定更松的审批策略。如果有，说明文件并没有在强制你的配置。
- 数一数你在聊天里问「Agent 现在在干什么」的频率。当这个问题每天出现，就该把工作、而不只是配置，搬进共享层。
大部分你可以用 Git 和 worktree 手工搭。等工作超出文件能追踪的范围，就把现有的 Codex 配置接到 HiFox 里跑，让任务和审阅待在全队都看得见的一个地方。
HiFox
