直接回答
CI は入力の確定、機械読み取り可能な出力、限定された権限、明確な失敗条件を備える必要がある。対話型の体験をそのまま無人環境に持ち込んではならない。
このガイドで解決できること
スクリプトや CI で安全に Codex CLI を実行する
無人タスクの機械契約を定義する
CI には clarification や承認に答える人がいないため、入力は固定され、権限境界と失敗時の挙動はあらかじめ定義されていなければならない。まずタスクを読み取り専用でレポート出力させ、その後ワークスペースへの書き込みを許可するか評価する。
スクリプトはプロセスの終了コードを第一のステータスとし、イベントストリーム、最終メッセージ、テスト成果物はそれぞれ別々に保存する。ターミナルの色付けや自然言語の「成功」を解析してはならない。
codex exec で単発タスクを実行する
プロンプトは引数として渡すことも、- で標準入力から読み込むこともできる。標準入力はバージョン管理されたファイルから長いタスクを提供するのに適しており、複雑な shell のエスケープを避けられる。
--ephemeral はセッションファイルを永続化せず、使い捨ての runner に適している。--skip-git-repo-check は、入力ディレクトリが実際に Git リポジトリに属さない場合にのみ使用すべきである。
codex exec -C /path/to/repo --ephemeral -s read-only -a never "检查未提交差异中的行为回归，只输出发现。"codex exec -C /path/to/repo --ephemeral -s read-only -a never - < .ci/codex-task.mdイベントと最終結論を分けて保存する
--json はイベントを JSONL として書き出し、ログ処理に適する。-o は最終メッセージを別ファイルに書き出す。呼び出し側は Codex の終了コードと後続テストの終了コードを引き続き確認する必要がある。
出力にはリポジトリのパス、コードスニペット、ツールの結果が含まれる可能性がある。成果物にはアクセス制御と保持期限を設定し、アップロード前にシークレットスキャンを実行する。
set -o pipefail
codex exec -C "$PWD" --ephemeral -s read-only -a never --json -o /tmp/codex-final.txt "分析测试失败并给出修复计划。" | tee /tmp/codex-events.jsonl
codex_status=${PIPESTATUS[0]}
printf "codex_exit=%s\n" "$codex_status"
exit "$codex_status"安定したフィールドが必要な場合は出力 Schema を使用する
--output-schema は JSON Schema を受け入れ、モデルの最終出力の構造を制約する。Schema は小さく安定に保ち、呼び出し側で再度解析検証すべきである。
構造化出力は結論の真実性を証明するものではない。発見事項には引き続きファイル、位置、証拠を含め、決定論的テストやレビュー手順で検証する。
{
"type": "object",
"additionalProperties": false,
"required": ["summary", "findings"],
"properties": {
"summary": { "type": "string" },
"findings": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": ["severity", "file", "reason"],
"properties": {
"severity": { "type": "string", "enum": ["high", "medium", "low"] },
"file": { "type": "string" },
"reason": { "type": "string" }
}
}
}
}
}codex exec --ephemeral -s read-only -a never --output-schema .ci/review.schema.json -o /tmp/review.json "审查当前改动。"CI 上で Secret から CodeNodex を設定
CI Key はプラットフォームの Secret によって注入され、独立した権限とクォータで使用すべきです。以下の手順では CLI を2つインストールしてログインモードで provider を設定し、その後、限定的なサンドボックスで読み取り専用のレビューを実行します。
実際のワークフローでは action とツールのバージョンを固定し、インストール資産を検証し、タイムアウトを設定した上で、リポジトリの言語に応じてテストステップを追加してください。pull request のログに Secret を出力しないでください。
- name: Install Codex CLI
run: npm install -g @openai/codex
- name: Install CodeNodex CLI
run: curl -fsSL https://token.codenodex.com/cli/install.sh | bash
- name: Configure provider
env:
CODENODEX_API_KEY: ${{ secrets.CODENODEX_API_KEY }}
run: |
codenodex setup -o https://token.codenodex.com \
--key "$CODENODEX_API_KEY" --platform openai --client codex -y
- name: Review changes
shell: bash
run: |
set -o pipefail
codex exec --ephemeral -s read-only -a never --json \
-o /tmp/codex-final.txt \
"审查当前提交中的行为回归、秘密泄漏和缺失测试。" \
| tee /tmp/codex-events.jsonl決定論的なゲートで自動化を制約する
Codex は修正やレビューの所見を提案できますが、マージゲートはテスト、型チェック、lint、シークレットスキャン、ポリシーチェックによって決定されるべきです。モデルの出力は補助的な証拠として適していますが、唯一の承認者とすべきではありません。
タスクごとにタイムアウト、同時実行数の上限、予算を設定してください。失敗時にはマスキングされた診断情報を保存し、再試行回数には上限を設けてください。自動書き込みのシナリオでは一時ブランチや隔離された worktree を使用し、保護されたブランチに直接プッシュすることを禁止します。
- ツールと依存関係のバージョンを固定する。
- Codex とプロジェクトコマンドの終了コードを確認する。
- Secret、ファイルシステム、ネットワークの範囲を制限する。
- 成果物に対してマスキングと保持ポリシーを実施する。
- 影響度の高い操作には人承認を残す。
公式情報と検証範囲
本ガイドは公開されている公式ドキュメントを根拠にしています。コマンドや設定はクライアントのバージョンにより変わるため、実行前に参照元も確認してください。
技術検証方法を見る