AIにpush・deployさせる前に見るチェックリスト｜git diff・build・秘密情報・本番反映の確認

実行・push・deployの境界を分ける

知らないrepoでは、読み取り、限定実行、commit、push、deployを別の段階として扱います。AIがsetupを通したことと、pushや本番反映まで任せてよいことは別です。

push・deploy前は、git以外の退避先も確認する

pushやdeployの前にgit diffを見るのは基本です。加えて、未追跡ファイル、画像素材、生成済みHTML、uploadフォルダ、ローカル設定など、gitだけでは戻しにくいものは外付けSSDなどへ退避してから公開前レビューへ進むと、戻し方を選びやすくなります。

Workで調査、Codexで実装、人間がdeployを判断する

ChatGPT Workで調査と企画をまとめても、Codexの実装、build / check、git diff、commit / push、本番deployは別の境界です。新desktop appに入口が統合されても、push成功と本番反映を同じ完了条件にしません。

Auto-reviewはpermission grantではなく、承認者の置き換え

Auto-reviewでは、main agentがread-onlyまたはworkspace-writeのsandbox内で作業し、境界を越えるapproval requestが出たときだけ、`approvals_reviewer = "auto_review"`なら別のreviewer agentが判断します。approvedなら処理が続き、deniedならより安全な代替策を探すか停止します。writable_rootsを広げたりnetworkを有効にしたり、protected pathを弱めたりする設定ではありません。

Auto-reviewを公開作業に使う前の停止条件

• Auto-reviewのapproval成功を、build成功、test成功、diff確認、secret確認、生成物確認、push可、deploy可と同一視しない。
• Auto-reviewは境界を越えるactionだけを評価し、adversarialまたは通常と違うcontextで誤る可能性があるため、sandbox設計、monitoring、組織policyを残す。
• 拒否後は同じ目的を別のcommand、MCP、外部送信、shell wrapperで迂回せず、より安全な代替策を提示できなければ停止する。
• denial circuit breakerは、同じturnで3回連続または直近50 review中10回のdenialでinterruptする。loop回数を増やして突破しない。
• `/approve`のoverrideは、最近の特定denied actionを同じcontextで1回retryする狭い承認として扱い、似た将来のactionへの包括許可とは考えない。
• review transcriptは既定で`~/.codex/sessions`へ保持されるため、private data、secret、credentialがログに残る前提で入力と出力を確認する。
• review量を減らすためにbroadなwritable_rootsやprefix ruleを足さず、必要なscratch directoryやcommand prefixだけを狭く設計する。

Codex GitHub Actionは、workflow全体の安全性を保証しない

公式READMEのPR review例では、PRのmerge commitをcheckoutし、base・head refを明示的に取得し、`contents: read`でCodexを実行します。PR title・body・commit message・AGENTS.md・画像はprompt injectionの入力面になり得るため、PRの存在やラベルだけを根拠に広い権限を渡さず、レビュー対象の範囲と返却先を限定します。

GitHub Actionsへ組み込む前の停止条件

• `openai/codex-action@v1`を使う場合も、API keyはsecretに置き、prompt、PR本文、issue本文、branch名を無加工でshellへ連結しない。
• レビュー専用jobはjob-level permissionsを最小にし、`contents: read`、merge commit、base/head SHA、`persist-credentials: false`を確認する。
• 新しいpermission profileを選ぶなら、`:read-only`または`:workspace`とCodex CLIの対応versionを確認し、legacy `sandbox`や`sandbox_mode`を同じworkflow/configへ混在させない。
• Linux/macOS runnerでは`drop-sudo`または管理済みの`unprivileged-user`を優先し、read-only sandboxだけでAPI keyが守られると判断しない。
• Codex Actionはjobの最後に置き、完了後に特権step、secret利用、他Action、hook、release、deployを続けない。
• `final-message`を別jobへ渡しても、レビュー結果はmerge、push、deployの承認ではない。人間がdiff、CI、secret、生成物を確認する。
• Windows hosted runnerでは公式README上`safety-strategy: unsafe`だけが対応するため、Linux/macOSと同じ安全境界と見なさず、runner選択から見直す。