Codexで「一度だけ許可」が出続けるときの設定―Full AccessとWindows Sandboxを確認する

VS CodeのCodexでコマンド実行のたびに「一度だけ許可」が出る状態を、Permission ProfileとWindows Sandboxの設定を見直して解消した手順を記録します。

執筆:ゆまラボ運営者

公開:更新:
Codexで「一度だけ許可」が出続けるときの設定―Full AccessとWindows Sandboxを確認する

VS CodeでCodexに修正を任せていると、ターミナルコマンドを実行するたびに「一度だけ許可」が出るようになった。

ファイルを読むだけの処理でも止まるため、ある程度まとまった作業を任せる使い方ではかなり邪魔になる。自分の環境では、Codexにはローカルの開発作業をある程度連続して進めてもらいたいので、毎回手動で承認する状態は避けたかった。

最初に、Windowsのユーザー設定にある config.toml を確認した。

%USERPROFILE%\.codex\config.toml

ここにはすでに次の設定を入れていた。

approval_policy = "never"
sandbox_mode = "danger-full-access"

approval_policy = "never" まで入っているので、見た目だけなら承認は出なさそうに見える。ただ、VS Code側のCodexでは「承認を求める」が有効なままで、Full Accessとして扱われていなかった。

Permission Profile方式へ切り替える#

現在のCodexには、従来の sandbox_mode とは別にPermission Profileがある。

組み込みのPermission Profileは次の3つ。

  • :read-only
  • :workspace
  • :danger-full-access

OpenAIの公式ドキュメントでは、Permission Profileを使う場合は default_permissions を指定する。また、default_permissions と従来の sandbox_mode / sandbox_workspace_write は混在させないよう案内されている。

どこかの読み込み対象設定に sandbox_mode が残っている場合は、Permission Profileではなく従来のsandbox設定が使われる。

今回は、先頭の設定を次のように変更した。

変更前。

approval_policy = "never"
sandbox_mode = "danger-full-access"

変更後。

approval_policy = "never"
default_permissions = ":danger-full-access"

approval_policydefault_permissions は役割が違う。

approval_policy は、Codexがコマンド実行前に承認で停止するタイミングを制御する設定。default_permissions は、ローカルコマンドにどの範囲までアクセスを与えるかを決めるPermission Profileの指定になる。

プロジェクト単位で設定していた trust_level はそのまま残した。

[projects.'C:\path\to\project']
trust_level = "trusted"

設定を保存したあと、VS Codeを終了して起動し直す。

Codexの承認方法を開くと、今度は「フルアクセス」にチェックが付くようになった。

Codexの承認方法でフルアクセスが有効になった画面

ここまでは狙った状態になった。

Full Accessにしても既存の作業では承認が残った#

ただし、切り替え直後に動いていた作業では、まだ「一度だけ許可」が表示された。

Full Accessへ変更後も表示されたコマンド実行の承認画面

この時点で、Permission Profileの表示自体はFull Accessになっている。

設定ファイルをさらに増やす前に、新しいチャットで状態を確認することにした。既存の作業がどの権限状態を保持しているかは画面だけでは判断できないため、切り替え後の状態で新規に開始した方が切り分けしやすい。

ところが、新しいチャットを開始しようとすると別のエラーが出た。

メッセージを送信できませんでした
エージェント サンドボックスを設定して続行する

Codexでエージェントサンドボックスの設定を求められメッセージを送信できない画面

Full Accessの選択とは別に、Windows側のAgent Sandboxの初期化で止まっている状態になっていた。Full Accessへ切り替えた直後だったので、この挙動はかなり紛らわしかった。

Windows Sandboxをunelevatedへ変更する#

CodexをWindowsネイティブで動かす場合、Windows Sandboxには elevatedunelevated の2つのモードがある。

公式ドキュメントでは elevated が推奨されている。専用の低権限ユーザー、ファイルシステム境界、ファイアウォールルールなどを使う、より強いsandboxになる。

一方の unelevated はフォールバック用で、現在のWindowsユーザーから制限されたトークンを使って動作する。elevated より分離が弱く、ネットワーク分離にも差がある。

今回の環境ではAgent Sandboxのセットアップで止まったため、config.toml に次を追加した。

[windows]
sandbox = "unelevated"

最終的に、今回動作した主要部分は次の設定になった。

approval_policy = "never"
default_permissions = ":danger-full-access"

[windows]
sandbox = "unelevated"

既存のプロジェクト設定がある場合は、この下にそのまま続ける。

[projects.'C:\path\to\project']
trust_level = "trusted"

VS Codeを再起動して新しいチャットから実行すると、メッセージを送れるようになり、止まっていたCodexの作業も進むようになった。

unelevatedは常用推奨という意味ではない#

今回 unelevated で動いたからといって、Windows版Codexでは常にこちらを使う方がよいわけではない。

OpenAIのWindows Sandboxドキュメントでは、両方使える環境なら elevated を使うよう案内されている。unelevated は、UACやローカルユーザー作成、ファイアウォール変更、ログオン権限、企業ポリシーなどの影響で elevated のセットアップが通らない場合に作業を継続するためのフォールバックという位置付けになっている。

今回表示された画面だけでは、どのWindows設定がAgent Sandboxのセットアップを止めていたかまでは断定できない。

公式ドキュメントでは、elevated のセットアップに失敗する代表例として、管理者承認が通らない、ローカルユーザーやグループを作成できない、ファイアウォールルールを変更できない、sandboxユーザーに必要なログオン権限がない、といったケースが挙げられている。

管理されたPCで同じ状態になる場合は、unelevated で作業を継続しつつ、必要ならWindows側のポリシーを確認する方がよい。

Full Accessはアクセス範囲を理解してから使う#

:danger-full-access は、Codexのローカルsandbox制限を外すPermission Profileになる。

今回の目的には合っていたが、単に「確認ダイアログが邪魔」という理由だけで全環境に設定するものではない。Full Accessではプロジェクト外のファイルやネットワークにも広くアクセスできるため、誤ったコマンドによるファイル削除や変更の影響範囲も大きくなる。

プロジェクト内の修正だけで足りる場合は、例えば次のように :workspace を使う選択肢もある。

approval_policy = "never"
default_permissions = ":workspace"

Permission Profileは現在Beta扱いで、仕様は変更される可能性がある。Codex更新後に同じ設定で挙動が変わった場合は、古い設定例をそのまま使うより公式のPermissionsとConfiguration Referenceを確認した方がよい。

また、企業管理環境では requirements.tomlallowed_permission_profileswindows.allowed_sandbox_implementations によって、利用できる権限やWindows Sandboxの種類が制限される場合もある。

実際に確認した権限設定#

今回の流れでは、最初から approval_policy = "never" は入っていた。それでもVS Code側でFull Accessにならなかったため、旧 sandbox_mode を残した構成からPermission Profile方式へ変更した。

approval_policy = "never"
default_permissions = ":danger-full-access"

これでVS Codeの承認方法はFull Accessとして表示されるようになった。

その後、新しいチャット開始時にAgent Sandboxの設定で止まったため、Windows側を次のように変更した。

[windows]
sandbox = "unelevated"

自分の環境では、この状態でCodexを再び動かせるようになった。

同じ「一度だけ許可」が出続ける症状でも、approval_policy、Permission Profile、Windows Sandboxは別の設定として確認した方が切り分けしやすい。

参考#