Codex 許可が多いときの設定確認｜安全な減らし方のコツ

「Codex 許可 めんどくさい」の正体は何か

Codexの操作中に確認が多いとき、最初から「許可をなくす設定」を探すのは得策ではありません。確認が出た操作が、ファイルの編集なのか、ワークスペース外への書き込みなのか、ネットワーク接続なのかを分ける必要があります。許可を求める仕組みは、Codexが何でも止めているというより、現在の作業範囲から外れる操作を人に知らせるためにあります。範囲が狭いこと自体が問題なのか、対象の指定がずれているのか、単に確認方針が慎重なのかで、直す場所は変わります。まず画面に出た文言と、実行しようとした命令、作業フォルダー、選択中の設定を一緒に残してください。

OpenAIの安全運用に関する公式説明も、サンドボックスが書き込み場所やネットワークへの到達範囲を決め、承認方針が確認を求めるタイミングを決める、と整理しています。したがって「許可を求められた」という結果だけでは、二つの設定のどちらが原因か判断できません。確認画面を閉じる前に、対象パス、接続先、使っていたモデル、Codexの版を記録すれば、次の試行で変えたものを一つに絞れます。出典: https://openai.com/index/running-codex-safely/

許可確認とサンドボックス拒否は別

承認確認は「この操作を進めてよいか」を尋ねる表示です。サンドボックスによる拒否は「現在の範囲では、その操作を実行できない」という状態です。前者だけを減らす目的で後者の境界まで広げると、確認は減っても、触れてよい場所が広がります。ファイルを編集したいだけなら、書き込み対象をワークスペース内へ戻せば解決することがあります。許可ボタンを押す回数を数える前に、操作が本当に境界を越えていたかを読みましょう。

確認が多いこと自体は失敗ではない

新しいプロジェクトや初めて読むコードでは、確認が多い方が意図しない変更を見つけやすい場合があります。短い調査、既存ファイルの読み取り、差分の確認まで慎重に進め、問題のない命令の傾向が分かってから設定を調整する方が、あとで原因を追いやすくなります。確認の回数だけで使いにくさを評価せず、確認された操作の種類と、実際に必要だったかを一緒に見てください。

公式仕様で読む二つの設定

Codexの許可設定を理解するには、approval_policy と sandbox_mode を別の質問に置き換えるのが近道です。前者は「いつ人に確認するか」、後者は「どこまで操作できるか」です。両方を強い値へ変えれば表示は減るかもしれませんが、同時に見落とした変更を止める機会も減ります。OpenAIの公式サンドボックス文書は、workspace-write と on-request の組み合わせを、ワークスペース内の作業を進めつつ境界を越えるときに確認する構成として説明しています。出典: https://developers.openai.com/codex/sandboxing/

approval_policy は止まるタイミング

untrusted は信頼されていない命令を確認へ回し、on-request はサンドボックス内の作業を進め、境界を越えるときに確認します。never は確認を出さない値ですが、確認を減らしたいという理由だけで日常のプロジェクトに選ぶものではありません。OpenAIの設定リファレンスでは、対話的な実行では on-request、確認を人へ残す場合は user を基準に読めるよう整理されています。自分の目的が「同じフォルダーの編集を止めたくない」なら、方針を最も強い値へ変える前に、サンドボックスの範囲が合っているか確認してください。出典: https://developers.openai.com/codex/config-reference/

承認方針を変えるときは、確認が消えたかだけで判断しません。読み取り、ファイル編集、テスト、外部接続という異なる操作を一つずつ試し、どれが確認なしで進み、どれが止まったかを記録します。値を変更したセッションと、変更していないセッションを同じフォルダーで比べれば、方針の影響を見分けられます。

sandbox_mode は作業範囲

read-only は調査や説明に向いた状態で、ファイルを書き換える作業には追加の確認が必要になります。workspace-write は現在のワークスペース内での読み取り・編集・通常のローカル命令を進めるための状態です。danger-full-access はファイルやネットワークの境界を外す値なので、許可が多いという理由で選ぶと、問題の場所を隠してしまいます。編集対象が別のフォルダーにあるなら、全体を開くのではなく、必要なパスを追加する方が範囲を説明しやすくなります。

追加パスは最小限にする

複数のプロジェクトを同時に参照したい場合でも、書き込み可能なルートをドライブ全体や利用者のホーム全体にする必要はありません。公式の設定リファレンスにある sandbox_workspace_write.writable_roots は、ワークスペースへ追加する場所を指定するための項目です。読み取りだけでよい資料は書き込み対象へ入れず、生成物を保存する一つのフォルダーだけを追加します。追加した理由、対象、不要になった時期をメモしておけば、あとで設定を狭める判断もできます。

なぜ今、Codexの許可設定を見直すのか

設定の考え方そのものは以前から変わりませんが、Codexの入口と連携方法は更新されています。OpenAIの公式変更履歴では、2026年8月24日に codex mcp-server コマンドを非推奨とし、Codex app serverを使うよう案内しています。これは既存の接続がその日に必ず止まるという告知ではありませんが、古い起動方法と現在のCLIリファレンスを同じものとして扱わないきっかけになります。どのクライアントがどの権限を持つのかを確認せずに設定だけコピーすると、許可が増えた理由を追えなくなります。出典: https://developers.openai.com/codex/changelog

さらに、openai/codexの公式リリースページでは、2026年8月30日に 0.152.0-alpha.4 が先行版として公開されています。先行版を通常利用の基準にする必要はありませんが、版によって表示されるフラグ、設定の読み込み、警告の内容が変わる可能性があります。更新前の版で許可が少なかったのに、更新後に増えたなら、設定の値だけでなく、実際に起動している実行ファイルと、読み込まれた設定の場所を比較してください。出典: https://github.com/openai/codex/releases/tag/rust-v0.152.0-alpha.4

更新日と版番号を記録する

記事や画面の説明には、確認した日と版番号を添えます。公式CLIリファレンスを読んだ日が同じでも、手元のCLIが別の版なら、コマンドの一覧や既定値が一致しないことがあります。codex --version の出力、起動した入口、作業フォルダー、モデル表示、設定ファイルの変更日を一つの記録にまとめると、「自分の設定が変わった」のか「版の仕様が変わった」のかを切り分けられます。

非推奨と停止を混同しない

非推奨という表示は、今後の利用先を見直す合図であって、停止日や削除版を自動的に意味するわけではありません。codex mcp-server が設定やログに見つかった場合は、まず呼び出し元と用途を確認し、現行の接続が動く状態を記録してから後継の app server を別に検討します。権限設定の記事で接続方式まで一括変更すると、許可の増減と接続先の変更が同時に起きます。原因を一つずつ比較できるよう、移行と許可調整を別の確認として扱いましょう。

許可を減らすための手順

ここからは、Codex CLIを使って許可確認の回数を減らしつつ、作業範囲を説明できる状態にする手順です。いきなり設定ファイルを上書きせず、現在の状態を記録し、読み取り、編集、外部接続の順で確認します。各段階で結果を残せば、設定を戻す必要が出たときも、どの変更が影響したかが分かります。Windowsではパスの区切り方や起動元の違いも結果に影響するため、コマンドを実行したフォルダーを省略しないでください。

Step 1: いま何が止めているかを記録する

最初に、Codexの版とその版が表示するオプションを確認します。次の二つは設定を変えずに、使えるフラグと現在の版を調べるための命令です。許可確認が表示された直後なら、実行しようとした命令と対象パスもメモします。ここで原因を「許可不足」と決めつけず、画面の文言をそのまま残すことが重要です。

codex --version
codex --help

Step 2: 作業場所を固定する

作業フォルダーが意図したプロジェクトになっているか確認します。起動場所が親フォルダーだったり、別のコピーを開いていたりすると、Codexが必要なファイルを外側へ探しに行き、許可を求めることがあります。Windowsではパスを引用符で囲み、調査だけなら読み取り専用の範囲を明示します。プロジェクトのルートと、変更してよいフォルダーを人が確認できる形にしてください。

codex --cd "C:\work\sample" --sandbox read-only --ask-for-approval untrusted "対象ファイルを読み、変更案と確認方法を説明する"

Step 3: 編集時はワークスペース内に限定する

ファイルを編集する作業では、workspace-write と on-request の組み合わせを一回の起動で試します。これはワークスペース内の通常作業を進め、そこから外れる操作では確認する構成です。実際のプロジェクトで試す前に、戻しやすい小さなファイルや検証用のコピーを使い、編集した場所、実行した命令、確認された操作を記録してください。公式文書にある値を、そのまま広い範囲へ適用しないことが大切です。

codex --cd "C:\work\sample" --sandbox workspace-write --ask-for-approval on-request "READMEの見出しを一つ整え、差分を説明する"

Step 4: 確認の種類を分けて試す

設定変更後は、読み取りだけの依頼、ワークスペース内の小さな編集、テストの実行、ネットワークを必要とする命令を別々に確認します。すべてを一つの依頼に入れると、どの操作で許可が出たのか分からなくなります。読み取りと編集が進んでも、ネットワークだけ確認されるなら、承認方針をさらに広げるのではなく、接続先が本当に必要か、通信設定がどこで決まっているかを調べます。

Step 5: 例外は一つのパスまたは命令に絞る

追加の資料フォルダーやパッケージ取得が必要になった場合は、必要な対象を一つずつ切り出します。sandbox_workspace_write.writable_roots を使う場合は、出力を置くフォルダーだけを追加し、プロジェクト全体やドライブ全体を指定しません。ネットワークが必要な場合も、接続先、目的、確認後に残る変更を記録し、用事が終わったら元の範囲へ戻します。例外を積み重ねると、最初に何を守る設定だったかが見えなくなるためです。

Step 6: 設定ファイルへ反映する

一時的なCLIフラグで望む挙動が確認できたら、毎回同じ作業をする範囲にだけ既定値を反映します。OpenAIの設定リファレンスでは、ユーザー側の config.toml と、信頼したプロジェクトで使うプロジェクト側の設定を分けて説明しています。まずは次のように、ワークスペース内の編集と境界越えの確認を明示する値から始めます。設定ファイルの位置や優先順位は、利用している版の公式ページで確認してください。出典: https://developers.openai.com/codex/config-reference/

approval_policy = "on-request"
sandbox_mode = "workspace-write"
sandbox_workspace_write.writable_roots = ["C:\\work\\sample"]

Step 7: 差分と結果を確認して終える

許可が減ったことを完了条件にせず、変更されたファイル、実行されたテスト、外部接続の有無、未確認の項目を見ます。Codexが出した説明と実際の差分が一致しているか、指定したフォルダーの外に変更がないか、必要のない命令まで通っていないかを確認します。結果に問題がなければ設定を採用し、問題があれば一段階慎重な値へ戻して、どの操作で止めるべきだったかを記録します。

Windowsで許可が多いときの確認点

Windowsでは、Codexの入口がデスクトップアプリ、CLI、IDE拡張のどれかによって、設定を変更する場所と表示名が異なります。画面上の「確認」「許可」「フルアクセス」のような言葉だけで同じ動作だと判断せず、実際の作業場所、書き込み範囲、通信の可否を比べてください。OpenAIの公式CLIリファレンスは、--cd で作業ルートを指定し、--sandbox と --ask-for-approval を起動時に指定できると説明しています。Windowsで再現条件を残すときは、ドライブ文字を含む絶対パス、起動したシェル、CLIの版番号を一緒に書きます。出典: https://developers.openai.com/codex/cli/reference/

パスの違いを疑う

同じプロジェクト名でも、同期フォルダー、作業コピー、ネットワーク上の場所では、Codexから見えるパスが異なることがあります。許可を求められた対象が、意図したルート内かを確認し、不要な親フォルダーを作業場所にしないでください。プロジェクト内に生成物を置くなら、出力先を一つの下位フォルダーへ定め、そこだけを差分確認の対象にします。許可の回数が減っても、違うコピーを編集していれば解決とは言えません。

CLIとIDEの設定を混ぜない

CLIで指定した --ask-for-approval on-request がIDE拡張の設定画面へ自動的に反映されるとは限りません。逆に、IDE側で選んだ権限プロファイルが、別のターミナルから起動したCLIにそのまま適用されるとも限りません。同じモデル名が表示されていても、入口、設定の読み込み先、作業フォルダーが違えば挙動は別です。まず一つの入口で設定を確定し、その後に別の入口を同じ条件で比較してください。

WindowsのサンドボックスやWSLを分ける

Windowsネイティブの作業とWSL内の作業では、パスの表記、ファイルシステム、起動するシェルが変わります。C:\work\sample と /mnt/c/work/sample を同じ場所として扱えるかは、利用する入口と設定によって異なるため、片方で許可を減らした結果をもう片方へそのまま移しません。OpenAIのWindows向け公式案内を確認し、どの環境でCodexが命令を実行しているかを記録してから、権限を調整してください。出典: https://developers.openai.com/codex/windows/

状況別の直し方

許可が多いときの症状は似ていますが、直す順序は異なります。下の表では、確認の回数を直接減らす値ではなく、まず原因になりやすい境界と確認方法を対応させています。変更は一度に一つにし、同じ入力で結果を比べると、設定の影響を過大評価せずに済みます。

すべてのコマンドで聞かれる

すべての命令で確認されるなら、まず read-only と untrusted の組み合わせになっていないかを見ます。調査目的ならそのままでも自然ですが、編集作業であれば、作業場所が正しいことを確認したうえで workspace-write を試します。許可を一度に通し続ける値へ変える前に、読み取り、編集、テストを順番に実施してください。各操作の結果が同じなら、設定の読み込み先や管理側の制約が別にある可能性があります。

特定のフォルダーだけ聞かれる

特定の保存先だけで止まる場合は、承認方針よりもパスの問題であることが多いです。出力先がプロジェクトの外側なら、まずプロジェクト内の専用フォルダーへ変更できないかを検討します。外側へ置く必要がある場合も、追加ルートを一つに限定し、そこへ何を保存するのかを明記します。許可を減らした後に、別のフォルダーや隠しファイルまで書き込めるようになっていないかを差分で確認してください。

ネットワークだけ聞かれる

ネットワーク接続の確認は、ファイル編集の確認とは別に考えます。パッケージの取得、ドキュメントの参照、外部APIの呼び出しなど、接続の目的を分け、なくても作業できるものは先にローカルで済ませます。OpenAIの安全運用資料も、外部接続を無制限にせず、想定した宛先と確認条件を用意する考え方を示しています。接続先を広げた結果だけで「許可設定が直った」と判断せず、通信の記録と生成物を確認してください。出典: https://openai.com/index/running-codex-safely/

更新後に急に聞かれる

更新後に確認が増えたときは、前の値が消えたと決めつけず、設定のキー名、読み込み先、プロファイル、起動時フラグを確認します。公式リファレンスに現在の版で使える値が掲載されているかを見て、古い値が警告や無視の対象になっていないかを調べます。変更前の版へ戻すことを先に選ぶより、同じ小さな作業を新旧の版で比較し、どの場面が変わったのかを記録した方が、次の更新にも応用できます。

許可を減らすときに避けたい設定

「Codex 許可 めんどくさい」という検索意図に対して、最も強い設定を勧めるのは簡単です。しかし、確認が消えたことと、安全に作業できることは同じではありません。OpenAIのCLIリファレンスは、--dangerously-bypass-approvals-and-sandbox、別名 --yolo を承認とサンドボックスの両方を迂回する危険な指定として扱い、外部で十分に保護された環境だけに限定しています。普段のプロジェクトの許可を減らす方法として使わないでください。出典: https://developers.openai.com/codex/cli/reference/

--yoloを便利な短縮指定にしない

--yolo は、確認を出さないだけの表示設定ではありません。ファイル範囲や通信の境界まで失うため、誤ったフォルダーで起動したときの影響が大きくなります。もし隔離された検証環境で一時的に使う場合でも、対象、入力、出力、終了後の破棄方法を先に決めます。日常の開発で繰り返し確認される理由を調べる代わりに使うと、原因が残ったまま見えなくなるだけです。

neverを日常の解決策にしない

approval_policy = "never" は確認を出さない値ですが、sandbox_mode が広いままだと、実行前に人が立ち止まる地点がなくなります。OpenAIの公式文書が示す on-request は、ワークスペース内の通常作業を進めながら境界越えで確認する考え方です。許可が多い場合は、まずその境界が適切かを見て、確認を残す操作と減らす操作を分けてください。

広い書き込みルートを登録しない

追加パスを指定する機能は、プロジェクト間で資料や生成物を共有するために役立ちます。一方で、ドライブ全体やホーム全体を登録すると、どこまでが対象か説明しにくくなります。必要な下位フォルダーだけを追加し、使い終わった設定を戻す習慣を作ります。許可の回数を少なくするために対象を広げるのではなく、対象を明確にすることで確認の理由を減らすのが基本です。

設定変更後の確認記録を残す

許可設定は一度決めたら終わりではなく、版、入口、プロジェクト、作業内容によって結果が変わります。最低限、確認日、Codexの版、起動方法、作業フォルダー、approval_policy、sandbox_mode、追加した書き込み先、ネットワークの要否、変更されたファイル、テスト結果を残します。設定ファイルの値だけを貼るのではなく、実際にどの操作が確認なしで進み、どの操作で止まったかを書いてください。

この記録があれば、次のアップデートで確認が増えたときも、設定を最も弱い値から順に見直せます。反対に、確認を減らした結果だけを残すと、何を許可したのかが分からず、別のプロジェクトへ同じ設定を持ち込む判断もできません。許可を減らす目的は、止まる画面をなくすことではなく、人が見るべき境界を明確にして、通常の作業をそこで滞らせないことです。

まとめ

Codexの許可確認が多いときは、承認方針とサンドボックスを別々に確認し、作業場所を正しく指定することから始めます。日常の編集では workspace-write と on-request を小さな対象で試し、追加パスや通信は必要な範囲だけに絞ります。--yolo や never へ直行すると、確認回数は減っても境界と原因が見えなくなるため、通常の解決策にはしません。

2026年8月24日の codex mcp-server 非推奨化と、8月30日のCodex CLI 0.152.0-alpha.4公開が示すように、Codexの入口と版は更新されます。OpenAIの公式CLIリファレンス、サンドボックス文書、設定リファレンス、公式リリースを確認し、版番号と設定を記録しながら調整してください。そうすれば「Codex 許可 めんどくさい」という状態を、広い権限で隠すのではなく、必要な確認だけが出る作業環境へ近づけられます。