Windows版Codex CLIで確認が多い理由
（サンドボックスと承認ポリシー）

by

WindowsでCodex CLIを使い始めると、Get-Contentのようなファイルを読み取るだけのコマンドでも毎回確認が出ることがあります。
Linux版では気にならなかったのに、PowerShellだと異常に多いと感じている方は少なくないはずです。

<svg class="eyecatch-svg" viewBox="0 0 192 192" xmlns="http://www.w3.org/2000/svg"> <!-- 背景 --> <rect width="192" height="192" rx="32" ry="32" fill="white"/> <!-- ターミナルウィンドウ本体 --> <rect x="12" y="18" width="162" height="116" rx="10" ry="10" fill="#263238"/> <!-- タイトルバー（上部、角丸あり） --> <rect x="12" y="18" width="162" height="28" rx="10" ry="10" fill="#37474F"/> <!-- タイトルバー下部の角丸を塗りつぶし --> <rect x="12" y="36" width="162" height="10" fill="#37474F"/> <!-- ウィンドウコントロールドット --> <circle cx="32" cy="32" r="5" fill="#EF5350"/> <circle cx="48" cy="32" r="5" fill="#FFC107"/> <circle cx="64" cy="32" r="5" fill="#4CAF50"/> <!-- ターミナルコンテンツ --> <!-- プロンプト記号 --> <rect x="26" y="58" width="8" height="6" rx="2" fill="#4CAF50"/> <!-- コマンドテキスト --> <rect x="40" y="58" width="68" height="6" rx="2" fill="#90A4AE"/> <!-- 出力行1 --> <rect x="26" y="74" width="86" height="5" rx="2" fill="#546E7A"/> <!-- 出力行2 --> <rect x="26" y="87" width="66" height="5" rx="2" fill="#546E7A"/> <!-- 承認バッジ（右下オーバーレイ） --> <!-- 白リング（ターミナルとの境界） --> <circle cx="144" cy="112" r="32" fill="white"/> <!-- ブルーバッジ本体 --> <circle cx="144" cy="112" r="26" fill="#1565C0"/> <!-- チェックマーク --> <path d="M133,112 L141,120 L157,103" stroke="white" stroke-width="5.5" stroke-linecap="round" stroke-linejoin="round" fill="none"/> </svg>Windows版Codex CLIで確認が多い理由<br class="chiilabo-br is-on">（サンドボックスと承認ポリシー）

この差がなぜ起きるのか、設定で変えられるのかを整理します。

関連記事

1. 承認の基準は「危険かどうか」ではない

1. 承認の基準は「危険かどうか」ではない

Codex CLIの承認確認は「このコマンドが危険そうかどうか」で決まっているわけではありません。

Codex CLIは、AIモデルが生成したシェルコマンドをローカルで実行するコーディングエージェントです1。
単なるチャットと違い、実際にファイル操作やコマンド実行を行います。
実行できる範囲をOS側で制限する仕組みである「サンドボックス（sandbox）」を使って操作を閉じ込めています。

承認確認が発生するのは、サンドボックスの境界を越えるかどうかが基準になります。
境界内ならそのまま実行し、境界外に出る必要があれば確認する、という設計です2。

「読み取りだから安全」「削除だから危険」という人間的な判断軸とは、ズレがあります。

1.1. WindowsとLinux、WSL2でサンドボックス実装が違う

1.1. WindowsとLinux、WSL2でサンドボックス実装が違う

Codex CLIの公式ドキュメントでは、PowerShell上で動かす場合はWindowsネイティブのサンドボックスを、WSL2上で動かす場合はLinux側のサンドボックスを使うと説明されています。

Linuxのサンドボックスは、ファイルシステムの名前空間やcgroupsなどのカーネル機能で境界を定めやすい仕組みになっています3。
Codex CLIもこれを前提に設計されているため、「ワークスペース内の読み取りです」という判断をきちんと下せます。

Windows側はそうはいきません。
ドライブ構造、ユーザーフォルダ、OneDrive連携、企業ポリシーに加え、ファイルやフォルダごとのアクセス権リストであるACLも絡んでくるため、Codex側から見ると「本当にワークスペース内の安全な操作か」を保証しにくい要素が多くあります。
保証できない場合、安全側に倒して確認が増えます4。

これが、LinuxやWSL2では通っていた操作がWindows PowerShellでは止まる理由です5。

2. Get-Contentが確認対象になる理由

2. Get-Contentが確認対象になる理由

Get-Content .\README.md は読み取り専用のコマンドですが、Codex CLIから見ると「AIが生成したPowerShellコマンドを実行する」操作です。

PowerShellは強力な実行環境で、同じ経路からRemove-Item、Set-Content、Invoke-WebRequest、スクリプトの実行まで扱えます。
Codex CLIはPowerShellというシェルに対してコマンドを渡しているため、コマンド単体の性質だけで安全性を判断しきれません。

Get-Contentが読み取るファイルによっては.env、SSHキー、APIトークンといった機密情報に触れる可能性もあります。
Codexの安全設計は「読み取りは常に安全」とは扱いません。
サンドボックスによってワークスペース内の操作だと保証できるかどうかが、実際の判断軸になります6。

3. 設定で変えられる

3. 設定で変えられる

承認の頻度は設定で調整できます。
試す価値があるのは次のコマンドです。

codex --sandbox workspace-write --ask-for-approval on-request

workspace-writeは、Codexの作業対象ディレクトリ内での読み取り・書き込み・コマンド実行を許可するサンドボックスモードです。
on-requestは、必要なときだけ承認を求めるポリシーを指します。
ワークスペース内の操作はそのまま流れ、外部ネットワークやワークスペース外のパスへのアクセスで確認が入ります7。

3. 設定で変えられる

毎回この設定で動かしたい場合は~/.codex/config.tomlに書きます8。

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = falseCode language: TOML, also INI (ini)

別のディレクトリも作業対象に加えたいときだけ、writable_rootsを追記します。

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false
writable_roots = ['C:\path\to\other\repo']Code language: TOML, also INI (ini)

3.1. 「破壊的な変更だけ承認」に近づけるには

3.1. 「破壊的な変更だけ承認」に近づけるには

「読み取りは自動、削除だけ確認」という粒度の設定は、Codex CLIの基本設計にはありません。
基準はコマンドの破壊性ではなくサンドボックス境界だからです。

ただし、Rulesという仕組みを使えばある程度近づけられます。
Rulesは特定のコマンドに対してallow、prompt、forbiddenを指定できる実行ポリシー規則で、~/.codex/rules/default.rulesに置きます9。

prefix_rule(
    pattern = ["Remove-Item"],
    decision = "prompt",
    justification = "削除操作は確認してから実行する",
)
prefix_rule(
    pattern = ["del"],
    decision = "prompt",
    justification = "削除操作は確認してから実行する",
)
prefix_rule(
    pattern = ["rm"],
    decision = "prompt",
    justification = "削除操作は確認してから実行する",
)Code language: JavaScript (javascript)

workspace-write + on-requestでワークスペース内の操作を通しつつ、削除系のコマンドだけRulesで止めるのが現実的な運用になります。

4. WindowsネイティブにこだわらないならWSL2が安定する

4. WindowsネイティブにこだわらないならWSL2が安定する

Windows PowerShell上でどうしても確認が多い場合は、WSL2上にリポジトリを置いてCodex CLIを使う選択肢があります。
~/code/以下などLinux側のファイルシステムに置くと、CodexはLinuxサンドボックスの挙動を使えるため、Linux版と近い感覚で動きます10。

公式ドキュメントでもWSL2ではLinuxサンドボックスを使えると明記されており、Windowsネイティブ特有の摩擦を避けたいなら有効な回避策です11。

Codex CLIの承認の多さは「このツールがうるさい」のではなく、WindowsとLinuxのサンドボックス実装の差から来ています。
設定で解消できる部分は多いので、まずworkspace-write + on-requestを試してみてください。

  1. OpenAIが2025年4月にオープンソースで公開しました。もとはTypeScript実装でしたが、のちにRust実装（codex-rs）へ移行し、2026年時点ではコードベースの95%以上がRustで書かれています – GitHub: openai/codex
  2. 公式のSandboxドキュメントには「サンドボックスは技術的な境界を定義し、承認ポリシーはその境界を越える前にCodexが停止して確認が必要なタイミングを決定する。この2つは異なる制御として連携して機能する」と説明されています – Sandbox – Codex | OpenAI Developers
  3. 正確には、bubblewrap（bwrap）によるユーザー名前空間の分離、Landlock LSMによるファイルシステムアクセス制限、seccomp-BPFによるシステムコールフィルタリングの3つを組み合わせています。cgroupsはメモリ・CPUリソース管理に使われますが、Codexのサンドボックス境界の主役はこの3つの組み合わせです – Agent approvals & security – Codex | OpenAI Developers
  4. OpenAIはWindowsサンドボックスの実装にあたり、AppContainer・Windows Sandbox・Mandatory Integrity Controlを候補として検討しましたが、「任意の開発ツールをエージェントが使う」というCodexの用途にいずれも合わなかったとして、制限付きトークン（restricted token）とACLを組み合わせた独自方式を設計しました。詳細は2026年5月公開のエンジニアリングブログに記されています – Building a safe, effective sandbox to enable Codex on Windows | OpenAI
  5. WindowsへのネイティブPowerShellサポートとWindowsネイティブサンドボックスが追加されたのは2026年3月のことで、それ以前はWSL2経由での利用が主流でした – Codex (AI agent) – Wikipedia
  6. バージョン管理されていないフォルダでCodexを起動した場合、デフォルトのサンドボックスモードがworkspace-writeではなくread-onlyに切り替わる設計になっています – Agent approvals & security – Codex | OpenAI Developers
  7. 公式ドキュメントではこの組み合わせをAutoプリセットと呼んでいます。バージョン管理されているフォルダでcodexを起動すると、Codexが自動的にAutoプリセットを推奨する仕組みになっています – Agent approvals & security – Codex | OpenAI Developers
  8. Windows環境ではさらに[windows]セクションでsandbox = “elevated”を指定すると、専用サンドボックスユーザーとWindowsファイアウォール規則を使った、より堅牢なelevatedサンドボックスが有効になります。初回起動時に管理者権限でのセットアップが必要ですが、以降は通常権限で動作します – Config basics – Codex | OpenAI Developers
  9. Rulesファイルの構文にはStarlarkというPythonに似た設計の安全な組み込みスクリプト言語を使います。codex execpolicy check –rules ~/.codex/rules/default.rules — コマンド名でルールが意図どおりに適用されるか事前にテストできます – Rules – Codex | OpenAI Developers
  10. /mnt/c/以下のWindowsファイルシステム上で作業するとクロスファイルシステムのI/Oオーバーヘッドも発生します。WSL2でCodexを使う場合はLinux側にリポジトリを置くのが推奨されています – How To Install Codex CLI on Windows (2026 Guide) | ITECS
  11. WSL1はCodex CLIバージョン0.114まで対応していましたが、0.115からLinuxサンドボックスがbubblewrapに移行したため、現在はWSL1がサポート外になっています – Agent approvals & security – Codex | OpenAI Developers