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選択から見直す。

/reviewのscopeとGit stateを分ける

Windowsでreviewを再開する確認順

• 対象projectがGit repo内にあることを確認し、absolute path、Git root、remote、current branch、status、diff、untracked、staged、保護対象ファイルを記録する。別repoの同名pathや前回のreview結果を現在状態と推測しない。
• レビューの目的を、base branch、uncommitted、commit、branch、Last turn、custom criteriaのどれかに限定し、PR番号・branch・commit・対象file・確認観点をpromptで明示する。複数repoでは選択repoを先に固定する。
• Unstagedだけを見て完了にせず、必要ならStaged、Commit、Branchの範囲を個別に確認する。review paneのfindingはGit全体の選択範囲に対する指摘であり、Codexの今回の編集だけに限定されない。
• findingやinline commentは、再現条件・対象行・影響・根拠を確認してから修正を依頼する。follow-upでは修正範囲を明示し、作業ツリー、diff、test・build結果、生成物を再確認する。
• 修正後は通常のsandbox・approvalでstage、revert、commit、pushを判断する。FTP、DNS、CDN、production、Search Consoleはreviewの完了とは別の手動gateとして残す。