Codexの承認をスキップするには？設定手順と危険なバイパスの見分け方

Codexで毎回承認が求められるのはなぜか｜approval_policyの基本

Codexの承認ポリシー、サンドボックス、自動レビューという3つの層で、操作範囲を限定しながら承認による中断を減らす仕組み。

Codexの承認とは、AIエージェントが提案したコマンド実行やファイル変更を、実行前に人間が許可する確認の仕組みです。まずはこの仕組みが何を守っているのかを押さえると、どこまで減らしてよいかの判断がしやすくなります。

承認プロンプトはAIの暴走を防ぐ安全装置

Codexは指示を受けると、コードの修正やコマンド実行を自律的に進めます。その際、ファイルの書き換えや外部への通信など影響の大きい操作の前に「実行してよいですか」と確認を挟むのが承認プロンプトです。AIの判断は常に正しいとは限らないため、意図しない削除や誤ったコマンドの実行を人間が止められるように設計されています。

一方で、確認のたびに作業が止まるため、利用者からは毎回の承認がわずらわしいという声も多く聞かれます。承認の頻度は設定で調整できるので、仕組みを理解した上で自分の作業に合わせて最適化していきましょう。

approval_policyで選べる設定値

承認の頻度を決めるのが、設定項目のapproval_policy（承認ポリシー）です。Codex CLI 0.149.0以降の起動オプションでは、次の2種類から選びます。

設定値	動作	向いている場面
on-request	サンドボックスの境界を越える操作など、必要な場面で承認を求める	人の確認を残しながら進める日常的な開発
never	承認を一切求めない	隔離された検証環境での自動実行

config.tomlでは、承認の種類ごとに対話を許可するかを決めるgranular形式も利用できます。一方、以前使われていたon-failureは非推奨です。untrustedはCodex CLI 0.149.0以降でサポートされず、設定に残っていると起動できない場合があります。旧設定を使っている方は、OpenAIの案内に従って削除してください。

日常的な開発では、まずon-requestを基準にします。確認を厳しくしたい場合は、承認ポリシーを旧untrustedへ戻すのではなく、read-onlyのサンドボックスとon-requestを組み合わせます。

承認を安全に減らす鍵はサンドボックスとの組み合わせ

承認を減らすと聞くと危険に思えますが、Codexには承認とは別にもう1つの安全装置があります。それがサンドボックス（AIの操作範囲を制限した隔離実行環境）です。

sandbox_modeで実行範囲を隔離する

sandbox_modeは、Codexが操作できる範囲そのものを制限する設定です。承認が「操作のたびに人間が確認する」仕組みだとすれば、サンドボックスは「そもそも触れる範囲を狭めておく」仕組みにあたります。

設定値	許可される操作
read-only	ファイルの読み取りのみ。書き込みと外部通信は不可
workspace-write	作業フォルダ内の読み書きまで許可。フォルダ外への書き込みは原則不可
danger-full-access	制限なし。すべての操作が可能

調査やコードリーディングだけならread-only、コードを書かせるならworkspace-writeが基準になります。danger-full-accessは後述するリスクを理解するまで選ばないでください。

「隔離を広げるほど承認は厳しく」が使い分けの基本

approval_policyとsandbox_modeは掛け算で効く関係にあります。実行範囲を狭く隔離しているなら承認を減らしても被害は限定的ですし、逆に制限を外すなら承認は厳しく残すべきです。たとえばworkspace-writeとon-requestの組み合わせは、影響を作業フォルダ内に閉じ込めたまま承認回数を減らせるため、多くの利用者にとって出発点になります。

さらに、approvals_reviewer = "auto_review"を設定すると、承認が必要になった操作を自動レビューへ送れます。自動レビューは、予定している操作と直近の文脈、ユーザーの明示的な承認を含めてリスクを判定し、条件を満たす操作を自動承認します。判断できない操作は拒否または人の確認へ戻るため、承認そのものを無効化するneverや、サンドボックスまで外す完全バイパスとは異なります。OpenAIの安全運用例でも、サンドボックス内の操作範囲を保ったまま中断を減らす方法として紹介されています。

Codexの承認を安全にスキップする設定手順【5ステップ】

ここからは、承認の回数を安全に減らす具体的な設定手順を5つのステップで説明します。いきなり承認をすべてオフにするのではなく、段階的に緩めながら自分の作業に合う設定を見つける流れです。

ステップ1: 現在の設定と作業環境を確認する

まず、codex --versionでCLIのバージョンを確認します。Codexのセッション中に/statusと入力すると、現在のapproval_policyとsandbox_modeも確認できます。あわせて、対象のリポジトリがGitで管理され、未コミットの変更を把握できているかを確認しておきます。承認を減らす前提として、いつでも差分を確認して巻き戻せる環境を用意することが何よりの保険になります。

ステップ2: config.tomlでapproval_policyを変更する

恒久的な設定は、ホームディレクトリの~/.codex/config.tomlに記述します。


approval_policy = "on-request"

sandbox_mode = "workspace-write"

approvals_reviewer = "auto_review"

上記のように書くと、次回の起動から適用されます。on-requestで必要な確認を残し、workspace-writeで書き込み先を作業フォルダ内に限定したうえで、承認要求だけを自動レビューへ回す構成です。自動レビューの利用可否はクライアントや管理設定によって異なるため、反映後に/statusで有効な設定を確認してください。

ステップ3: sandbox_modeを作業内容に合わせて選ぶ

次に、承認とセットでサンドボックスの範囲を見直します。コードを書かせる作業が中心ならworkspace-writeを選び、書き込み先を作業フォルダ内に限定します。逆に、リポジトリの調査や仕様の確認だけならread-onlyのままで十分です。作業フォルダの外に書き込みたい事情がある場合も、いきなりdanger-full-accessに切り替えるのではなく、必要なフォルダだけを追加で許可できないかを先に検討してください。

AIエージェントの作り方

AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。

無料ダウンロード →

ステップ4: CLIオプションで自動レビューを試す

恒久設定を変えるほどではないものの、今回の作業だけ承認を減らしたい場面では、CLI（コマンドラインインターフェース）の起動オプションを使います。


codex --approve-for-me

--approve-for-meは、workspace-writeのサンドボックスを使い、承認要求を自動レビューへ送る起動オプションです。ポリシー上の条件を満たす操作は中断せずに進められますが、判断できない操作は拒否されたり、人の確認が残ったりします。確認をすべて消すオプションではありません。

ステップ5: 自動レビューの判断と実行結果を検証する

まず本番に影響しない検証用リポジトリで、自動承認される操作、拒否される操作、人の確認へ戻る操作を観察します。意図しない変更が起きていないかをdiff（変更差分）とテストで確認できたら、日常の作業にも段階的に広げていきます。承認による中断を減らした分は、実行後のコードレビューやテストで品質を担保する運用に切り替えるのがコツです。

設定しても承認が求められ続けるときの確認ポイント

Codexの承認が残るときに、起動オプション、config.toml、サンドボックス境界、自動レビューの順で原因を切り分ける図。

設定を変えたのに承認が出続ける場合は、設定の優先順位から確認します。Codexは起動時のCLIオプションが設定ファイルの内容を上書きするため、config.tomlを書き換えてもオプション指定が残っていれば反映されません。次の順に見直してみてください。

config.tomlの記述場所は正しいか（該当項目をファイルの先頭側のトップレベルに書いているか）
起動時のオプションやプロファイル指定が設定を上書きしていないか
作業フォルダの外への書き込みなど、サンドボックスの範囲外の操作を依頼していないか
自動レビューが安全上の理由で拒否または人の確認へ戻していないか
codex --versionで確認したCLIが、設定項目や起動オプションに対応しているか

特に多いのは、サンドボックスの範囲外の操作を頼んでいるケースです。この場合はapproval_policyを変えても、範囲外の操作である限り確認は残ります。また、自動レビューが操作を止めるのは設定不良とは限りません。承認を減らしたいのか、操作できる範囲を広げたいのか、安全判断で止まったのかを切り分けてから設定を見直すのが近道です。

—dangerously-bypass-approvals-and-sandboxの危険性

—dangerously-bypass-approvals-and-sandboxは、その名のとおり承認とサンドボックスの両方を同時に無効化する起動オプションです。最も手軽に確認をなくせる一方で、リスクの質が他の設定とはまったく異なります。

関連記事：Codexのセキュリティリスクと対策｜情報漏洩・脆弱性・危険性を整理

すべての安全装置が同時に無効になる

このオプションを付けると、Codexは確認なしであらゆるコマンドを実行でき、ファイルの削除・上書き・外部への通信を止めるものがなくなります。プロンプトインジェクション（外部の文章に埋め込まれた不正な指示でAIを操作する攻撃）を受けた場合、機密情報の送信や破壊的な操作がそのまま実行される恐れがあります。

approval_policyをneverにする設定との違いは、サンドボックスの有無です。neverでもサンドボックスが有効なら操作範囲は制限されたままですが、このオプションは範囲の制限ごと取り外します。

使ってよい場面と避けるべき場面

利用が許容できるのは、壊れても影響がない使い捨ての環境に限られます。たとえばコンテナや仮想マシンの中だけで完結する検証作業です。逆に、業務データのある端末・本番につながる環境・チームで共有しているリポジトリでの利用は避けてください。会社の端末で使う場合は、社内のセキュリティルールに反しないかを事前に確認しておくと安心です。

GitHub Copilot・Claude Codeとの承認管理の違い

AIコーディングエージェントの承認管理は、ツールごとに名称と設計が異なります。下表は、Codex・Claude Code・GitHub Copilotの3つを、承認設定の名称・承認を減らす方法・完全バイパスの手段・実行環境の隔離という4つの観点で整理したものです。複数のツールを併用する場合は、安全装置の違いを押さえた上でチームとして同じ方針をそろえると管理しやすくなります。

観点	Codex	Claude Code	GitHub Copilot
承認設定の名称	approval_policy	permission mode	エージェントへの承認（ワークフロー承認など）
承認を減らす設定	on-request + auto_review / --approve-for-me	編集を自動許可するモードへの切り替え	設定により一部の承認を省略可能
完全バイパスの手段	--dangerously-bypass-approvals-and-sandbox	--dangerously-skip-permissions	該当機能なし（人間のレビューを前提）
実行環境の隔離	サンドボックスを内蔵	利用環境に依存	クラウド上の隔離環境で実行

考え方はどのツールも共通で、自動化の範囲を広げるほど隔離とレビューで補うという原則に行き着きます。Codexで身につけた承認設計の考え方は、他のツールにもそのまま応用できます。

Before/Afterで見る承認設定見直しの業務インパクト

承認設定の見直し前後で、1日の承認対応時間がどれだけ変わるかを対比で見せ、設定変更の価値を数字で実感させる。

承認設定の見直しは、体感の快適さだけでなく作業時間の数字にも表れます。ここでは、例えば次のような2つのケースが考えられます。

シナリオ1: 日常のコード修正が承認対応で細切れになるケース

AIコーディングツールを使い始めて3ヶ月の開発担当者が、1タスクあたり10回前後の承認に毎回応答しているケースです。1回の応答と文脈の切り替えに約30秒かかるとすると、1日10タスクで約60分が承認対応に消えます。仮にon-requestと自動レビューの組み合わせで人への確認が1タスク2〜3回まで減れば、対応時間は1日約15分、およそ75%の削減になります。月20営業日では15時間相当を取り戻せる試算ですが、実際の削減幅は依頼内容と安全判断によって変わります。

AI活用実態調査レポート

全国8,000人調査で、AIの活用方法によって生産性向上に約3.8倍の差が生まれることが判明。

無料ダウンロード →

シナリオ2: 検証用リポジトリでの定型修正を一括実行するケース

もう1つは、100ファイル規模の定型的な修正を1件ずつ承認しているチームのケースです。一括修正のたびに承認が約50回発生し、完了まで約40分かかっていたとします。書き込み先を作業フォルダに限定し、--approve-for-meで低リスクな承認要求を自動レビューへ回して、完了後にdiffをまとめて確認する方式なら、中断を抑えながらレビューへ時間を振り向けられます。ただし高リスクな操作では人の確認が残るため、「承認0回」を前提にはしません。

承認をスキップする前の安全チェックリスト

最後に、承認を減らす設定へ切り替える前の確認項目をチェックリストにまとめました。上から順に確認していけば、リスクを抑えたまま移行できます。

対象リポジトリはGitで管理され、いつでも巻き戻せる状態か
未コミットの変更や、共有ブランチへの直接作業が残っていないか
sandbox_modeは作業に必要な最小限の範囲になっているか
認証キーや顧客データなど、機密情報に触れる作業ではないか
実行後のdiffレビューやテストなど、承認に代わる品質確認の手段があるか
会社やチームのセキュリティルールに反していないか

すべてにチェックが付くなら、承認を減らしても安全性は大きく損なわれません。逆に1つでも引っかかる項目があるなら、その作業に限っては承認を残す判断が賢明です。

Codexのような AIエージェント導入で陥りがちな3つの落とし穴

Codexの承認設計は、AIエージェントを業務に組み込むときの縮図でもあります。ここでは、AIエージェント導入の現場でよく見られる3つの落とし穴を紹介します。

落とし穴1: いきなり全てをやろうとする

最初からすべての作業をAIに任せ、承認も一気に外すという進め方は失敗のもとです。適用範囲を一度に広げると、問題が起きたときに原因の切り分けができなくなります。

落とし穴2: 壮大なAI戦略から考えて手が止まる

全社的な計画や完璧なルール作りから着手すると、検討ばかりが続いて導入が進みません。小さく試して学ぶほうが、ルールも実態に合ったものになります。

落とし穴3: 既製品のチャット型AIでは業務フローに組み込めない

チャットに質問して答えをもらう使い方だけでは、日々の業務フローに定着しません。自社の手順やデータに合わせてカスタマイズでき、業務の流れに組み込めるエージェント型の仕組みが必要になります。

スモールスタートで1業務をAIエージェントに任せる

遠回りに見えても、まず1つの業務をAIエージェントに任せ、承認や隔離の設定を調整しながら運用を固めるスモールスタートが定着への近道です。Codexの承認設計で行ったように、小さな範囲で安全装置の塩梅を確かめてから広げる進め方なら、失敗しても影響は限定的です。1業務で得た設定・レビュー・運用ルールの知見は、次の業務への展開にそのまま生かせます。

自社業務でAIエージェント活用を進めたい方へ

ここまでで紹介した「スモールスタートで1業務から自動化する」アプローチを、自社で実践したいとお考えの方もいらっしゃるかもしれません。

GiftXでは、AIエージェントの構築支援サービス「GiftX AIエージェント構築支援」を提供しています。1業務単位のスモールスタートから、業務フローに組み込めるレベルのAIエージェント構築までを伴走します。

詳細はGiftX AIエージェント構築支援のサービスサイトでご覧いただけます。

Codexの承認に関するよくある質問

最後に、Codexの承認まわりでよく寄せられる質問と回答をまとめます。

承認を完全にオフにしても安全ですか？

approval_policyをneverにしても、サンドボックスが有効なら操作範囲は制限されたままなので、一定の安全性は保たれます。危険なのは、サンドボックスまで同時に無効化するオプションとの併用です。オフにする場合も、隔離された検証用の環境に限定することをおすすめします。

GitHub Copilotでも承認を省略できますか？

GitHub Copilotのコーディングエージェントにも承認の仕組みがあり、設定によって一部のワークフロー承認を省略できます。ただし設定箇所や挙動はCodexと異なるため、利用中のプランの公式ドキュメントで最新の仕様を確認してください。

環境によって承認まわりの挙動が違うのはなぜですか？

承認の挙動は、Codexのクライアントとバージョン、起動オプション、選択したサンドボックス、組織の管理設定によって変わります。OSだけを原因と決めつけず、まずcodex --versionと/statusを確認し、起動オプション、プロファイル、config.tomlの順に有効な設定を切り分けてください。

まとめ｜承認は消すのではなく設計する

Codexの承認は、単にわずらわしい確認作業ではなく、サンドボックスと組み合わせて安全性を担保する仕組みの一部です。approval_policyとsandbox_mode、自動レビューの役割を分けて理解すれば、操作範囲を限定したまま中断を減らせます。完全にバイパスするオプションは使いどころを使い捨ての環境に限定し、日常の作業ではon-requestとworkspace-writeを基準に、必要に応じて自動レビューを組み合わせてください。承認を消すのではなく、どこに残すかを設計すると捉えることが、AIエージェントと安心して協働するための土台になります。