codex execの使い方｜stdin・JSONL・権限・終了コードを実測

codex exec は、OpenAI Codex CLIを対話画面なしで実行するコマンドです。Claude Codeの claude -p に対応する入口として、ログを渡す、結果をファイルへ保存する、小さな修正を別のエージェントへ頼む、といった処理に使えます。通常は最終回答が stdout、進捗が stderr に出ます。

確認日: 2026-10-29。対象バージョン: codex-cli 0.163.0、macOS。比較対象のhelpはClaude Code 2.1.308。公式Web資料は同日取得で、CLIの全バージョンを保証する説明ではありません。

要点: 最初は -s read-only で入力と出力を確かめます。編集を任せるときは workspace-write を明示し、終了コードだけで成功とせず、差分とテストを確認してから次の仕事へ渡します。

#codex execとは何ですか？

実行する仕事を引数に書くと、Codexがその仕事を進めて終了します。Gitリポジトリで実行します。Git外での実行を許すオプションもありますが、今回は未実測です。既存のCLI認証を使えます。ここではログイン済みのMacで実行し、新しいログインやAPIキーの設定はしていません。公式の非対話モード

codex --version
codex exec --help
codex exec -s read-only 'このリポジトリの構成を説明。ファイルは変更しない'

0.163.0のhelpでは -p はprofile指定です。codex -p を claude -p と同じ非対話のスイッチとして使わず、codex exec から始めてください。helpと設定ファイルを含む実行条件を、引き継ぎ先にも残します。指示ファイルの読込範囲

#claude -pとの違いは何ですか？

次の表は、2026-10-29に取得した公式資料と両CLIのhelpを照合したものです。同じ作業の性能や安全性を比較実験した表ではありません。Codex参照、Claude Code CLI参照、Claude Codeの非対話実行

Claude Codeで会話を移す手順はコンテキストの引き継ぎにまとめています。

#標準入力でログを渡すには？

パイプで渡したログと、Codexへの指示を分けて書けます。0.163.0のhelpでは、引数の指示がある場合、パイプ入力は追加の <stdin> ブロックになります。

printf '%s\n' 'ERROR E_DEMO: missing fixture' |
  codex exec -s read-only \
    'このログの原因候補と、次に確認することを説明。コマンド実行や編集はしない' \
    > answer.txt 2> progress.txt

指示全体を標準入力から読む形は codex exec - です。入力はモデルへ渡るため、実際のログから秘密値や個人情報を除いてください。今回の合成ログでは、E_DEMO を含む場合に LOG_OK を返すよう指示し、LOG_OK が返ることを確認しました。

stdout の answer.txt には最終回答、stderr の progress.txt には進捗や診断が入ります。実測ではstderrに起動情報と、タスクでは使わないMCPの認証警告も出ました。stderrに文字があることだけでタスク失敗と判断せず、終了コードと内容を確認します。

#JSONで出力するには？ JSONLと最終回答は同じですか？

--json はイベントを1行ずつ出す JSONL です。stdout全体を一つのJSONオブジェクトとして読む用途とは分けます。最終回答だけを別ファイルに保存するには --output-last-message、短縮形では -o を使います。公式の出力仕様

codex exec -s read-only --json \
  --output-last-message answer.txt \
  'このリポジトリの概要を短く説明。変更はしない' \
  > events.jsonl 2> progress.txt

今回のworkspace-write実験では7行のJSONLが出て、thread.started、turn.started、item.started、item.completed、turn.completed を確認しました。行数やイベント順をすべてのタスクに固定しないでください。通常モードの -o は、末尾の改行を除くとstdoutと同じ最終回答を保存しました。

以下は、空の作業用git projectで試す例です。出力先に既存のファイルがあれば上書きします。最終回答のフィールドを決めたい場合は、JSON Schemaを別ファイルにします。次は構文例で、ok がtrueでも仕事の正しさを証明するものではありません。

cat > schema.json <<'JSON'
{"type":"object","properties":{"ok":{"type":"boolean"}},"required":["ok"],"additionalProperties":false}
JSON
codex exec -s read-only --json --output-schema schema.json \
  -o answer.json 'ツールは使わず、okをtrueとして返す' \
  > events.jsonl 2> progress.txt

合成実験では answer.json に {"ok":true} が保存され、JSONL内の最終メッセージとも一致しました。下流の処理でもJSONを解析し、必要なフィールドと実際の成果物を確かめます。

#read-onlyで実行するには？ 承認モードとは何が違いますか？

sandboxはコマンドが使う権限、承認設定は確認が必要な操作をどう扱うかを決めます。自動処理では両方を明示すると、引き継ぎ先が条件を追えます。never は、利用者に承認を求めない設定です。承認が必要になった操作の扱いは今回検証していません。操作全体の安全性を保証する設定としては使わず、例は独立した作業用checkoutで試してください。

codex exec -s read-only -c 'approval_policy="never"' \
  'git diffを読み、問題の候補と根拠の行を報告。編集はしない'

codex exec -s workspace-write -c 'approval_policy="never"' \
  '指定された小さな修正だけを行い、実行したテストと残件を報告'

公式の非対話ガイドは既定をread-onlyと説明しています。実測ではモードを明示しました。0.163.0のhelpにあるほかの権限設定や、承認の自動レビューは今回試していません。

合成git projectで printf PROBE > marker.txt を1回実行するよう、それぞれ指示しました。read-onlyではファイルは作られず、モデルは書き込み拒否と報告しました。ただし、その試行のJSONLにはshell実行イベントがなく、モデルが述べたshell終了コード1を独立には確認できませんでした。workspace-writeではshellイベントの終了コード0と、実ファイルの内容 PROBE の両方を確認しました。

#終了コードは何を意味しますか？

CLIの終了コードと、実行したコマンドの終了コードを分けて扱います。今回のread-only試行はファイルが作られなくても、CLIは0で終了しました。親エージェントは最終回答だけを読まず、差分・成果物・テストを確認する必要があります。

これは実行した7ケースの記録です。認証失敗、通信切断、利用上限、timeout、signal等を含む終了コードの網羅表ではありません。実測の集計JSON

テスト出力をパイプするときは、元のテストの終了コードも別に保存してください。パイプ全体やCodexの0だけから、元のテストが成功したと判断しないようにします。Hooksで終了コードを失う例

#resumeで前の仕事を続けるには？

codex exec -s read-only resume <SESSION_ID> \
  '前回の未確認点を整理。ツールは使わず、決まっていないことは残す'

<SESSION_ID> は実際のIDに置き換えます。--json の thread.started にある thread_id を親側で保存できます。今回、workspace-write試行のIDを明示して再開すると、先の指示にだけ含めた合言葉 TEAL42 が返りました。ファイルを読み直さない会話の継続を1回確認した結果で、複雑な仕事の引き継ぎ精度は未検証です。

helpには codex exec resume --last '指示' もあります。別の処理が同時に走る運用では、どの会話を続けるかを記録するため明示IDを使う案が考えられます。今回 --last は使っていません。

#別のエージェントから小さな仕事を任せるには？

親側で対象・権限・完了条件を決め、独立したgit checkout等で一件だけ渡します。次は運用の提案で、自動マージする仕組みを検証した例ではありません。

1. 対象ファイル、変更理由、期待する振る舞い、指定テスト、触れない対象を指示へ書く。
2. 調査ならread-only、必要な編集ならworkspace-writeを選び、入力ログから機密を除く。
3. 親側でCLI終了コード・JSONL・最終回答と、git diff --check・git diff を照合する。
4. 親側でも指定テストを実行し、実行済みと未検証を分けて次の人やAIへ残す。

目的と対象ファイル:
期待する変更と、触れない対象:
対象commit・CLI版・sandbox・承認設定:
完了を確認するテスト:
成果物の差分と、実際に通ったテスト:
未決の判断・未検証・次の操作:

接続を引き継ぐならMCP設定の保存先、指示の適用範囲ならCLAUDE.md・AGENTS.md、利用の範囲を確認するなら使用量の見方も一緒に残せます。

#どこまで実測し、何が未検証ですか？

モデルを使う5ケースと、引数エラー・存在しないIDの2ケースを、使い捨てのgit projectで各1回実行しました。実験時は --ignore-user-config と -c project_doc_max_bytes=0 を指定し、config.tomlの読み込みを省きました。指示文書が実際に読まれなかったかは、個別には確認していません。この指定だけではMCPやpluginをすべて無効にできず、実際にMCPの起動警告も残っています。モデル・reasoningの上書き引数は使っていません。最初の起動情報にはmodel gpt-6.1-sol、reasoning effort none と表示されました。実機helpに加え、同版の公式ソースも確認しています。

ユーザー設定を直接編集する操作は行っていません。ただし前後のSHA-256照合では、AGENTS.mdは一致し、config.tomlは変わっていました。CLIや同時実行との関係は未特定で、設定不変を確認した実験とは扱いません。セッションの記録も生成されるため、read-onlyをCLIの保存領域すべてへの書き込み禁止と解釈しないでください。

Linux・Windows、ネットワークや作業外ディレクトリへのアクセス、承認の自動レビュー、認証切れ・利用上限・中断、--last、ほかのCLI版は未検証です。出力は入力と設定に依存します。自分の環境ではhelp、権限、結果の3点を確かめてから仕事を渡してください。