Codexの承認が多いときの対処法｜権限を広げる前に確認すること

2026年10月6日

当ページのリンクには広告が含まれています。

Codexで承認待ちの停止が頻繁に出るとき、まず確認すべきなのは「操作（何を実行しようとしたか）」「対象（実際のパスやURL）」「有効権限（現在のsandboxや承認ポリシー）」の3点です。

コマンドを実行するたびに画面が止まって負担に感じることもありますが、いきなり権限を一括解除するのは避けるのが無難です。承認や権限による停止の場合、環境やファイルを守るための安全境界が働いているケースがあるためです（※コマンド自体の文法エラーなど技術的な実行失敗によって停止する場合もあります）。

止まった原因を確認すると、作業フォルダ外へのアクセス、外部への通信、あるいは作業フォルダ内であっても保護されている設定ファイルなど、具体的な理由が見えてきます。停止した操作と有効範囲を照合し、承認モードの使い分けや必要な保護設定を行うことで、安全性を保ちながら作業を進めやすくなります。

この記事では、停止理由の切り分け方、3つの承認モードの違い、フォルダ内での保護ルール、触らせたくない場所の保護方法、そして変更後のテスト手順を順を追って解説します。

1. まず何をしようとして止まったかを確認する

作業が停止したときは、画面の許可ボタンをすぐに押す前に、何を実行しようとして止まったのかを確認します。

停止画面で確認する3つの項目

確認するポイントは次の3点です。

操作（何を実行しようとしているか）
ファイルの読み取り、ファイルの新規作成や編集、コマンド実行、外部通信など、どのような処理を行おうとしたかを確認します。
対象（どこを触ろうとしているか）
アクセス先となっているファイルパスや接続先URLを確認します。作業フォルダ内なのか、別のドライブやシステム領域なのかを特定します。
有効権限（現在の動作モードはどうなっているか）
現在のセッションで有効になっている承認ポリシーやsandboxの範囲を確認します。通常の承認待ちか、Auto-reviewによる審査中かも把握します。

仕組みと停止理由の切り分け

Codexには、ファイルやネットワークへのアクセス境界を決める「sandbox」と、操作の実行前に確認を求める「approval」という独立した仕組みがあります（出典：OpenAI Codex: Sandboxing）。sandboxの技術的境界を超える操作や、保護ルールに抵触する操作を検知したときに承認が求められます。

ここで注意したいのは、「フォルダ外へのアクセスや一時領域の利用は必ず止まる」と決めつけないことです。既定のworkspace-write構成であっても、有効な追加書込ルートやシステム一時領域が許可されている場合があります。そのため、実際のパスと現在の有効範囲を照合して判断する必要があります。

また、通信に関する承認は設定や操作経路に依存します。Web検索やブラウザ機能、外部連携サービスの制御はローカルコマンドのsandboxとは別の制御下にある点にも留意してください。

停止状況の判断表

停止した状況に応じて、先に確認する対象を以下の表にまとめました。原因を特定する前に、まず該当する対象を照合してください。

止まった状況	先に確認する対象
作業フォルダ以外の場所を変更しようとしている	実際の出力先パス、現在の有効な作業フォルダ（workspace）、設定された追加書込ルート
外部通信や資料の外部送信が発生している	接続先URLや送信データの内容、現在のネットワーク許可設定、操作の実行経路
作業フォルダ内だが設定ファイルやGit関連で止まる	触ろうとした実パス、既定で保護される設定ファイル（.git、.codex、.agents）の保護ルール
代理承認（Auto-review）で操作が拒否された	拒否の理由、対象となった操作やコマンド、送信先と送る資料の内容（人間が許可するか安全な別案を検討）
触らせたくないドライブやフォルダがある	中身を読ませてよいか（read）、読取も変更も拒否したいか（deny）、現在の設定プロファイル
停止した理由が画面からよく分からない	画面に表示されたコマンド名、対象パス、現在の承認モードとエラー表示（点検プロンプトで確認）

止まった状況から次に確認する対象を選ぶ目安として、以下の入力欄から近い状況を選択できます（自動での設定変更や原因の確定は行いません）。

2. 承認を求める・代理で承認・フルアクセスは何が違う？

Codexには、作業中の承認をどのように扱うかを決める複数の方式が用意されています（出典：OpenAI Codex: Permission modes）。これらは「審査担当」「ローカル範囲」「向く状況」が異なります。

3つの承認方式の比較

方式	審査担当	ローカル範囲	向く状況
承認を求める（Ask for approval）	人間	作業フォルダ内が基本。境界外は都度確認	操作内容を人間が1つずつ確認して進めたいとき
代理で承認（Approve for me）	AI（Auto-review）	境界は維持し、個別の越境操作を審査	通常の作業フォルダ外操作を含め、確認の手間を減らしたいとき
フルアクセス（Full access）	省略（自動実行）	ローカルsandboxを外しコマンド承認を省略	隔離された環境でコマンド承認を省略して進めたいとき

各方式の特徴と注意点

承認を求める（Ask for approval）
人間が審査を担当します。作業フォルダ内での標準的な操作は任せ、境界外への変更や外部通信が発生したときは人間に確認を求めます。意図しない操作を防ぎやすい標準的な方式です。
代理で承認（Approve for me）
審査AIであるAuto-reviewが個別の操作を自動で評価します（出典：OpenAI Codex: Auto-review）。
重要な点として、Auto-reviewは境界を恒常的に広げるものではありません。審査対象となった個別の操作を審査し、安全と判断された個別操作のみ実行へ進めます。また、審査AIによる判断ミスが起きる可能性もあります。操作が拒否（Denial）された場合は、同じ指示を無理に繰り返して回避しようとせず、拒否理由や送信先、送る資料の内容を確認し、人間が許可を与えるか安全な別案へ切り替えます。
フルアクセス（Full access）
ローカルのsandboxを外し、コマンド実行時の個別承認を省きます。ただし、省かれるのはローカルコマンドに対する承認であり、コマンド実行自体のエラーや組織ポリシーによる管理要件、別機能（ブラウザ連携など）の確認や制限は残り得ます。意図しないファイル変更のリスクもあるため、通常の作業での常用には慎重さが求められます。

設定に関する誤解とインターフェースの違い

設定ファイル（config.toml）における approval_policy = "never" は、承認待ちを行わない設定です（出典：Configuration Reference）。ただし、これは操作可能範囲を広げる設定ではなく、失敗を解消する設定でもありません。許可されていない操作は承認を求めずにエラーとして終了するため、権限不足の解決策として使うものではない点に注意してください。

また、設定ファイル等で特定のモードを有効化（メニューに表示可能に）することと、現在のチャットセッションでそのモードを選択することは別の手順です。

デスクトップやIDEでは入力欄周辺の権限メニューから切り替え、CLI版では /permissions コマンドで確認・変更します。なお、公式のPermission modesドキュメントにおけるデスクトップ版の表記はChatGPT向けのものであり、Codexを含むすべてのバージョンや環境で同一のメニュー名や画面位置になるとは限りません。所属組織の管理設定によって利用できる方式が制限されている場合もあります。

3. 作業フォルダ内なのに止まる場合を切り分ける

作業フォルダ（workspace）の中で作業させているつもりでも、承認ダイアログが表示されることがあります。この場合は、実際のパスや保護設定を確認します。

出力先パスと有効範囲の確認

指示文で作業フォルダ内を意図していても、コマンドが一時ファイルやログを別のパス（システムの一時領域やユーザーホームなど）に出力しようとするケースがあります。

ただし、既定のworkspace-write構成であっても、設定によっては特定の追加書込ルートやシステム一時領域への書き込みが許可されている場合があります。単に「フォルダ外だからエラー」と判断するのではなく、実際にアクセスしようとしたパスと現在の有効範囲を照合することが大切です。

通信設定と外部機能の切り分け

ツールの依存パッケージ取得やデータ更新に伴い、通信が発生して停止することがあります。ネットワーク通信に対する承認は現在の設定や実行経路に依存します。また、Web検索やブラウザ連携などの外部機能は、ローカルコマンドのsandboxとは別の制御下で動作している点を確認してください。

既定workspace-writeで保護される対象

公式のセキュリティ仕様（出典：OpenAI Codex: Agent approvals & security）により、既定のworkspace-write環境では、作業フォルダ内であっても以下のパスが変更から保護されています。

.git ファイルおよびディレクトリ（解決された gitdir を含む）
存在する .agents ディレクトリ（再帰的に読み取り専用）
存在する .codex ディレクトリ（再帰的に読み取り専用）

これは「すべてのGit関連ファイルや全モードで変更が禁止されている」という意味ではなく、既定構成において重要な設定を保護するための条件です。AIがこれらのファイルを変更しようとすると確認が求められます。

指示文での対応と必要な確認の維持

出力先を明確にしたい場合は、プロンプトで「生成ファイルは作業フォルダ内の ./output に保存してください」と指定することで、不要な越境アクセスを抑えやすくなります。

ただし、単なる相談や確認であっても、ファイルの削除や外部への資料送信など、重要な変更に関する人間確認まで指示文で無理に消そうとしないことが大切です。安全に必要な確認は維持するようにしてください。

4. 触らせたくない場所は変更禁止と読み取り禁止を分ける

作業用PCの中にプライベートなデータや他業務のファイルがある場合、触らせたくないドライブやフォルダをどう扱うかが問題になります。

カッパパ

僕自身も、触ってほしくないドライブを指定できるか、アプリの設定画面から変更できるかを相談したことがありました。守りたい場所があるときは、「変更だけを止めたいのか」それとも「読み取りも止めたいのか」を整理することが出発点になります。

readとdenyの仕様

Codexの権限仕様（出典：OpenAI Codex: Permissions）では、ファイルシステムへのアクセスを以下のように設定できます。

read（読み取り専用）
中身の読み取りは許可しますが、新規作成、編集、削除などの変更操作は禁止します。参考資料として参照させたい場合に適しています。
deny（アクセス拒否）
読み取りと書き込み（変更）の両方を禁止します。

ここで注意したいのは、denyはローカルsandbox内コマンドの読取と書込を拒否する設定であり、ファイルの存在や名前そのものを完全に秘匿する機能ではないという点です。

また、承認済みの昇格操作、MCP（Model Context Protocol）、ブラウザ機能、外部連携サービス、Cloud機能などはローカルsandboxとは別系統で制御されています。denyを設定したからといって、Codexに関連するあらゆる外部連携や機能からのアクセスが一括で遮断されるわけではありません。

設定ファイル（config.toml）の記述例

以下は、~/.codex/config.toml の一部として記述するカスタムプロファイルの例です（出典：OpenAI Codex: Permissions）。

※このプロファイル（profile）機能はベータ仕様であり、今回の環境での実機検証は行っていません。 ※D:\private-materials は説明用の架空のパスです。試す場合はダミーファイルのみを入れた専用フォルダを使用してください。 ※WSL環境をご利用の場合、Windows形式のドライブパス（D:\...）をそのまま使用せず、Linux形式（/mnt/d/... など）に合わせて指定する必要があります。

default_permissions = "work-with-private-folder-denied"

[permissions.work-with-private-folder-denied]
extends = ":workspace"

[permissions.work-with-private-folder-denied.filesystem]
'D:\private-materials' = "deny"

記述のポイント
extends = ":workspace" を指定することで、作業フォルダ外の保護など既定のルールを継承します。内容を読ませたいだけなら "deny" を "read" に変更します。
設定時の確認事項
この記述を既存の設定ファイルへ一括で貼り付けるのは避けてください。読み込まれた設定の中に従来の sandbox_mode が存在する場合、原則として旧設定が優先されて新しいプロファイルが利用されない仕様となっています（組織の管理要件で新しいプロファイルの利用が明示的に許可・指定されている場合などの例外を除く）。そのため、新旧の設定を混在させず、現在有効になっている設定や管理要件をあらかじめ確認したうえで追加してください。

5. 変更後は動いたことと止めたい操作が止まることを確認する

設定を変更した後は、秘密ファイルを使わず、テスト用のダミーファイルとフォルダを使って動作を確認します。

ダミー環境での照合手順

ローカルsandbox内で、以下の両方を確認します。

作業用ダミー原稿の確認
作業フォルダ内にダミーファイル（dummy_draft.txt など）を置き、読み取りや編集（追記など）が正常に行えるかを確認します。
保護対象フォルダの確認
第4章の設定例と同じパス（D:\private-materials）を使用し、コードと実際のテスト対象を一致させて確認します。この名前のフォルダを実際に用意する場合は、中身がダミーファイルだけの専用フォルダにしてください。
- read に設定した場合：中身の読み取りが可能で、書き込み操作が拒否されるか照合します。
- deny に設定した場合：読み取りと書き込みの両方が拒否されるか照合します。

※昇格操作や例外許可を与えて動作した結果を、「制限が正しく機能した確認」と誤認しないようにしてください。本物の重要ファイルや秘密ファイルはテストに使用しないことが鉄則です。

停止理由を整理する点検プロンプト

意図せず処理が停止したときは、以下のプロンプトを使ってCodexに状況を整理させることができます。

直前の操作で処理が停止した（または承認が求められた）理由を整理してください。
回答にあたっては、確認済みの事実、推測、不足している情報を明確に区別してください。
有効範囲が不明な項目は「未確認」と明記し、設定変更は実行せず、最小限の修正候補だけを提示してください。

1. 実行しようとした具体的なコマンドまたは操作
2. 対象となったファイルパスまたは通信先URL
3. 停止した原因（作業フォルダ外、保護対象パス、通信設定、権限不足など）
4. 作業フォルダ内で安全に処理を完了させるための、最小限の修正案（プロンプトやパスの変更など）

AIから返ってきた内容は、画面のログや実際の実行記録と照合して確認してください。点検プロンプトの出力が、確実な原因特定やその後の動作成功を保証するものではありません。