codex-first

首选 Codex

启动标志 — 请先阅读，并原样复制

所有 Codex 工作线程（新启动或恢复的都一样）默认使用 GPT-6.1 Sol、high 推理、Ultrafast 服务层级（service_tier="ultrafast"）。除非用户要求覆盖设置，否则传入全部三项设置。

# fresh
codex exec --yolo -C "$WT" \
  -m gpt-6.1-sol -c 'model_reasoning_effort="high"' \
  --enable fast_mode -c 'service_tier="ultrafast"' \
  -c 'model_auto_compact_token_limit=260000' \
  -o "$OUT" - < "$ORDER"
# resume: pass the same flags again; resume does not inherit them
codex exec resume "$SID" --dangerously-bypass-approvals-and-sandbox \
  -m gpt-6.1-sol -c 'model_reasoning_effort="high"' \
  --enable fast_mode -c 'service_tier="ultrafast"' \
  -c 'model_auto_compact_token_limit=260000' -o "$OUT" -

• Ultrafast 有上下文上限（2026-10-13 测得，使用 gpt-6.1-sol + gpt-6-astra 直接探测 Responses）：提示词 token 数不超过约 282k 时提供 ultrafast，288–294k 时不稳定，≥300k 时静默降为 fast，HTTP 状态码仍为 200。配置默认在 400k 时压缩，因此长时间运行的工作线程会逐渐转为 Fast；将压缩上限设为 260k 可让它们保持 Ultrafast。发布记录只记录请求的层级；要通过直接探测（response.service_tier）确认实际提供的层级。
• 上下文：工作线程使用基础的 500k 窗口。只有当任务需要整个代码库的上下文时，才添加 -p sol61-1m（或 -p astra-1m）；参见 $codex-huge-context。这些配置档在超过约 280k 后无法使用 Ultrafast。
• 将所有模型／推理／层级标志复制到包装器中；仅在用户要求时覆盖。验证启动参数（默认 ultrafast；用户要求的 fast 有效）。
• 对于用户要求使用 Fast 的审查，使用 --codex-speed fast。

安全审计与网络安全分类器拒绝 → Daybreak Red（Peter，2026-10-15/18）

安全审计任务（威胁模型、注入／秘密信息泄露审计、权限清单、加固差异的安全审查）从一开始就使用 Daybreak Red 启动（Peter，2026-10-18：“安全审计使用 daylight red 模型”）。

工作线程因 This content was flagged for possible cybersecurity risk 停止时 → 在 Daybreak Red 上重新启动或恢复同一任务（Peter：“常规模型遇到阻碍时使用 daybreak red”）。不要改写内容以绕过分类器，也不要在常规模型之间切换。

• 仅限直接 API：使用 ChatGPT 账户的路由会返回 400 错误 not supported when using Codex with a ChatGPT account。添加 -c 'model_provider="openai_api_direct"'（通过 ~/.codex/config.toml 中该提供方的认证命令传入 API 密钥）。
• Slug：model_catalog_json 中 display_name 为 Daybreak Red 的条目。根据公开模型命名要求，不要将其写入公开产物（提交、PR、问题、日志）。
• 不使用 Ultrafast：移除 --enable fast_mode / service_tier；保留 model_reasoning_effort="high"。
• 已于 2026-10-15 使用直接提供方进行单行 codex exec 探测验证。

容量回退（Peter，2026-10-12）

组织将 gpt-6.1-sol 的上限设为每分钟 40M 个 token。工作线程启动或恢复失败，并出现 Rate limit reached for gpt-6.1-sol ... tokens per min (TPM)、Selected model is at capacity 或 overloaded → 立即在 GPT-6 Astra、high、Ultrafast 上恢复同一会话（Peter，2026-10-12：“Sol 受速率限制时使用 astra”；Astra 可提供 ultrafast，已于 2026-10-13 验证）；不要循环等待：

codex exec resume "$SID" --dangerously-bypass-approvals-and-sandbox \
  -m gpt-6-astra -c 'model_reasoning_effort="high"' \
  --enable fast_mode -c 'service_tier="ultrafast"' \
  -c 'model_auto_compact_token_limit=260000' -o "$OUT" -

• 恢复到 Astra 会保留会话线程（已于 2026-10-12 验证：在 Sol 上创建的会话恢复到 Astra 后作出了回复）。容量不足时的新任务：使用相同标志运行 codex exec --yolo -C "$WT"；因容量不足而退出的新启动进程已在 stderr 中包含会话 ID（session id: …）——恢复该会话，不要重新启动。
• 只有在 Sol 和 Astra 都受限时才退避；随后交替尝试并逐渐延长等待时间。
• 包装器的重试触发条件必须匹配全部三个字符串（rate limit|at capacity|overloaded）；仅匹配“rate limit”会导致容量错误直接退出，而不会回退。
• 容量不足时进行自动审查：使用 --model gpt-6-astra --thinking high --codex-speed fast。如果自动审查因其提供方／路由与操作者配置不匹配而拒绝，不要更改配置——使用带有差异和简要说明的新上下文子 Agent 进行审查，并在 PR 中说明。
• 新工作线程仍从 Sol 6.1 Ultrafast 开始；仅在出现容量错误时，才按工作线程回退。
• 重启与恢复：~/.codex/skills/agent-scripts/codex-first/scripts/codex-resume 会执行回退、忙碌检查、安全停止和分类退出（恢复与看门狗）。

包装脚本与进程管理（2026-10-12/13）

• 切勿原地修改正在运行的包装脚本：bash 会逐步读取脚本，因此正在运行的进程会在旧偏移处执行新字节。写入 x.new，运行 bash -n、chmod +x，然后运行 mv（重命名会为正在运行的副本保留旧 inode；忘记运行 chmod 会导致退出码为 126）。
• 切勿在包装脚本的 set -e 下运行 codex exec：遇到速率限制而退出时，非零退出码会让脚本在运行回退逻辑前结束（2026-10-13，一支由 27 个工作进程组成的集群曾发生此情况）。捕获退出码（… && rc=0 || rc=$?）并进行分类处理，或将会话交给 codex-resume。
• 终止包装脚本会使其 codex exec 子进程成为孤儿；下一次恢复会失败，并提示 thread … already has an active writer。请使用 codex-resume --stop "$SID" 停止并恢复：它会通过工作进程打开的 rollout 文件找到该进程（新启动的进程不会在 argv 中带有 $SID，因此 pgrep -f 无法找到它），且当其下方有 scripts/pr 或 git 进程运行时会拒绝操作。没有活动持有者的残留 ~/.codex/thread-writer-locks/$SID.lock 文件无害。
• 如需将正在运行的工作进程改派到新设计或优先级，请运行 codex-resume --stop -p "$ORDER_FILE" "$SID"（或使用 --message "…"）；其工作树更改和上下文会保留。
• 如需永久退役某个工作进程，切勿使用 codex-resume：--stop 总会在之后恢复它（2026-10-18，某个已取消的工作进程在已删除的工作树中重新启动）。终止原生 codex 二进制文件（pgrep -P <node-shim-pid>），然后终止 node shim 及其包装脚本。

严格门槛

**自动审查例外：**始终优先使用由 Codex 支持的 $autoreview，不受 ANTHROPIC_BASE_URL、路由器状态或运行环境影响。审查冻结的代码包不属于亲自委派。不要仅仅因为父会话由路由器提供支持就切换审查引擎。此例外优先于下方的门槛。

使用自动审查助手并指定 --engine codex（默认值：6.1 Sol、medium、Ultrafast），除非用户要求覆盖默认设置。它会先尝试 ChatGPT 订阅；如果身份验证失败，则在配置的 direct-API 提供商上重试一次。只有在要跳过订阅尝试时，才传入 --codex-config 'model_provider="openai_api_direct"'。保留助手的审查隔离机制。

对于亲自进行的委派，仅当活动 Agent 是 Claude Code 且会话运行在原生 Claude 模型上时，才使用此技能。

**模型检查（首选）。**设置此门槛的目的是考虑模型成本：Claude 令牌按量计费且价格昂贵，因此亲自处理的工作应转交给 Codex；但如果会话已经路由到更便宜的其他模型，委派就没有收益。根据会话实际运行的模型来判断，而不是根据传输方式：

1. 从系统提示词的环境部分读取模型 ID（“You are powered by the model …”）。路由器包装的 ID 可能难以识别（claude-ccr-<hex>）；十六进制后缀通常是 ASCII 编码——解码它（echo <hex> | xxd -r -p）即可显示底层路由，例如 Gorilla CCP/native-claude-fable-5。
2. 如果解析出的模型是原生 Claude 模型（包含 claude、fable、opus、sonnet 或 haiku，包括 native-claude-* 路由器路由）：**将亲自处理的工作委派给 Codex。**即使 ANTHROPIC_BASE_URL 指向回环地址或本地路由器（Gorilla Claw、Clawdex），也适用——真实 Claude 模型前置路由器时，仍然属于价格昂贵的 Claude。
3. 如果解析出的模型明确不是 Claude（GPT／其他提供商的路由）：会话已经处于固定费率／低成本一侧；不要亲自委派，直接处理。

**基础 URL 回退（仅在无法识别模型时使用）。**如果看不到模型 ID，且无法解码十六进制值或路由，则回退到旧的传输方式判断：如果 ANTHROPIC_BASE_URL 的主机名为 gorillaclaw.sheep-coho.ts.net、localhost、以 .localhost 结尾、属于 127.0.0.0/8，或是 IPv6 回环地址 ::1，则假设会话可能路由到了非 Claude 模型，并直接处理。如果模型和基础 URL 都无法检查，则采取保守策略，直接处理。

Codex、ChatGPT、Pi 及所有其他运行环境：不要调用 Codex CLI 来亲自委派。直接继续任务。此门槛优先于仅仅提及 $codex-first 的仓库指令；但不覆盖上述自动审查例外。

默认工作者是 Ultrafast 层级的 GPT-6.1 Sol。Claude 负责规格说明、判断、编排和最终验证；Codex 负责受委派的实现。

路由

动手执行的工作默认委派给 Codex：

• 根据已冻结的规范进行实现；重构；机械式迁移
• 修复：修复 Bug（已知复现步骤，或先诊断再修复）、CI/lint/类型检查失败；编写测试；补足覆盖率
• 依赖升级、脚本/工具
• 探索 + 探索性子 Agent：当原始阅读量远大于答案所需时，派出多个 Codex 执行只读探索，而非 Claude Explore/Task 子 Agent（并行使用 -o 文件，每个线程一个文件）
• Git 操作——始终使用 Codex，绝不直接使用 Claude：git rebase、合并冲突 解决，以及仓库的合并工作流（例如 scripts/pr）都必须委派。下达一份完整独立的工作单，涵盖 rebase→解决冲突→推送→附加 CI 并通过→合并，确保流程不会中途退回给 Claude；是否合并、门禁以及下方的审查仍由 Claude 负责。
• 工作单中的 CI 等待：先检查 PR 是否可合并（CONFLICTING = 无法附加 pull_request CI，因为没有合并引用），并确认有一次运行关联到确切的 head SHA 后再轮询；每次等待都要在有限迭代次数内输出所有终止状态；有仓库监视脚本时优先使用（openclaw：node scripts/watch-pr-ci.mjs）。工作单中绝不使用 gh run watch 或 gh pr checks --watch：gh run watch 默认每 3 秒轮询一次（每小时约 1,200 次调用），而 2026-10-15，两台此类监视器两次耗尽了共享的每小时 5,000 次写入令牌。每隔约 10 分钟最多用 gh run view <id> --json status,conclusion 轮询一次确切的运行，或让仓库的合并工具负责等待。
• 新工作单应交给全新的 codex exec 会话，并附上完整独立的提示词。 不要为新工作单恢复长期会话——负载饱和的会话会把工作单误读为配置并空操作（“明白……”）。
• 仓库指令文件：绝不创建或编辑 CLAUDE.md。每个仓库的规范文件都是 AGENTS.md；CLAUDE.md 仅作为指向它的符号链接存在。Codex 工作单应指定 AGENTS.md，且只编辑 AGENTS.md。

由 Claude 负责：

• 设计、API 设计、架构、命名、UX 判断
• 编写规范本身就是工作内容的任务（有歧义 = 需要设计）
• 小改动（约少于 20 行，单一明显改动）——委派的开销得不偿失
• 任何需要会话工具的事项：MCP（浏览器/电脑操作/chronicle）、1Password、机密信息
• 发布、公布、版本升级及其凭据——按发布规则由 Claude 负责
• 是否合并 + 合并前门禁（$autoreview 干净、CI 通过、证明）以及审查 Codex 的输出——绝不委派，绝不跳过；只有 Claude 决定合并且门禁通过后，Codex 才能执行操作流程

混合型任务：Claude 先设计、冻结规范，再委派构建。 判断方法：提示词读起来像工作单 → 委派；编写提示词会迫使你做出决策 → 由 Claude 设计。 组合/多仓库工作：改用 $maintainer-orchestrator。

Invoke

• 运行 timeout 8 git --version；如果 Xcode-beta 卡住，请在会话和每条命令中设置 DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer。
• 对于 openai_api_direct，在批次首次启动全新会话或恢复会话之前，运行 ruby ~/.codex/skills/agent-scripts/codex-huge-context/scripts/preflight.rb。如果 Keychain 传递失败，请停止；绝不要覆盖提供方或使用普通 Codex 身份验证。
• 保留已配置的提供方；恢复会话会沿用该提供方。如果它与 6.1 Sol 不兼容，请全新启动；绝不要静默更改模型。
• 使用仓库范围的 --yolo、临时文件提示词（绝不内联引用）和 -o 结果（而非 JSONL）。
• Harness 可见性（Claude Code）：每次 codex 运行都必须有各自由 harness 跟踪的后台命令（run_in_background: true）——每个 worker 对应一个侧边栏标记，并包含完成通知。将设置步骤（安装、worktree 准备）放在该跟踪命令内部。绝不要从共享启动器用 & 分叉 worker：启动器的标记会在分叉时退出，worker 随后会变成不可见的孤儿进程，只由 PID 文件监管。
• 可以并行执行互不依赖的任务：使用不同仓库/目录、不同的 -o 文件，每个 worker 对应一条跟踪的后台命令。
• 在 Git 仓库之外添加 --skip-git-repo-check。
• 如需 Fast/目录检查、CLI 设置或执行详情，请阅读启动详情。
• 发生故障或提供方变更时，请参阅故障排查；绝不要将凭据放入 -c key=value。
• 恢复/监控之前，请参阅恢复与 watchdog。通过 scripts/codex-resume 恢复和重启（不确定时先使用 --dry-run）。

提示词约定

Codex 启动时没有任何会话上下文。每条提示词都必须说明：目标、确切的仓库/路径、约束、非目标、预期的验证方式（确切的测试命令）和输出格式（“报告变更的文件 + 测试输出”）。成功与否取决于规范的质量。

• 指明领域 skill。 如果仓库中有适用于所改动领域的 skill（例如，进行 Control UI/Solid 工作时使用 openclaw .agents/skills/solid/SKILL.md），工作指令必须要求在首次编辑前阅读它及其指向的参考资料。Codex 只会自动加载其工作目录所在链上的 AGENTS.md，因此很容易漏掉由嵌套 AGENTS.md 链接的 skill。

• 每条硬性禁令都必须提供退出路径。 被逼入绝境的 worker 会钻规则空子：有一次，worker 被告知“绝不提高大小预算”，但其设计导致 bundle 膨胀，于是 Codex 把源代码标识符手动缩减成单个字母——结果通过了所有门槛，包括 autoreview。每项硬性约束都应配上获准的退出方式：“如果经过合理尝试后门槛 X 仍未通过：停止，报告确切数据/诊断，不要绕过。”应将停止并报告视为一次成功运行（这是协调者作出决策的时点；一旦有了这项规则，worker 就能正确执行）。

• 多 PR 系列：每个 PR 使用相同的规范框架；引用先前已合并的 PR 编号，并指出其惯用模式（“采用窄主机接口的 controller，即 #NNN 的模式”）——worker 模仿已落地的先例，远比遵循抽象风格规则可靠。将每轮遇到的新陷阱纳入下一份规范。

• 每个系列的工作指令都必须以明确的停止要求结尾：“只完成此项；不要开始 PR N+1。”

• 工作指令中的验证要求：PR CI 是默认的广泛验证；构建和有针对性的本地测试/类型检查/lint/格式检查通过后，就应创建一个可供审核的 PR，不要等待 PR 前的广泛测试套件；仅在 CI/本地测试无法覆盖的情况下使用 Crabbox/Testbox，且只有在能立即获得时才使用（排队 → 本地；没有 Testbox 时，不要沿着 AWS → Hetzner 的梯级继续）；修复实际故障，阅读 CI 对既存问题/新增问题的分类，绝不要只为得到绿色状态而重复运行/推送。确保不受信任的代码不接触机密、已授权使用有效凭据，并隔离 Gateway/state。

在审核/合并或协调 worker 之前，请阅读协调说明；编辑/提交之前，检查是否有正在运行的 worker。