Codex が何度も承認を求めてくる？ 承認ポリシー、サンドボックス、「don’t ask again」を解説
Codex は、コマンドがサンドボックスの外に出る必要があるときに承認を求めます。「何度も聞いてくる」という不満の多くは、制限が厳しすぎるサンドボックス、もう存在しない設定、あるいはセッション中しか持続しない「don’t ask again」が原因です。
要点
現在の Codex では、approval_policy は on-request（デフォルト。モデルが必要なときに確認する）、never、または granular テーブルのいずれかです。untrusted は削除され、on-failure は今では on-request の別名にすぎません。確認の頻度を主に決めるのはサンドボックスです。sandbox_mode = "workspace-write" なら、Codex はプロジェクト内で確認なしにファイルを編集し、コマンドを実行します。常に信頼するコマンドには、~/.codex/rules/default.rules に decision = "allow" を指定した prefix_rule を追加します。「don’t ask again for commands that start with …」もここに保存されます。
まず確認: Codex の変更点
多くのガイドやフォーラムの回答は、もう機能しない設定を紹介しています。何かを調整する前に、~/.codex/config.toml を次の一覧と照らし合わせてください。
| 以前の設定 | 現在 |
|---|---|
approval_policy = "untrusted" | 削除されました。Codex は「approval_policy = "untrusted" is no longer supported; remove this setting」と報告します。ドキュメントでは代わりに sandbox_mode = "read-only" と on-request の組み合わせが推奨されています。 |
approval_policy = "on-failure" | 引き続き受け付けられますが、on-request の別名としてのみです。 |
--full-auto | CLI リファレンスから消えました。最も近いフラグは --approve-for-me（別名 --not-so-yolo）で、on-request と workspace-write サンドボックスによる自動承認レビューを行います。 |
config.toml 内の [profiles.name] | Codex 0.134.0 以降、--profile name は代わりに $CODEX_HOME/name.config.toml を読み込みます。profile = "x" キーが残っているとエラーになります。 |
/approvals | /permissions（「Set what Codex can do without asking first.」）を使います |
Codex のドキュメントも移転しました。以前の developers.openai.com/codex のページは、現在 learn.chatgpt.com にリダイレクトされます。
Codex が確認するかどうかを決める仕組み
2 つの設定が連動します。サンドボックスは、コマンドが触れられる範囲（プロジェクト外のファイル、ネットワーク）を制限します。承認ポリシーは、コマンドがサンドボックスの許可を超える操作を必要としたときにどうするかを決めます。
| sandbox_mode | Codex が確認なしでできること |
|---|---|
read-only（デフォルト） | 読み取り専用のサンドボックスでファイルを読み、コマンドを実行する |
workspace-write | 作業ディレクトリ内での読み取り、編集、コマンド実行を自動で行う |
danger-full-access | サンドボックスなしで何でもできる。非推奨 |
| approval_policy | 動作 |
|---|---|
on-request（デフォルト） | 確認するタイミングはモデルが判断する。サンドボックスが許可するコマンドは承認なしで実行される |
never | 決して確認しない。失敗した操作はあなたに上げられず、モデルに返される |
{ granular = { … } } | 一部の確認カテゴリだけを対話式に残し、残りは自動で拒否する（sandbox_approval、rules、skill_approval、request_permissions、mcp_elicitations） |
つまり read-only では、すべての編集に承認が必要です。これが「Codex が何でも聞いてくる」の最もよくある原因です。workspace-write でも .git、.codex、.agents、.aws は読み取り専用のままで、ネットワークアクセスは自分で有効にしない限りオフです。
次は OpenAI のドキュメントにあるサンプル設定で、ワークスペースのオプションに説明を付けたものです。
新しいバージョンでは権限プロファイル（組み込みの :read-only、:workspace、:danger-full-access を持つ default_permissions）も使えます。プロファイルと sandbox_mode はどちらか一方だけを使い、併用しないでください。
CLI、IDE 拡張機能、アプリのプリセット
TOML を編集する必要はありません。CLI では /permissions でプリセットが開き、アプリと IDE 拡張機能ではコンポーザーの下に権限の切り替えがあります。CLI のプリセットは次のとおりです。
- Read Only: ワークスペースを読み取ります。ファイルの編集やインターネットへのアクセスには承認が必要です。
- Default: ワークスペース内で編集します。インターネットへのアクセスや他のファイルの編集には承認が必要です。
- Full Access: ワークスペース外の編集やインターネットの利用を確認なしで行います。
アプリと IDE 拡張機能では、同じ選択肢が Ask for approval、Approve for me、Full access と表示されます。古い IDE のスクリーンショットでは Chat、Agent、Agent (Full Access) と呼ばれています。
ルールで特定のコマンドを許可する
特定のコマンド（たとえば gh pr view）をサンドボックスの外で確認なしに実行させたいときは、ルールを書きます。ルールは試験的な機能で、設定レイヤーの隣にある rules/ フォルダー内の .rules ファイルに置きます。例: ~/.codex/rules/default.rules
allow: 確認なしでサンドボックスの外で実行します。prompt: 一致するコマンドのたびに確認します。forbidden: 確認せずにブロックします。
複数のルールが一致した場合は、最も制限の強いものが優先されます。優先順位は forbidden、prompt、allow の順です。ルールに頼る前に、codex execpolicy check でコマンドをテストしてください。
「don’t ask again」が実際に保存するもの
Codex CLI の承認プロンプトには何種類かの「yes」があり、その持続期間は大きく異なります。
| 選択肢 | 持続期間 |
|---|---|
| Yes, proceed | このコマンド 1 回のみ |
Yes, and don’t ask again for commands that start with <prefix> | 永続的（ルールとして ~/.codex/rules/default.rules に書き込まれる） |
| Yes, and don’t ask again for this command in this session | セッション終了まで |
| Yes, and don’t ask again for these files | ファイル編集、このセッションのみ |
セッション単位の選択肢ばかり選んでいると、翌日また聞かれます。プレフィックスの選択肢を選ぶか、自分でルールを書きましょう。
Windows での Codex
「何でも聞いてくる」問題が最もひどかったのは Windows でした。issue #10187 で、OpenAI のチームメンバーがその理由を説明しています。「Without a sandboxing mechanism, all tool calls need to be manually approved on Windows.」（サンドボックスの仕組みがないため、Windows ではすべてのツール呼び出しを手動で承認する必要がある）。現在の Codex にはネイティブの Windows サンドボックスがあり、デフォルトで使用されます。
mxc: 対応する Windows デバイスで推奨されるサンドボックス。elevated: MXC が使えない場合の推奨フォールバック。unelevated: 従来のフォールバック。
CLI で /setup-default-sandbox を実行すると、elevated サンドボックスがセットアップされます（IT 部門向けには codex sandbox setup --elevated）。Windows 11 を推奨し、Windows 10 1809 以降はベストエフォートでのサポートです。WSL で作業する場合、Codex はそこで Linux のサンドボックスを使います。WSL1 はサポートされなくなりました。
プロジェクト設定は信頼済みプロジェクトでのみ読み込まれる
リポジトリ内の .codex/config.toml は、そのプロジェクトを信頼した場合にのみ読み込まれます。プロジェクト設定が無視されているように見えるなら、これが原因です。ユーザー設定の信頼エントリは次のようになります。
設定はレイヤー構造で、優先度の高い順に、コマンドラインフラグと -c による上書き、信頼済みプロジェクトの .codex/config.toml、--profile のファイル、~/.codex/config.toml、システムのデフォルトです。
--yolo について
--dangerously-bypass-approvals-and-sandbox（別名 --yolo）は、すべてのコマンドを承認もサンドボックスもなしで実行します。ソースコードには「EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.」（極めて危険。外部でサンドボックス化された環境での実行専用）と書かれています。設定ファイルで approval_policy = "never" と danger-full-access を組み合わせても同じです。確認を減らしたいだけなら、workspace-write といくつかの allow ルールで、サンドボックスを有効にしたまま実現できます。
残した確認をどう扱うか
Codex が重要なこと（ネットワーク、プロジェクト外のファイル、push）だけを聞くようになれば、残る問題は質問に気づくことです。Pet Island は、Codex のコマンド承認とファイル編集の承認を、コマンドや差分とともに画面上部の小さなアイランドに表示します。正しいターミナルを探さなくても許可や拒否ができます。Codex が作業中か完了したかも表示され、Codex からの質問はワンクリックで該当のウィンドウに移動できます。Codex CLI と Codex アプリの両方で動作し、アイランドを閉じている場合、Codex は通常どおり自分のウィンドウで確認します。
よくある質問
Codex が常に承認を求めてくるのを止めるには？
sandbox_mode = "workspace-write" にして Codex がプロジェクト内で編集とコマンド実行をできるようにし、approval_policy = "on-request" はそのままにして、常に信頼するコマンドについては ~/.codex/rules/default.rules に decision = "allow" の prefix_rule エントリを追加します。
approval_policy = "untrusted" はまだサポートされていますか？
いいえ。現在の Codex は「approval_policy = "untrusted" is no longer supported; remove this setting」というメッセージで拒否します。代わりに sandbox_mode = "read-only" と approval_policy = "on-request" を使います。
--full-auto はどうなりましたか？
Codex CLI リファレンスから消えました。最も近いオプションは --approve-for-me（別名 --not-so-yolo）で、on-request と workspace-write サンドボックスによる自動承認レビューを使います。
「don’t ask again」が保持されないのはなぜですか？
「Don’t ask again for this command in this session」はそのセッション中しか持続しません。「don’t ask again for commands that start with …」を選ぶと、~/.codex/rules/default.rules にルールが保存されます。
Windows で Codex の確認が多いのはなぜですか？
サンドボックスがないと、すべてのツール呼び出しに承認が必要になるためです。現在の Codex はデフォルトでネイティブの Windows サンドボックスを使います。セットアップされていない場合は /setup-default-sandbox を実行してください。
プロジェクトの .codex/config.toml が無視されるのはなぜですか？
Codex は信頼済みのプロジェクトでのみプロジェクト設定を読み込むためです。
出典
このページの設定と動作はすべて、2026年10月26日 に以下のページと照らし合わせて確認しました。エージェントは変化が速いため、内容が一致しなくなった場合は公式ページの記述を優先してください。
- OpenAI: Codex エージェントの承認とセキュリティ
- OpenAI: Codex の権限モード
- OpenAI: Codex 設定の基本
- OpenAI: Codex サンプル設定
- OpenAI: Codex ルール
- OpenAI: Codex Windows サンドボックス
- OpenAI: Codex CLI リファレンス
- OpenAI: Codex スラッシュコマンド
- openai/codex ソースコード（承認プロンプト、設定エラー）
- Issue #10187: Codex がコマンドの承認を繰り返し求める
- Issue #5131: ファイル編集を毎回承認しなければならない
- Issue #29406: don’t ask again を選んでも承認プロンプトが出続ける