Codex の "command failed; retry without sandbox"：6 つの直し方（2026 年版）

Codex がコマンド 1 つごとに「retry without sandbox」を尋ねてくる？ 30 秒の診断

Codex を走らせ、ファイルを編集するかコマンドを実行しようとすると、これが出ます。

command failed; retry without sandbox?

次の 3 つのチェックを順に実行してください。最初に変な結果が返ってきたものが、あなたの直し方です。

codex --version              # note the version; 0.115–0.118 had regressions
command -v bwrap             # Linux/WSL2: expect a path; empty = sandbox can't start
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml   # check your settings

本記事は、実行時に起きる実行とサンドボックス/承認のエラー、つまり command failed; retry without sandbox プロンプトと「コマンドごとに承認が要る」ループについてです。インストール直後の codex: command not found が問題なら、それはサンドボックスではなく PATH の問題で、codex: command not found？ npm install 向け 7 つの直し方 を参照してください。この記事が触れる config.toml キーの全リストは、Codex CLI config.toml 徹底解説 がリファレンスです。

このプロンプトの正体（サンドボックス vs 承認）

Codex はモデルのコマンドを 2 つの別々の制御の裏で実行します。人々はこれを混同し、その混乱がこのプロンプトをこれほど厄介にしている原因の半分です。

1 つ目の制御はサンドボックスです。コマンドが触れられるものの技術的な境界、つまりどのファイルに書けるか、ネットワークに到達できるかを設定します。モードは 3 つあり、以下が CLI が受け付ける値の文字列そのものです。

• read-only：Codex はファイルを読み、書き込まないコマンドを実行できる
• workspace-write：Codex は現在のワークスペース内で読み書きし、ルーティンなローカルコマンドを実行できる（インタラクティブのデフォルト）
• danger-full-access：ファイルシステムやネットワークの制限なし

2 つ目の制御は承認ポリシーです。Codex が境界を越える前にいつ止まってあなたに尋ねるかを決めます。受け付ける値はこちら。

• untrusted：何かを実行する前に確認する
• on-request：モデルはルーティンな作業を自分で実行し、境界の外に出る必要があるときだけ尋ねる（インタラクティブのデフォルト）
• never：決して尋ねない。許可されていないものは単に失敗する

公式の Codex サンドボックスドキュメント はこの関係をはっきり述べています。サンドボックスが技術的な境界を定義し、承認ポリシーが Codex がそれを越える前に止まって尋ねるべきタイミングを決める。2 つは連携して働きます。

では command failed; retry without sandbox? はどこから来るのか。コマンドが実行され、サンドボックス層が原因で非ゼロ終了し、承認ポリシーが反応して、あなたが yes と言えば同じコマンドをサンドボックスの外で再実行すると申し出ている、というわけです。文言は「あなたのコードにもっと権限が必要」を匂わせますが、実際にはコマンドは問題なかったケースが非常に多いのです。サンドボックス自体が起動に失敗したか、リグレッションが通常の編集を拒否と誤ラベルしたのです。

model wants to run a command
        │
        ▼
  sandbox_mode applies the boundary  ──► command runs clean ──► done
        │
        ▼ (command exits non-zero under the sandbox)
  approval_policy reacts
        │
        ▼
  "command failed; retry without sandbox?"  ──► you approve ──► reruns unsandboxed

この区別を頭に置いてください。以下の直し方はほぼすべて、「サンドボックスが仕事をできるようにする」か「承認ポリシーにルーティン作業の邪魔をやめさせる」のどちらかです。

いつ直すか、いつバージョンを変えるか、いつ単に承認するか

何かを変える前に、自分がどのバケツにいるかを決めましょう。これで、そもそも問題でなかった config を書き直す手間が省けます。

config を直すのは、bwrap が見つからないとき、あるいは approval_policy/sandbox_mode が望むより厳しく設定されているときです。これが大半のケースで、記事の残りがそれをカバーします。

バージョンを変えるのは、既知のリグレッションを含むリリースにいて、クリーンな config と bubblewrap でも通常の編集でプロンプトが出るときです。2026 年のいくつかのビルドに apply_patch リグレッションが入りました。良いものに固定するか、それを越えるバージョンへ上げてください。

単に承認して先へ進むのは、プロンプトが稀にしか出ず、本当にネットワークに到達するかプロジェクト外に書き込むコマンドのときだけです。それはサンドボックスが仕事をしているのです。一度承認するほうが、一度きりのために構成を作り直すより速いです。

中止ルール：本物のネットワーク/ワークスペース外コマンドで 1 時間に 1〜2 回しかプロンプトを見ないなら、それはバグではありません。承認して作業を続けてください。以下の直し方は「コマンド 1 つごと」のケース向けです。

Codex のサンドボックスと承認のエラー：それぞれの意味

Linux で単独で最もよくある根本原因は最初の行です。Codex ドキュメントは、Linux と WSL2 ではまず bubblewrap を入れると明言しています。Codex は PATH 上で最初に見つかった bwrap を使い、見つからなければ非特権ユーザー名前空間を必要とする同梱ヘルパーにフォールバックします。どちらも使えないと、Codex は起動時の警告を出し、それ以降はサンドボックス化したコマンドがすべて retry プロンプトへ失敗します。これがまさに issue #19162 で報告された挙動で、バージョン 0.115.0 前後からすべてのファイル編集が失敗し、メンテナの最初の質問はサンドボックスの前提どおり bubblewrap が入っているかでした。

どの仕組みがサンドボックスを強制するかは完全にプラットフォーム依存で、それによってそもそも何かをインストールする必要があるかが決まります。

macOS か Windows PowerShell にいてそれでもコマンドごとにプロンプトが出るなら、原因がサンドボックスの仕組み自体であることはほぼありません。Fix 2（承認ポリシー）か Fix 5（バージョンリグレッション）へ飛んでください。「何かをインストールする」系の直し方は Linux と WSL2 の話です。

直し方（あらゆる構成向けの解決策）

Fix 1（Linux/WSL2）：bubblewrap を入れる

これは Linux での「コマンドごとに承認が要る」ケースの直し方です。workspace-write サンドボックスは境界の強制に bwrap を必要とします。なければコマンドはサンドボックス化して実行できず、失敗してエスカレートします。

# Debian / Ubuntu / WSL2 (Ubuntu)
sudo apt-get update && sudo apt-get install -y bubblewrap

# Fedora
sudo dnf install -y bubblewrap

# Arch
sudo pacman -S bubblewrap

command -v bwrap   # expect /usr/bin/bwrap

インストール後に Codex を再起動してください。起動時の警告は消え、編集でプロンプトが出なくなるはずです。bwrap が入っているのにプロンプトが続くなら、カーネルで非特権ユーザー名前空間が無効になっているか、AppArmor プロファイルが bubblewrap をブロックしている可能性があります。確認してください。

cat /proc/sys/kernel/unprivileged_userns_clone   # expect 1 (or the file absent on newer kernels)

Ubuntu 25.10 では特に（issue #17134）、ユーザーが bwrap まわりの AppArmor 制限に当たりました。最近の Ubuntu リリースは非特権ユーザー名前空間を制限する AppArmor ポリシーを同梱しており、それこそ同梱ヘルパーが依存しているものです。ハード化したカーネルにいるなら、bubblewrap 用に該当する AppArmor プロファイルを許可する必要があるかもしれません。通常のデスクトップ Ubuntu では上記の apt-get install で十分です。システムの bwrap は自身のプロファイルで許可されているからです。優先順位はこうです。まずシステムの bwrap パッケージを入れ（動作するプロファイルを持っています）、パッケージはあるのに名前空間の生成がまだ失敗する場合にだけ AppArmor 設定に触れてください。

macOS ユーザーはこの直し方を丸ごとスキップします。macOS は組み込みの Seatbelt フレームワークを使うので、追加インストールなしでサンドボックスが動きます。macOS の実行でコマンドごとにプロンプトが出るなら、それは config かバージョンの問題で、サンドボックスバイナリの欠落ではありません。

Fix 2：approval_policy を on-request にする

Codex がすべてのコマンドの前に尋ね、かつ bwrap がある場合、承認ポリシーが厳しすぎます。untrusted の値は「何かを実行する前に確認する」を意味し、これが正しいのは各ステップを精査したいときだけです。

~/.codex/config.toml を編集します。

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

on-request では、Codex はルーティンな読み取り、編集、ローカルコマンドを自分で実行し、ワークスペースの外に出る必要があるかネットワークに到達する必要があるときだけ尋ねます。ファイルに触れず、実行ごとに設定することもできます。

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

短い形は --ask-for-approval が -a、--sandbox が -s で、どちらも Codex CLI コマンドラインリファレンス に記載があります。

Fix 3：read-only から離れて編集を許す

sandbox_mode = "read-only" だと Codex はまったく書き込めないので、試みた編集はどれも拒否されるか retry プロンプトへエスカレートします。通常のコーディング作業には workspace-write が欲しいところです。

sandbox_mode = "workspace-write"

read-only は、何も変えずに Codex にリポジトリを分析させたいときに有用です。コードの編集を頼んだ瞬間には間違ったモードで、retry プロンプトはその症状です。

Fix 4：サンドボックスを落とさずにネットワークを許す

npm install や git fetch が失敗したからといって、いきなり danger-full-access に飛ぶのはよくある過剰反応です。その必要はありません。workspace-write サンドボックスはデフォルトで外向き通信をブロックしますが、サンドボックス内でそれをオンにできます。

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

これでファイルシステムの境界を保ったまま、パッケージのインストールやフェッチを通せます。danger-full-access に手を伸ばすのは、無制限のファイルシステムとネットワークの両方が本当に必要なときだけにし、できればそれをコンテナ内で行ってください。

Fix 5：apply_patch リグレッションを越えて pin する

bubblewrap が入っていて、config がクリーンで、それでも通常の編集がまだプロンプトを出すなら、おそらくリグレッションを含むビルドにいます。報告はこちら。

Issue #16407 はリグレッションをバージョン 0.118.0 に特定しました。そこでは apply_patch が retry プロンプトを伴うパッチ承認ループに入り、0.117.0 は問題なく動きました。Issue #19162 は 0.115.0 前後から始まり、ほぼすべてのファイル編集に影響したと報告しています。Issue #18079 はプロンプトを誤解を招くと表現しました。bubblewrap とファイルシステムへの書き込みは動いていたのに、apply_patch がなお retry without sandbox を尋ねた、と。

悪いバージョンで詰まっているなら、既知の良いものに固定するか、修正済みのリリースへ前進してください。

# pin to a specific version
npm install -g @openai/codex@0.117.0

# or upgrade to latest and re-test
npm install -g @openai/codex@latest
codex --version

バージョンを変えたら些細な編集でテストしてください。クリーンなバージョンと bubblewrap で解消するなら、原因は config ではなくリグレッションでした。

Fix 6（macOS / クロスプラットフォーム）：writable roots を広げる

macOS ではサンドボックスはたいてい初めから動くので、プロンプトを見たときはしばしば本物の境界ヒットです。コマンドがワークスペースの外に書き込もうとしたのです。よくあるケースは、ビルドツールがホームフォルダのキャッシュディレクトリに書き込む、またはモノレポのタスクが開いたディレクトリの外にある兄弟パッケージに触れる、というものです。

サンドボックスを無効化する代わりに、パスを writable_roots に追加します。

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["/Users/you/.cache/mytool"]

[sandbox_workspace_write] テーブルは、/tmp と $TMPDIR の扱いを締めたい場合に備えて、config リファレンスどおり exclude_slash_tmp と exclude_tmpdir_env_var もサポートしています。

—full-auto と —yolo についての注意

フォーラムの回答で 2 つのフラグが絶えず出てきますが、片方は今や罠です。

--full-auto は非推奨の互換フラグです。CLI リファレンスはこれを deprecated と記述し、--sandbox workspace-write を推奨するよう述べています。使うと Codex が警告を出します。古いブログ記事が「とにかく codex --full-auto を走らせろ」と言っているなら、その習慣を --sandbox workspace-write --ask-for-approval on-request に更新してください。これは両方の制御を明示します。

--dangerously-bypass-approvals-and-sandbox（エイリアス --yolo）は両方の制御を一度に取り除きます。使い捨てでネットワーク隔離されたコンテナか VM の中だけが正しい使い道です。なぜなら Codex はあなたのフル権限で任意のコマンドを実行できるからです。大切にしているマシンでの無人実行には、より安全な組み合わせがこちらです。

codex --sandbox workspace-write --ask-for-approval never

これはファイルシステムの境界を保ちつつ承認で止まらないので、--yolo に手を伸ばすとき人々が実際に欲しいのはたいていこれです。

2026 年の Codex サンドボックス問題：実際の報告

これらはこのプロンプトの背後にある公開 issue で、バージョンとステータス付きです。執筆時点ですべて CLOSED で、つまり修正や回避策が着地したという意味ですが、バージョン番号はどのビルドを避けるべきかを教えてくれます。

パターンは明白です。おおよそ 0.115 から 0.118 の間に、apply_patch 経路がプロンプトを過剰トリガーするリグレッションのまとまりがあり、それが定番の Linux 原因（bubblewrap 未インストール）の上に重なっています。1 つだけ読むなら、#19162 が「すべてのコマンド」報告の正典で、メンテナの返答はまっすぐサンドボックスの前提を指しています。

サンドボックスが健全か確かめる方法

直し方を当てたら、推測ではなく検証してください。手早いループ。

codex --version                         # off the regression range
command -v bwrap                        # Linux: resolves to a path
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml

それから Codex を起動し、サンドボックスの起動警告がないか見てください。警告がなく、些細な編集がプロンプトなしで適用されれば、境界は機能しています。Codex 自身の環境ビューを表に出したいなら、最近のビルドには codex doctor 風の診断が同梱されています。codex --help を走らせてあなたのバージョンが公開しているサブコマンドを確認してください。これらはリリースごとに変わります。

動く構成ができたら役立つパターン：それを名前付きプロファイルとして取り込み、フラグを打ち直さずに済むようにします。config リファレンスによると、プロファイルファイルは config.toml の隣に $CODEX_HOME/profile-name.config.toml として置かれ、--profile profile-name で選びます。config.toml には厳しいデフォルトを置き、すでに信頼しているリポジトリ用に緩めのプロファイルファイルを保ってください。

# ~/.codex/trusted.config.toml
approval_policy = "never"
sandbox_mode   = "workspace-write"

codex --profile trusted で起動します。これで日常の実行は安全に保ちつつ、信頼するリポジトリには --yolo に手を伸ばさずワンフラグの脱出口を持てます。

サンドボックスが間違ったレイヤーのとき：不安定なモデルステップを迂回する

retry-without-sandbox のケースの大半はローカルです。bubblewrap、config、あるいはバージョンリグレッション。でも時には、根底のコマンドは問題なく、モデルがループの遅い/失敗する部分で、同じ Codex ワークフローの裏により速いか安いバックエンドが欲しいことがあります。

Codex CLI は任意の OpenAI 互換 endpoint と話します。だから環境変数 1 つだけで ofox に対して動きます。Codex を ofox の base URL とキーに向け、サンドボックスと承認の設定を上のとおりそのまま保ち、好きなモデルにルーティングします。

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="your-ofox-key"
# then run Codex normally; sandbox/approval config is unchanged
codex --sandbox workspace-write --ask-for-approval on-request

これはサンドボックスのプロンプトについて何も変えません。それはローカルの制御です。ただループの裏のバックエンドがあなたの選択になるだけです。ofox は https://api.ofox.ai/v1 で OpenAI 互換 API を公開し、OpenAI モデル（GPT-5.4 系と GPT-5.3 Codex）を他のモデルと並べて掲載しているので、Codex のローカルな安全制御を保ったままモデルを独立に差し替えられます。プロバイダの完全な設定は、Codex CLI API 設定ガイド が base URL、キー、モデル選択を一通り案内します。

別の実行モデルが欲しいときの代替

サンドボックスモデル自体があなたのワークフローに合わないなら、現実的な選択肢はこちらです。

• ofox バックエンドの Codex。 Codex のサンドボックスと承認の制御を保ち、OpenAI 互換 base URL を https://api.ofox.ai/v1 に向け、モデルを選ぶ。Codex の UX は好きだがバックエンドの柔軟性が欲しいときに最適。設定は環境変数 1 つ。
• --sandbox workspace-write --ask-for-approval never。 同じ Codex、プロンプトなし、ファイルシステムの境界はそのまま。信頼するマシンでの無人ローカル実行に最適。
• 使い捨てコンテナ + --yolo。 隔離した VM かコンテナ内での完全バイパス。ホスト上で害を被るものが何もない使い捨て環境に最適。
• 他の agentic CLI。 Claude Code と Cursor は独自の権限モデルを持ちます。Codex のサンドボックスと絶えず戦うなら、別のツールのデフォルトのほうが合うかもしれません。Claude Code vs Codex CLI vs Cursor で比較してください。

ほとんどの人にとって正直なデフォルトは最初か 2 つ目の選択肢です。サンドボックスを保ち、根本原因を直し、意図したときだけ制御を緩めてください。

FAQ

冒頭の質問は、このプロンプトをめぐる最もよくある検索を反映しています。完全なセットはこのページの FAQ スキーマにあります。短い版はこうです。Linux では bubblewrap を入れる。どこでも approval_policy = "on-request" と sandbox_mode = "workspace-write" を設定する。両方が正しいなら、0.115–0.118 の範囲のバージョンリグレッションを疑い、既知の良いビルドに固定する。

今回の更新で確認したソース

• Codex 設定リファレンス、approval_policy、sandbox_mode、[sandbox_workspace_write] のキーと値（2026-06-29 確認）：https://developers.openai.com/codex/config-reference
• Codex サンドボックスのコンセプト、macOS の Seatbelt、Linux/WSL2 の bubblewrap、ネイティブの Windows サンドボックス、PATH 上の最初の bwrap と同梱ヘルパーのフォールバック（2026-06-29 確認）：https://developers.openai.com/codex/concepts/sandboxing
• Codex CLI コマンドラインリファレンス、--ask-for-approval（-a）、--sandbox（-s）、--full-auto（非推奨）、--dangerously-bypass-approvals-and-sandbox / --yolo（2026-06-29 確認）：https://developers.openai.com/codex/cli/reference
• GitHub issue #19162、すべてのコマンドで “retry without sandbox”、0.115.0+（2026-06-29 確認）：https://github.com/openai/codex/issues/19162
• GitHub issue #16407、0.118.0 の apply_patch リグレッション、0.117.0 は動く（2026-06-29 確認）：https://github.com/openai/codex/issues/16407
• GitHub issue #18079、bwrap と書き込みが動いても誤解を招くプロンプト（2026-06-29 確認）：https://github.com/openai/codex/issues/18079
• ofox API カタログ、OpenAI 互換 base URL https://api.ofox.ai/v1、GPT-5.4 系と GPT-5.3 Codex を掲載（2026-06-29 確認）：https://ofox.io/docs