Codex

Claude CodeからCodex CLIを非対話で実行する。依頼文の「呼び名・effort・fast」から引数を決め、毎回すべて明示して実行する。~/.codex/config.tomlの既定値には頼らない。

呼び名

呼び名	-m	使えるeffort
sol	gpt-6.1-sol	low, medium, high, xhigh, max
astra	gpt-6-astra	low, medium, high, xhigh, max
luna	gpt-6-luna	low, medium, high, xhigh, max

gpt-6-sol、gpt-5.6系、effortのultraは使わない。

依頼文の読み方

書き方は<呼び名> [<effort>] [fast]。大文字と小文字は区別しない。例: sol、astra xhigh、luna low、sol high fast。

要素	省略したとき	指定したとき
呼び名	sol（「Codexで」だけのときも）	表の-mの値
effort	medium	-c model_reasoning_effort=<effort>
fast	-c 'service_tier="default"'（通常の速さ）	-c 'service_tier="priority"'（Fast。速さ2倍、使用量も増える）

表にない呼び名やeffort（ultraなど）が指定されたら、実行せずに、使える値を示して止まる。

実行

codex exec -m <slug> -c model_reasoning_effort=<effort> -c 'service_tier="<default|priority>"' \
  -C <作業ディレクトリ> -s <sandbox> \
  -o <作業ディレクトリ>/.tmp/codex/<YYYYMMDD-HHMMSS>.md \
  "$(cat <<'PROMPT'
<プロンプト>
PROMPT
)" </dev/null

• service_tierの値は、TOMLの文字列になるよう、-c 'service_tier="default"'のように単一引用符で囲んで二重引用符ごと渡す。
• プロンプトは、上のように引用符付きのheredoc（<<'PROMPT'）で渡す。二重引用符で直接囲むと、プロンプト中のバッククォートや$がシェルに展開されてしまう。
• 標準入力は</dev/nullで閉じる（codex execは、パイプされた標準入力を<stdin>ブロックとしてプロンプトに足すため、EOFまで待ってしまう）。
• 作業ディレクトリ: 既定は現在の作業ディレクトリ。実行の前にgit -C <作業ディレクトリ> rev-parse --is-inside-work-treeで確かめ、Gitリポジトリの外なら--skip-git-repo-checkを付ける（付けないとNot inside a trusted directoryで失敗する）。
• sandbox: 調査、レビュー、相談はread-only。ファイルの変更を頼まれたときだけworkspace-writeにする。--dangerously-*系のオプションは使わない。
• 出力先: -oで最後の返答をファイルに受け取る。先にmkdir -p <作業ディレクトリ>/.tmp/codexを実行しておく。
• 時間: 2分を超えそうな依頼は、Bashのrun_in_backgroundで実行し、完了の通知を待つ。
• プロンプト: 下の「プロンプトの型」で組む。秘密情報、.env、auth.jsonの中身は入れない。

プロンプトの型

次の見出しで組む。見出しは省略しない（該当がなければ「なし」と書く）。

## ゴール
<1文。終わったとき何が成り立っているか>

## 完了条件
- <確かめられる形で。調査なら「〜の答えと、根拠のファイル:行」、実装なら「〜のテストが通る」「〜が表示される」>

## 範囲
- 対象: <ファイル、ディレクトリ、URL>
- 変更: <してよい／しない。してよいなら、触ってよいファイル>
- やらないこと: <広げてほしくない方向>

## 背景
<判断に必要な事実だけ。経緯の全文は貼らない>

## 出力
<返答の構成。例: 結論 → 根拠 → 未確認の点>

## 止まる条件
完了条件をすべて満たしたら、そこで止まって報告する。範囲の外の変更が必要なとき、または判断が分かれる点に当たったときは、推測で進めずに、その時点までの結果と論点を報告する。

• ゴールと完了条件は、ユーザーの依頼を言い直して作る。依頼にない目的を足さない。
• ゴールは手順ではなく結果で書く。
• 完了条件には確かめ方（実行するコマンド、再現手順）も書く。
• 依頼からゴールか完了条件を決められないときは、Codexを呼ぶ前にユーザーに確認する。
• 長い指示書を.tmp/plan/などのファイルにして渡す場合も、同じ見出しにする。

結果の扱い

• -oのファイルを読んで、要点を報告する。使ったモデル、effort、速度も添える。
• 返答を完了条件と照らし合わせ、満たしていない条件があればそう報告する。
• Codexの返答は報告であって、証拠ではない。ファイルの変更、テストの結果、出典などは、必要に応じて自分で確かめてから事実として扱う。
• workspace-writeで実行したら、git statusとgit diffで変更を確かめてから報告する。
• 実行に失敗したら（例: 400 model is not supported）、エラー文をそのまま報告し、勝手に別のモデルに切り替えない。