codex-first

Codex First

起動フラグ — まず読んで、そのままコピーしてください

すべての Codex ワーカー（新規・再開を問わず）のデフォルトを、GPT-6.1 Sol、高い推論レベル、Ultrafast サービスティア（service_tier="ultrafast"）にしてください。ユーザーが上書きを求めない限り、3つの設定をすべて指定してください。

# 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 に直接 Responses プローブで測定、gpt-6.1-sol + gpt-6-astra）：ultrafast は約282kのプロンプトトークンまで提供され、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 モデルを使用」）。

実装ワーカーはSolのままにしてください。

ワーカーがThis content was flagged for possible cybersecurity riskで停止した場合は、同じ指示でDaybreak Redを使用して再起動または再開してください（Peter：「通常のモデルで行き詰まったら daybreak red を使用」）。分類器を回避するために言い換えたり、通常モデル間を切り替えたりしないでください。

• 直接APIのみ：ChatGPTアカウント経由のルートは、not supported when using Codex with a ChatGPT accountという400エラーを返します。-c 'model_provider="openai_api_direct"'を追加してください（APIキーは~/.codex/config.tomlでプロバイダーの認証コマンドを使って設定します）。
• スラッグ：display_nameがDaybreak Redのmodel_catalog_jsonエントリです。公開される成果物（コミット、PR、issue、ログ）には含めないでください（公開モデルの命名規則に従ってください）。
• Ultrafastは使用しないでください：--enable fast_mode／service_tierを削除し、model_reasoning_effort="high"は維持してください。
• 2026-10-15に、directプロバイダー上で1行のcodex execプローブを使って検証済みです。

キャパシティ不足時のフォールバック（Peter、2026-10-12）

組織の上限はgpt-6.1-solで毎分40Mトークンです。ワーカーまたは再開時にRate limit reached for gpt-6.1-sol ... tokens per min (TPM)、Selected model is at capacity、またはoverloadedで失敗した場合は、同じセッションをすぐにGPT-6 Astra、高い推論レベル、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"と同じフラグを使用してください。キャパシティ不足で新規起動に失敗した場合、標準エラー出力にはすでにセッションID（session id: …）があります。再起動せず、そのセッションを再開してください。
• SolとAstraの両方が制限されている場合に限り、待機してください。その場合は、待機時間を徐々に増やしながら交互に再試行します。
• ラッパーの再試行条件には、3つすべての文字列（rate limit|at capacity|overloaded）を含める必要があります。「rate limit」のみを照合すると、キャパシティ不足による失敗で終了し、フォールバックされませんでした。
• キャパシティ不足時の自動レビューには、--model gpt-6-astra --thinking high --codex-speed fastを使用してください。自動レビューのプロバイダー／ルートがオペレーターの設定と一致せず拒否される場合は、設定を変更しないでください。新しいコンテキストのサブエージェント（差分＋概要）でレビューし、その旨を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 ファイルを使ってワーカーを特定します（新規起動時は $SID が argv に含まれないため、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 とそのラッパーを終了してください。

厳格なゲート

自動レビューの例外： ANTHROPIC_BASE_URL、ルーターの状態、ハーネスに関係なく、常に Codex ベースの $autoreview を優先してください。凍結されたバンドルのレビューは、実作業の自己委任ではありません。親セッションがルーターベースだからといって、レビューエンジンを切り替えないでください。この例外は、以下のゲートより優先されます。

ユーザーが上書きを要求しない限り、--engine codex を指定して自動レビューのヘルパーを使用してください（デフォルト：6.1 Sol、medium、Ultrafast）。まず ChatGPT サブスクリプションを試し、認証に失敗した場合は、設定済みのダイレクト API プロバイダーで 1 回再試行します。サブスクリプションの試行をスキップする場合に限り、--codex-config 'model_provider="openai_api_direct"' を渡してください。ヘルパーのレビュアー分離を維持してください。

実作業の直接委任では、アクティブなエージェントが Claude Code であり、かつセッションがネイティブの Claude モデルで実行されている場合にのみ、このスキルを使用してください。

モデルの確認（優先）： このゲートの目的はモデルのコストです。Claude のトークンは従量課金で高価なため、実作業は Codex に委任します。しかし、セッションがすでに低コストのモデルまたは別のモデルにルーティングされているなら、委任しても利点はありません。トランスポートではなく、セッションが実際に実行されているモデルに基づいて判断してください。

1. システムプロンプトの環境セクション（「You are powered by the model …」）からモデル ID を読み取ります。ルーターでラップされた ID は不透明な場合があります（claude-ccr-<hex>）。16 進数のサフィックスは ASCII であることが多いため、デコードして（echo <hex> | xxd -r -p）、たとえば Gorilla CCP/native-claude-fable-5 のような基盤のルートを確認してください。
2. 解決されたモデルがネイティブの Claude モデルの場合（ルーターの native-claude-* ルートを含め、claude、fable、opus、sonnet、haiku のいずれかを含む場合）：実作業を Codex に委任してください。 ANTHROPIC_BASE_URL がループバックまたはローカルルーター（Gorilla Claw、Clawdex）である場合も同様です。実際の Claude モデルの前段にルーターがあっても、Claude は依然として高コストです。
3. 解決されたモデルが明らかに Claude 以外（GPT／他プロバイダーのルート）の場合：セッションはすでに定額または低コストの環境にあるため、自己委任せず、直接作業してください。

ベース URL のフォールバック（モデルを特定できない場合のみ）： モデル ID が見えず、16 進数またはルートをデコードできない場合は、従来のトランスポート判定にフォールバックしてください。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 に委任します。

• 固定された仕様に基づく実装、リファクタリング、機械的な移行
• 修正：バグ修正（再現手順が既知のもの、または原因を特定してから修正するもの）、CI／lint／型の失敗、テスト作成、カバレッジの補完
• 依存関係の更新、スクリプト／ツール
• 調査＋探索用サブエージェント：読み込み量が回答内容を大きく上回る場合は、Claude Explore／Task サブエージェントではなく、読み込み中心の調査を Codex に並列で振り分けます（スレッドごとに 1 つの -o ファイル）。
• git の操作 — 必ず Codex に委任し、Claude が直接行うことはありません：git rebase、マージコンフリクトの解消、リポジトリの land ワークフロー（例：scripts/pr）は、必ず委任します。途中で Claude に差し戻されることがないよう、rebase→解消→push→CI の紐付けと成功確認→land までを網羅した、自己完結した作業指示を 1 つ発行します。land の判断、ゲート、以下のレビューは 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 には 2 つのウォッチャーが共有の 5,000 回／時の writer トークンを 2 度枯渇させました。正確な実行 1 件を gh run view <id> --json status,conclusion でポーリングするのは約 10 分ごとまでとするか、リポジトリの land ツールに待機を任せます。
• 新しい作業指示は、自己完結したプロンプトを用意して、必ず新規の codex exec セッションに送ります。新しい指示に長時間稼働中のセッションを再利用してはいけません。飽和したセッションは作業指示を設定と誤読し、何もせずに「了解しました…」と返すことがあります。
• リポジトリの指示ファイル：CLAUDE.md は絶対に作成・編集しません。すべてのリポジトリで AGENTS.md が正本であり、CLAUDE.md は AGENTS.md へのシンボリックリンクとしてのみ存在します。Codex の作業指示では AGENTS.md を指定し、編集するのは AGENTS.md のみとします。

Claude が担当するもの：

• 設計、API 設計、アーキテクチャ、命名、UX の判断
• 仕様を書くこと自体が作業となるタスク（曖昧さがある場合は設計）
• 小さな編集（約 20 行未満で、変更内容が 1 つに明確に定まるもの）— 委任のオーバーヘッドが上回ります
• セッションツールが必要な作業：MCP（ブラウザー／コンピューター操作／chronicle）、1Password、シークレット
• リリース、公開、バージョン更新、およびそれらの認証情報 — リリースルールに従い、Claude 側で実施します
• land の判断と land 前のゲート（$autoreview がクリーン、CI が成功、証明が揃っていること）、および Codex の出力のレビュー — 委任も省略もできません。Claude が land を決定し、ゲートを通過した後に限り、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 を使用し、プロンプトは一時ファイル経由で渡します（インラインで引用符を使わないでください）。結果には JSONL ではなく -o を使用します。
• ハーネスの可視性（Claude Code）：Codex の実行ごとに、ハーネスで追跡される独自のバックグラウンドコマンドを割り当てます（run_in_background: true）。ワーカーごとにサイドバーのチップが 1 つ表示され、完了通知も含まれます。セットアップ手順（インストール、worktree の準備など）は、追跡対象のコマンド内で実行します。共有ランチャーから & でワーカーをフォークしないでください。フォーク時点でランチャーのチップが終了し、ワーカーは不可視の孤立プロセスとなり、PID ファイルだけで監視されることになります。
• 並行して実行してよい独立タスク：リポジトリ／ディレクトリを分け、-o の出力ファイルも分け、ワーカーごとに追跡対象のバックグラウンドコマンドを 1 つ割り当てます。
• Git リポジトリの外では --skip-git-repo-check を追加します。
• Fast／catalog の確認、CLI のセットアップ、実行の詳細については、起動の詳細を参照してください。
• 失敗時やプロバイダーの変更時は、トラブルシューティングを参照してください。-c key=value に認証情報を記述しないでください。
• 再開／監視の前に、再開とウォッチドッグを参照してください。再開と再起動には scripts/codex-resume を使用します。不確かな場合は、まず --dry-run を実行してください。

プロンプトの要件

Codex はセッションコンテキストがゼロの状態で開始します。すべてのプロンプトに、目的、対象リポジトリ／パス、制約、対象外の内容、求める証明（テストコマンドを正確に記載）、出力形式（「変更したファイルとテスト出力を報告」）を含めます。成功を左右するのは仕様の質です。

• 対象領域のスキルを明記します。 変更対象の領域にリポジトリ固有のスキルがある場合（たとえば、Control UI／Solid の作業における openclaw の .agents/skills/solid/SKILL.md）、作業指示には、最初の編集前にそのスキルと、そこから参照されるドキュメントを読むよう記載します。Codex が自動で読み込むのは作業ディレクトリからの AGENTS.md の連鎖だけなので、ネストされた AGENTS.md からリンクされているスキルは見落としやすいです。

• 厳格な禁止事項には必ず回避策を設けます。 追い詰められたワーカーは、ゲートの文言を守るために設計を歪めることがあります。たとえば、バンドルサイズが増える設計に対して「サイズ上限を絶対に増やすな」と指示したところ、Codex はソース内の識別子を 1 文字に手作業で縮め、autoreview を含むすべてのゲートを通過しました。各制約には、認められた終了条件を併記します。「誠実に試みた後もゲート X に失敗した場合は、停止し、正確な数値と診断を報告し、回避策を講じないこと」。停止して報告することも成功した実行として扱います（これはコーディネーターが判断するための情報であり、終了条件を設ければワーカーは適切に対処します）。

• 複数 PR にまたがるシリーズでは、各 PR で同じ仕様の骨格を使います。すでに取り込まれた PR 番号を挙げ、その慣用パターンを名前で示します（「ホストインターフェースを絞ったコントローラー、#NNN の形」など）。抽象的なスタイル規則より、取り込み済みの前例をワーカーははるかに確実に模倣します。各ラウンドで見つかった新たな落とし穴を、次の仕様に反映します。

• シリーズの作業指示はすべて、明示的な停止条件で締めくくります。「この作業だけを行い、PR N+1 は開始しないこと。」

• 作業指示で求める証明：幅広い検証は PR CI を標準とします。ビルドと、対象を絞ったローカルテスト／型チェック／Lint／フォーマット確認が通ったら、PR 前の広範なスイートを待たずに、レビュー可能な PR を作成します。Crabbox／Testbox は、CI／ローカルで確認できない不足分に限り、すぐに利用許可が得られた場合のみ使用します（キュー待ちならローカルで確認します。Testbox が使えない場合に AWS、次に Hetzner と段階的に試すことはしません）。実際の失敗は修正し、CI の分類が既存の問題か新規の問題かを確認します。成功表示を得ることだけを目的に、再実行／再プッシュしないでください。信頼できないコードにはシークレットを渡さず、ライブ認証情報は許可を得て使用し、Gateway／状態を分離します。

レビュー／取り込みの前、またはワーカーを調整する前に、調整を読みます。編集／コミットの前に、稼働中のワーカーがいないか確認します。