Codex "command failed; retry without sandbox": 6 Fixes (2026)

Codex Asking to “Retry Without Sandbox” on Every Command? The 30-Second Diagnosis

You run Codex, it tries to edit a file or run a command, and you get this:

command failed; retry without sandbox?

Run these three checks in order. The first one that comes back wrong is your fix.

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

This article is about execution and sandbox/approval errors at runtime: the command failed; retry without sandbox prompt and the “every command needs approval” loop. If your problem is codex: command not found right after install, that is a PATH problem, not a sandbox problem; see codex: command not found? 7 fixes for npm install. For the full list of config.toml keys this post touches, the Codex CLI config.toml deep dive is the reference.

What This Prompt Actually Is (Sandbox vs Approval)

Codex runs your model’s commands behind two separate controls. People mix them up, and that confusion is half the reason this prompt is so annoying.

The first control is the sandbox. It sets the technical boundary for what a command can touch: which files it can write, whether it can reach the network. There are three modes, and these are the exact value strings the CLI accepts:

• read-only: Codex can read files and run commands that do not write
• workspace-write: Codex can read and edit inside the current workspace and run routine local commands (this is the interactive default)
• danger-full-access: no filesystem or network restriction

The second control is the approval policy. It decides when Codex stops and asks you before crossing the sandbox boundary. The accepted values:

• untrusted: ask before running anything
• on-request: the model runs routine work itself and asks only when it needs to step outside the boundary (interactive default)
• never: never ask; if something is not allowed, it just fails

The official Codex sandboxing docs state the relationship directly: the sandbox defines the technical boundaries, and the approval policy decides when Codex must stop and ask before crossing them. The two work together.

So where does command failed; retry without sandbox? come from? A command ran, the sandbox layer caused it to exit non-zero, and the approval policy reacted by offering to run the same command again outside the sandbox once you say yes. The wording suggests “your code needs more permission,” but very often the command would have been fine. The sandbox itself failed to start, or a regression mislabeled a normal edit as a denial.

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

Keep that split in mind. Almost every fix below is either “make the sandbox able to do its job” or “tell the approval policy to stop interrupting routine work.”

When to Fix This, When to Switch Versions, and When to Just Approve

Before you change anything, decide which bucket you are in. This saves you from rewriting a config that was never the problem.

Fix the config if bwrap is missing, or your approval_policy/sandbox_mode are set to something stricter than you want. This is the majority of cases and the rest of the article covers it.

Switch versions if you are on a release with a known regression and a clean config plus bubblewrap still triggers the prompt on ordinary edits. Several 2026 builds shipped apply_patch regressions; pin to a good one or upgrade past it.

Just approve and move on if the prompt only shows up rarely, on a command that genuinely reaches the network or writes outside your project. That is the sandbox doing its job. Approving once is faster than re-architecting your setup for a one-off.

Stop rule: if you only see the prompt once or twice an hour on real network/out-of-workspace commands, you do not have a bug. Approve it and keep working. The fixes below are for the “every single command” case.

Codex Sandbox and Approval Errors: What Each One Means

The single most common root cause on Linux is the first row. The Codex docs are explicit that on Linux and WSL2 you install bubblewrap first; Codex uses the first bwrap it finds on PATH and falls back to a bundled helper that needs unprivileged user namespaces. If neither is available, Codex prints a startup warning, and from then on every sandboxed command fails into the retry prompt. That is exactly the behavior reported in issue #19162, where every file edit failed starting around version 0.115.0, and a maintainer’s first question was whether bubblewrap was installed per the sandboxing prerequisites.

Which mechanism enforces the sandbox depends entirely on your platform, and that decides whether you have anything to install at all:

If you are on macOS or Windows PowerShell and still get the prompt on every command, the cause is almost never the sandbox mechanism itself; jump to Fix 2 (approval policy) or Fix 5 (version regression). The “install something” fixes are a Linux and WSL2 story.

How to Fix It (Solutions for Every Setup)

Fix 1 (Linux/WSL2): Install bubblewrap

This is the fix for the “every command needs approval” case on Linux. The workspace-write sandbox needs bwrap to enforce its boundary. Without it, commands cannot run sandboxed, so they fail and escalate.

# 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

Restart Codex after installing. The startup warning should disappear and edits should stop prompting. If bwrap is installed but the prompt persists, your kernel may have unprivileged user namespaces disabled, or an AppArmor profile is blocking bubblewrap. Check:

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

On Ubuntu 25.10 specifically (issue #17134), users hit AppArmor restrictions around bwrap. Recent Ubuntu releases ship an AppArmor policy that restricts unprivileged user namespaces, which is exactly what the bundled helper relies on. If you are on a hardened kernel, you may need to allow the relevant AppArmor profile for bubblewrap; on a normal desktop Ubuntu the apt-get install above is enough, because the system bwrap is allowed by its own profile. The order of preference is: install the system bwrap package first (it carries a working profile), and only touch AppArmor settings if the package is present but namespace creation still fails.

macOS users skip this fix entirely. macOS uses the built-in Seatbelt framework, so the sandbox works without any extra install. If a macOS run prompts on every command, you are looking at a config or version issue, not a missing sandbox binary.

Fix 2: Set approval_policy to on-request

If Codex asks before every command and bwrap is present, your approval policy is too strict. The value untrusted means “ask before running anything,” which is correct only if you want to vet each step.

Edit ~/.codex/config.toml:

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

With on-request, Codex runs routine reads, edits, and local commands itself and asks only when it needs to step outside the workspace or reach the network. You can also set it per-run without touching the file:

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

The short forms are -a for --ask-for-approval and -s for --sandbox, both documented in the Codex CLI command-line reference.

Fix 3: Move off read-only so edits are allowed

If sandbox_mode = "read-only", Codex cannot write at all, so any edit it tries either gets refused or escalates into the retry prompt. For normal coding work you want workspace-write:

sandbox_mode = "workspace-write"

read-only is useful when you want Codex to analyze a repo without changing anything. It is the wrong mode the moment you ask it to edit code, and the retry prompt is the symptom.

Fix 4: Allow network without dropping the sandbox

A frequent overreaction is jumping straight to danger-full-access because npm install or git fetch failed. You do not need to. The workspace-write sandbox blocks outbound network by default, but you can turn it on inside the sandbox:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

That keeps the filesystem boundary intact while letting package installs and fetches through. Reach for danger-full-access only when you genuinely need both unrestricted filesystem and network, and prefer to do that inside a container.

Fix 5: Pin past the apply_patch regression

If bubblewrap is installed, your config is clean, and ordinary edits still prompt, you are probably on a build with the regression. The reports:

Issue #16407 pinned a regression to version 0.118.0, where apply_patch entered a patch-approval loop with the retry prompt, while 0.117.0 worked. Issue #19162 reported the behavior starting around 0.115.0, affecting nearly every file edit. Issue #18079 described the prompt as misleading: bubblewrap and filesystem writes worked, yet apply_patch still asked to retry without sandbox.

If you are stuck on a bad version, pin to a known-good one or move forward to a fixed release:

# 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

Test with a trivial edit after changing versions. If a clean version plus bubblewrap clears it, the regression was the cause, not your config.

Fix 6 (macOS / cross-platform): Widen writable roots

On macOS the sandbox usually works out of the box, so when you do see the prompt it is often a real boundary hit: the command tried to write outside your workspace. Common cases are a build tool writing to a cache directory in your home folder, or a monorepo task touching a sibling package outside the opened directory.

Add the path to writable_roots instead of disabling the sandbox:

sandbox_mode = "workspace-write"

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

The [sandbox_workspace_write] table also supports exclude_slash_tmp and exclude_tmpdir_env_var if you need to tighten /tmp and $TMPDIR handling, per the config reference.

A Note on —full-auto and —yolo

Two flags come up constantly in forum answers, and one of them is now a trap.

--full-auto is a deprecated compatibility flag. The CLI reference describes it as deprecated and says to prefer --sandbox workspace-write; Codex prints a warning when you use it. If an old blog post tells you to “just run codex --full-auto,” update that habit to --sandbox workspace-write --ask-for-approval on-request, which is explicit about both controls.

--dangerously-bypass-approvals-and-sandbox (alias --yolo) removes both controls at once. It is the right tool only inside a disposable, network-isolated container or VM, because Codex can then run any command with your full permissions. For unattended runs on a machine you care about, the safer combination is:

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

That keeps the filesystem boundary while not pausing for approvals, which is usually what people actually want when they reach for --yolo.

Codex Sandbox Issues in 2026: Real Reports

These are the public issues behind the prompt, with their versions and status. All were CLOSED at the time of writing, which means fixes or workarounds landed, but the version numbers tell you which builds to avoid.

The pattern is clear: a cluster of regressions between roughly 0.115 and 0.118 where the apply_patch path over-triggered the prompt, layered on top of the evergreen Linux cause (bubblewrap not installed). If you read only one, #19162 is the canonical “every command” report, and the maintainer response points straight at the sandboxing prerequisites.

How to Confirm Your Sandbox Is Healthy

After applying a fix, verify instead of guessing. A quick loop:

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

Then start Codex and watch for a sandbox startup warning. No warning plus a trivial edit that applies without a prompt means the boundary is working. If you want Codex to surface its own view of the environment, the CLI ships a codex doctor-style diagnostic in recent builds; run codex --help to see the subcommands your version exposes, since these change between releases.

A practical pattern once you have a setup that works: capture it as a named profile so you are not re-typing flags. The config reference says profile files live next to config.toml as $CODEX_HOME/profile-name.config.toml and you select one with --profile profile-name. Keep a strict default in config.toml and a looser profile file for repos you already trust:

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

Launch it with codex --profile trusted. This keeps your everyday runs safe while giving you a one-flag escape hatch for trusted repos, without ever reaching for --yolo.

When the Sandbox Is the Wrong Layer: Routing Around a Flaky Model Step

Most retry-without-sandbox cases are local: bubblewrap, config, or a version regression. But sometimes the underlying command is fine and the model is the slow or failing part of the loop, and you want a faster or cheaper backend behind the same Codex workflow.

Codex CLI talks to any OpenAI-compatible endpoint, which is why it works against ofox with nothing more than an environment variable. You point Codex at the ofox base URL and key, keep your sandbox and approval settings exactly as above, and route to whichever model you want:

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

This does not change anything about the sandbox prompt; that is a local control. It just means the backend behind the loop is your choice. ofox exposes an OpenAI-compatible API at https://api.ofox.ai/v1 and lists OpenAI models (the GPT-5.4 family and GPT-5.3 Codex) alongside others, so you can keep Codex’s local safety controls and swap the model independently. For the full provider setup, the Codex CLI API configuration guide walks through base URL, key, and model selection.

Alternatives When You Want a Different Execution Model

If the sandbox model itself is not the fit for your workflow, these are the realistic options:

• ofox-backed Codex. Keep Codex’s sandbox and approval controls, point the OpenAI-compatible base URL at https://api.ofox.ai/v1, and choose your model. Best when you like the Codex UX but want backend flexibility. Setup is one environment variable.
• --sandbox workspace-write --ask-for-approval never. Same Codex, no prompts, filesystem boundary intact. Best for unattended local runs on a machine you trust.
• Disposable container plus --yolo. Full bypass inside an isolated VM or container. Best for throwaway environments where nothing on the host can be harmed.
• Other agentic CLIs. Claude Code and Cursor have their own permission models. If you fight the Codex sandbox constantly, a different tool’s defaults may suit you better. Compare them in Claude Code vs Codex CLI vs Cursor.

The honest default for most people is the first or second option: keep the sandbox, fix the root cause, and only loosen controls deliberately.

FAQ

The questions above the fold mirror the most common searches around this prompt. The full set is in the FAQ schema for this page; the short version is: on Linux, install bubblewrap; everywhere, set approval_policy = "on-request" and sandbox_mode = "workspace-write"; if both are correct, suspect a version regression in the 0.115–0.118 range and pin to a known-good build.

Sources Checked for This Refresh

• Codex Configuration Reference, for approval_policy, sandbox_mode, and [sandbox_workspace_write] keys and values (verified 2026-06-29): https://developers.openai.com/codex/config-reference
• Codex Sandbox concepts, for Seatbelt on macOS, bubblewrap on Linux/WSL2, native Windows sandbox, first bwrap on PATH plus bundled helper fallback (verified 2026-06-29): https://developers.openai.com/codex/concepts/sandboxing
• Codex CLI command-line reference, for --ask-for-approval (-a), --sandbox (-s), --full-auto (deprecated), --dangerously-bypass-approvals-and-sandbox / --yolo (verified 2026-06-29): https://developers.openai.com/codex/cli/reference
• GitHub issue #19162, “retry without sandbox” for every command, 0.115.0+ (verified 2026-06-29): https://github.com/openai/codex/issues/19162
• GitHub issue #16407, 0.118.0 apply_patch regression, 0.117.0 works (verified 2026-06-29): https://github.com/openai/codex/issues/16407
• GitHub issue #18079, misleading prompt even when bwrap and writes work (verified 2026-06-29): https://github.com/openai/codex/issues/18079
• ofox API catalog, OpenAI-compatible base URL https://api.ofox.ai/v1, GPT-5.4 family and GPT-5.3 Codex listed (verified 2026-06-29): https://ofox.io/docs