Codexで毎回承認を求められる原因と対処法｜フルアクセス・Google Drive・プロジェクトの違いを解説

Codex DesktopやCodexエージェントを使っていると、ファイルを編集したいだけなのに毎回のように承認を求められ、作業が止まってしまうことがあります。

特に、現在のスレッドの作業フォルダとは別の場所にあるファイルを編集しようとすると、approval_policy = "never" を設定しているのに承認が出る、ファイルに触れない、といった状況になりやすいです。Google Driveとミラーリングしているフォルダでも、仕組みとしては「Google Driveだから」ではなく、「現在の作業フォルダや権限プロファイルの外側にあるかどうか」が重要です。

この記事では、Codexの承認依頼がなぜ発生するのか、Codex Desktopの新規チャット画面でどの項目を選べばよいのか、config.toml や内部状態ファイルでは何を確認すればよいのかを、初心者の方にもわかるように整理します。

  1. この記事でわかること
  2. 検証環境と確認日
  3. まず結論：画面では2か所を確認する
  4. Google Driveのミラーリングは関係あるのか
  5. Codexの承認は何で決まるのか
  6. 「プロジェクト」と「作業フォルダ / workspace」は別物
  7. 承認が頻発しやすい例
  8. Google Driveのミラーリングフォルダで作業する手順
    1. 手順1：新しいチャット画面を開く
    2. 手順2：「プロジェクトで作業」を開く
    3. 手順3：未登録なら「新しいプロジェクトを追加」から追加する
    4. 手順4：「デフォルト権限」メニューを開く
    5. 手順5：「フルアクセス」を選ぶ
    6. 手順6：その状態で会話を開始する
  9. 権限メニューの違い
    1. デフォルト権限
    2. 自動レビュー
    3. フルアクセス
    4. カスタム（config.toml）
  10. config.tomlで確認する項目
  11. 特定の作業フォルダを許可するconfig.tomlの例
  12. .codex-global-state.jsonで確認できること
  13. 「サンドボックス側で PowerShell 起動が弾かれました。」と表示される場合
  14. フルアクセスでも承認が残る可能性がある操作
  15. 承認依頼を減らすためのチェックリスト
  16. よくある質問
    1. approval_policy = “never” にしているのに承認が出るのはなぜですか？
    2. Google Driveが原因ですか？
    3. フルアクセスを選べば完全に承認は出なくなりますか？
    4. .codex-global-state.json は編集してもよいですか？
    5. 「サンドボックス側で PowerShell 起動が弾かれました。」は承認設定の問題ですか？
  17. まとめ
  18. 参考情報

この記事でわかること

  • Codexで承認依頼が頻発する主な原因
  • approval_policy = "never" だけでは承認が減らないことがある理由
  • 「プロジェクト」と「作業フォルダ / workspace」の違い
  • Google Driveのミラーリングフォルダが関係する場合と、関係しない場合
  • 「デフォルト権限」「自動レビュー」「フルアクセス」「カスタム（config.toml）」の違い
  • config.toml と .codex-global-state.json で確認できること
  • 「サンドボックス側で PowerShell 起動が弾かれました。」と表示される場合の考え方

検証環境と確認日

項目内容
確認日2026年5月25日
対象Codex Desktop / Codexエージェント
OSWindows環境を想定
作業フォルダ例C:\Users\example\Google Drive\Projects\sample-app
参考情報OpenAI公式Codexドキュメント

Codex Desktopの画面表示や設定項目は、アップデートによって変わる可能性があります。この記事では、2026年5月時点で確認できるCodexの権限設定と公式ドキュメントをもとに整理しています。

まず結論：画面では2か所を確認する

Codexで承認依頼をできるだけ減らしたい場合、config.toml の approval_policy = "never" だけを見るのではなく、新しいチャットを開始するときに次の2か所を確認するのが重要です。

プロジェクトで作業 → Google Drive側のプロジェクトを選択
デフォルト権限 → フルアクセスを選択

Google Driveのミラーリングフォルダで作業したい場合は、そのフォルダが現在のスレッドの作業フォルダ、または書き込み可能な範囲に入っている必要があります。

たとえば、次のようなGoogle Drive配下のフォルダで作業したいとします。

C:\Users\example\Google Drive\Projects\sample-app
C:\Users\example\Google Drive\Projects\finance-notes

この場合、新規チャットをCodexの一時フォルダで開始してからGoogle Drive側を操作しようとするより、最初から「プロジェクトで作業」から対象フォルダを選んで開始するほうが、承認依頼を減らしやすくなります。

Google Driveのミラーリングは関係あるのか

結論からいうと、Google Driveのミラーリング自体が承認要求の直接原因とは限りません。

Codexから見て重要なのは、そのフォルダが現在のスレッドの作業フォルダ、または権限プロファイルで許可された作業ルートに入っているかどうかです。

たとえば、次の2つはCodexから見ると同じ問題として扱われる可能性があります。

C:\Users\example\Google Drive\Projects\sample-app
C:\dev\sample-app

どちらも、現在のスレッドが別の一時フォルダで始まっていて、上記のフォルダが作業ルートに入っていなければ、作業フォルダ外の操作として承認や制限の対象になりやすくなります。

つまり、Google Driveは「クラウド同期だから特別に承認が増える」というより、「普段の作業場所がCodexの現在のworkspace外になりやすい」という意味で関係します。Google Driveを使っていない通常のローカルフォルダでも、同じようにworkspace外であれば承認が出る可能性があります。

そのため、Google Driveを使っていない場合でも、この記事の本質は同じです。確認すべきポイントは、次の2つです。

  • そのスレッドの作業フォルダが、編集したいフォルダになっているか
  • config.toml の権限設定で、そのフォルダが作業ルートとして許可されているか

Codexの承認は何で決まるのか

Codexの承認依頼は、単に approval_policy だけで決まるわけではありません。

主に次の要素が関係します。

  • 画面上で選んだ権限モード
  • スレッドに紐づいた作業フォルダ
  • サンドボックスの書き込み可能範囲
  • Google Drive配下のフォルダが現在のスレッドで許可されているか
  • ネットワークアクセスの有無
  • 外部アプリやGUIアプリの起動
  • 削除、リセット、権限変更などの危険度が高い操作

OpenAIのCodex公式ドキュメントでは、Codexの安全制御は「サンドボックスモード」と「承認ポリシー」の2層で説明されています。サンドボックスモードはCodexが技術的にどこまで触れるか、承認ポリシーはどのタイミングでユーザーに確認するかを決めるものです。

つまり、approval_policy = "never" は「承認を求めない方向の設定」ですが、現在の作業フォルダが違っていたり、サンドボックス側でアクセスできない場所を操作しようとしていたりすると、期待どおりに動かないことがあります。

「プロジェクト」と「作業フォルダ / workspace」は別物

Codex Desktopでつまずきやすいのが、「プロジェクト」と「作業フォルダ / workspace」を同じものだと思ってしまうことです。

わかりやすく分けると、次のようになります。

プロジェクト
= Codex Desktop上で会話や作業をまとめる表示上の単位

作業フォルダ / workspace
= そのスレッドでCodexが実際に読み書きするローカルフォルダ

Codex Desktopの左側に表示されるプロジェクトは、会話や作業を整理するための単位です。一方で、Codexが実際にファイルを読み書きできる範囲は、そのスレッドに紐づいた作業フォルダやサンドボックス設定によって決まります。

そのため、見た目上は同じプロジェクト内で会話しているように見えても、スレッドの作業フォルダがGoogle Drive側ではなくCodexの一時フォルダになっていると、Google Drive配下のファイル操作で承認が出やすくなります。

承認が頻発しやすい例

たとえば、現在のスレッドが次のようなCodexの一時フォルダで始まっているとします。

C:\Users\example\Documents\Codex\2026-05-25\codex

この状態で、次のGoogle Drive配下のフォルダを編集しようとします。

C:\Users\example\Google Drive\Projects\sample-app

この場合、Codexから見ると「現在の作業フォルダの外側にあるファイルを触ろうとしている」状態になりやすくなります。

サンドボックスが作業フォルダ内の編集を前提にしている場合、作業フォルダ外へのアクセスや書き込みでは承認が必要になったり、操作自体が弾かれたりする可能性があります。

Google Driveのミラーリングフォルダで作業する手順

Google Driveとローカルフォルダをミラーリングしている場合は、新しいチャットを開始するときに、最初から対象フォルダを作業場所として選びます。

手順1：新しいチャット画面を開く

Codex Desktopで新しいチャットを開始します。

この時点で、いきなり指示を入力するのではなく、入力欄周辺の設定を確認します。

手順2：「プロジェクトで作業」を開く

新規チャット画面の下部にある「プロジェクトで作業」を開きます。

ここで、作業したいGoogle Drive側のプロジェクトを選びます。

例:

sample-app
finance-notes

手順3：未登録なら「新しいプロジェクトを追加」から追加する

対象のプロジェクトが表示されていない場合は、次の項目からGoogle Drive側のフォルダを追加します。

新しいプロジェクトを追加

追加するフォルダの例:

C:\Users\example\Google Drive\Projects\sample-app
C:\Users\example\Google Drive\Projects\finance-notes

Google Driveの「マイドライブ」全体を広く指定するより、実際に作業するプロジェクトフォルダ単位で追加するほうが管理しやすいです。

手順4：「デフォルト権限」メニューを開く

入力欄付近に、次のような権限メニューがあります。

デフォルト権限 ▼

このメニューが、承認頻度に直接関係します。

手順5：「フルアクセス」を選ぶ

承認依頼をできるだけ減らしたい場合は、権限メニューから「フルアクセス」を選びます。

フルアクセス

ただし、フルアクセスは便利な反面、Codexが広い範囲にアクセスできる設定です。信頼できる作業フォルダで、内容を把握しているタスクに対して使うのがおすすめです。

手順6：その状態で会話を開始する

「プロジェクトで作業」と「フルアクセス」を確認した状態で、Codexに作業を依頼します。

これにより、少なくとも「作業したいGoogle Driveフォルダが現在のスレッドの外側にあるため承認が増える」という状況は避けやすくなります。

権限メニューの違い

Codex Desktopの権限メニューには、次のような選択肢があります。

デフォルト権限
自動レビュー
フルアクセス
カスタム（config.toml）

それぞれの意味を整理すると、次のようになります。

項目意味承認の出やすさ向いている使い方
デフォルト権限現在の標準的な安全設定で動かす中通常の編集、調査、軽い修正
自動レビュー一部の承認判断を自動レビューに任せる低〜中承認の手間を減らしつつ、安全確認も残したい場合
フルアクセスサンドボックス制限と承認を大きく緩める低信頼できる作業フォルダで、長めの自動作業をさせたい場合
カスタム（config.toml）config.toml の設定を使う設定次第自分で細かく制御したい場合

デフォルト権限

デフォルト権限は、Codexが現在の作業フォルダ内で読み書きし、必要に応じて承認を求める標準的な使い方です。

初心者の方や、まだCodexに任せる範囲を決めきれていない場合は、まずこの設定で動きを確認するのが安全です。

一方で、Google Drive配下の別フォルダや、現在の作業フォルダ外のファイルに触れようとすると、承認が増えやすくなります。

自動レビュー

自動レビューは、承認が必要な操作のうち、条件に合うものをCodex側のレビューで自動的に判断する設定です。

ユーザーが毎回止められる回数を減らしつつ、すべてを無条件に通すわけではない、中間的な位置づけです。

ただし、危険度が高い操作や、ポリシー上ユーザー確認が必要な操作では、引き続き承認が必要になる可能性があります。

フルアクセス

フルアクセスは、承認依頼をできるだけ減らしたい場合に選ぶ設定です。

Codex公式ドキュメントでは、フルアクセス相当の考え方として、sandbox_mode = "danger-full-access" と approval_policy = "never" の組み合わせが説明されています。

ただし、名前のとおり強い権限です。作業対象を間違えると、意図しないファイル変更や削除につながる可能性があります。

フルアクセスを使う場合でも、次のような対策をおすすめします。

  • Git管理されているフォルダで使う
  • 重要なファイルはバックアップしておく
  • 削除やリセットを含む作業では指示を具体的にする
  • 最初は小さな作業で動作を確認する

カスタム（config.toml）

カスタム（config.toml）は、Codexの設定ファイルに書いた内容をもとに動かす選択肢です。

自分で承認ポリシー、サンドボックス、ネットワーク、プロジェクト信頼設定などを管理したい場合に使います。

ただし、config.toml に書いた内容と、現在のスレッドの作業フォルダや画面上の選択がずれていると、「設定したはずなのに承認が出る」という状態になります。

config.tomlで確認する項目

Codexの設定ファイルは、Windowsでは通常次の場所にあります。

C:\Users\example\.codex\config.toml

承認関連で確認したい代表的な設定は次のとおりです。

approval_policy = "never"

[windows]
sandbox = "elevated"

approval_policy = "never" は、承認プロンプトを出さない方向の設定です。

[windows] sandbox = "elevated" は、Windowsネイティブ環境で推奨される強めのサンドボックス方式です。OpenAIのWindows向けドキュメントでも、利用できる場合は elevated が推奨されています。

特定の作業フォルダを許可するconfig.tomlの例

特定の作業フォルダだけで承認要求を減らしたい場合は、default_permissions と [permissions] を使って、そのフォルダを作業ルートとして登録する方法があります。

ここでは例として、次のフォルダをCodex用の作業場所にします。

C:\codex-workspaces\sample-project

C:\Users\example\.codex\config.toml に書く例は次のとおりです。

approval_policy = "never"
default_permissions = "codex-work"

[windows]
sandbox = "elevated"

[permissions.codex-work.workspace_roots]
"C:\\codex-workspaces\\sample-project" = true

[permissions.codex-work.filesystem]
":minimal" = "read"

[permissions.codex-work.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

この設定では、C:\codex-workspaces\sample-project を作業ルートとして扱い、その中ではファイルの読み書きを許可します。一方で、.env のような環境変数ファイルは読めないようにしています。

ポイントは、approval_policy = "never" だけではなく、default_permissions で使う権限プロファイルを指定し、そのプロファイル内で作業ルートを明示することです。

ただし、この設定を入れても、すべての承認や制限が消えるわけではありません。ネットワークアクセス、外部アプリ起動、破壊的な操作、Codexアプリ側の画面設定、組織管理ポリシーなどによって、別の確認や制限が残る場合があります。

また、OpenAIの権限プロファイルの説明では、default_permissions / [permissions] と古い sandbox_mode / sandbox_workspace_write 系の設定は混在させないよう案内されています。新しい権限プロファイルで管理する場合は、古いサンドボックス設定が残っていないかも確認してください。

また、Google Drive側のプロジェクトが信頼済みとして登録されている場合、次のような設定があることがあります。

[projects.'c:\users\example\google drive\projects\sample-app']
trust_level = "trusted"

[projects.'c:\users\example\google drive\projects\finance-notes']
trust_level = "trusted"

ただし、ここで trusted になっていても、そのスレッドの作業フォルダとして選ばれていなければ、承認が出ることがあります。

trusted は「そのプロジェクトを信頼する」設定であり、「今開いているスレッドがそのフォルダを作業場所にしている」こととは別です。

.codex-global-state.jsonで確認できること

Codexの内部状態として、次のファイルにスレッドごとの権限情報が保存されている場合があります。

C:\Users\example\.codex\.codex-global-state.json

ここには、スレッドごとの approvalPolicy や writableRoots が含まれることがあります。

たとえば、次のような状態です。

"approvalPolicy": "on-request",
"writableRoots": [
  "C:\\Users\\example\\Documents\\Codex\\2026-05-25\\codex",
  "C:\\Users\\example\\Documents\\Codex"
]

この場合、そのスレッドはGoogle Drive配下ではなく、Codexの一時フォルダを作業場所として持っていると考えられます。

一方で、Google Drive側のプロジェクトとして作成されたスレッドでは、次のようになります。

"writableRoots": [
  "C:\\Users\\example\\Google Drive\\Projects\\sample-app"
]

このように、writableRoots を見ると、そのスレッドでCodexがどのフォルダを作業範囲として扱っているかを確認できます。

ただし、.codex-global-state.json はCodexアプリの内部状態です。直接編集すると予期しない動作につながる可能性があるため、基本的には確認用途に留めるのがおすすめです。

「サンドボックス側で PowerShell 起動が弾かれました。」と表示される場合

Codex DesktopでWindows環境を使っていると、次のようなメッセージが表示されることがあります。

サンドボックス側で PowerShell 起動が弾かれました。

このメッセージは、Google Driveのミラーリングとは直接関係しない場合があります。

PowerShellそのものの問題というより、CodexのサンドボックスがWindows上でコマンド実行を開始できなかった、または現在の権限設定ではそのコマンド実行を許可できなかったことを示している可能性があります。

考えられる原因は次のとおりです。

  • 現在のサンドボックス設定でPowerShell起動が許可されていない
  • 作業フォルダ外のファイルにアクセスしようとしている
  • Windowsの elevated サンドボックス設定がうまく動いていない
  • 企業PCなどでローカルユーザー作成、ファイアウォール、ログオン権限が制限されている
  • Codexが安全上、現在の操作をそのまま通せないと判断している

OpenAIのWindows向けドキュメントでは、Windowsネイティブのサンドボックスとして elevated と unelevated が説明されています。elevated は推奨される方式ですが、環境ポリシーによってはセットアップに失敗することがあります。

このメッセージが出る場合は、まず次を確認します。

  • 権限メニューで「フルアクセス」または意図した設定を選んでいるか
  • C:\Users\example\.codex\config.toml の [windows] sandbox = "elevated" が設定されているか
  • 編集したいフォルダが作業フォルダ、または権限プロファイルの作業ルートに入っているか
  • Windowsの管理者権限や企業ポリシーでCodexのサンドボックス設定がブロックされていないか
  • 必要であればCodexを再起動して、同じ操作を再試行する

一時的に作業を進めたい場合は、Codexの権限メニューやWindowsサンドボックス設定を見直す必要があります。ただし、フルアクセスを使う場合は、信頼できるフォルダで作業し、削除やリセットを含む操作には特に注意してください。

フルアクセスでも承認が残る可能性がある操作

フルアクセスは承認依頼を大幅に減らす設定ですが、すべての確認を100%消すものと考えないほうが安全です。

次のような操作では、環境やCodexのバージョン、管理ポリシーによって承認や制限が残る可能性があります。

  • ネットワークアクセス
  • 外部アプリやGUIアプリの起動
  • ブラウザ操作、MCP、コネクタなど別系統のツール呼び出し
  • 削除、リセット、権限変更などの破壊的操作
  • サンドボックス外フォルダへのアクセス
  • 未承認の特殊なコマンド
  • セキュリティ上、Codexが危険と判断する操作

特にネットワークアクセスは、サンドボックスや権限プロファイルとは別に制御される場合があります。ローカルファイル編集は通るのに、外部サイトへのアクセスやパッケージ取得で止まる場合は、ネットワーク設定も確認してください。

承認依頼を減らすためのチェックリスト

Codexで毎回承認を求められる場合は、次の順番で確認すると整理しやすいです。

  • 新しいチャットを作り直す
  • 「プロジェクトで作業」から作業対象のフォルダを選ぶ
  • 作業対象のプロジェクトが未登録なら追加する
  • 「デフォルト権限」メニューから「フルアクセス」を選ぶ
  • config.toml の approval_policy、default_permissions、Windowsサンドボックス設定を確認する
  • .codex-global-state.json で writableRoots が対象フォルダになっているか確認する
  • それでも止まる場合は、ネットワーク、外部アプリ、破壊的操作など別の承認要因を疑う

ここで大事なのは、「プロジェクトを選んだつもり」ではなく、「現在のスレッドの作業フォルダが本当に対象フォルダになっているか」を見ることです。

よくある質問

approval_policy = “never” にしているのに承認が出るのはなぜですか？

approval_policy は承認プロンプトの出し方に関係しますが、Codexの動作範囲はサンドボックスや作業フォルダにも影響されます。

現在のスレッドがGoogle Drive側ではなくCodexの一時フォルダで開始されている場合、Google Drive配下のファイル操作は作業フォルダ外の操作として扱われ、承認や制限が発生しやすくなります。

Google Driveが原因ですか？

Google Driveそのものが直接の原因とは限りません。

ただし、Google Driveのミラーリング先が現在のスレッドの作業フォルダや権限プロファイルの作業ルートに入っていない場合、Codexから見ると「許可された範囲の外側を操作している」状態になります。その結果、承認が増えることがあります。

同じことは、Google Driveではない通常のローカルフォルダでも起こります。Google Driveだけが原因なのではなく、workspace外のフォルダを操作しようとしているかどうかがポイントです。

フルアクセスを選べば完全に承認は出なくなりますか？

完全に出なくなるとは限りません。

フルアクセスは承認を大幅に減らす設定ですが、ネットワークアクセス、外部アプリ起動、破壊的操作、管理ポリシーで制限された操作などでは、引き続き止まる可能性があります。

.codex-global-state.json は編集してもよいですか？

基本的には編集しないほうが安全です。

.codex-global-state.json はCodexアプリの内部状態を保存するファイルです。approvalPolicy や writableRoots の確認には役立ちますが、直接編集するとCodex Desktop側の状態とずれる可能性があります。

設定を変えたい場合は、Codex Desktopの画面操作や config.toml を使うほうが安全です。

「サンドボックス側で PowerShell 起動が弾かれました。」は承認設定の問題ですか？

承認設定だけでなく、Windowsサンドボックス設定や作業フォルダの範囲が関係している可能性があります。ただし、Google Driveミラーリングが直接原因とは限りません。

まずは権限メニューで意図した設定を選んでいるか、config.toml の [windows] sandbox = "elevated" が設定されているか、作業対象フォルダがworkspaceまたは権限プロファイルの作業ルートに入っているかを確認してください。

まとめ

Codexで承認依頼を減らすには、config.toml の approval_policy = "never" だけでは不十分な場合があります。

特に普段の作業フォルダがCodexの一時フォルダとは別の場所にある場合は、新しいチャット開始時に次の2点を確認するのが重要です。

プロジェクトで作業 → 作業対象のプロジェクトを選択
デフォルト権限 → フルアクセスを選択

「プロジェクト」はCodex Desktop上で会話を整理する単位であり、「作業フォルダ / workspace」はCodexが実際に読み書きするローカルフォルダです。この違いを意識すると、なぜ承認が出るのかを切り分けやすくなります。

フルアクセスは便利ですが、広い権限を与える設定です。信頼できる作業フォルダで使い、削除やリセットを含む作業では慎重に指示するようにしましょう。

参考情報