Codex Keeps Asking to Retry Without Sandbox

Most people are one install or one config line away from a fix. Run these in order; the first one that comes back wrong is your fix.

Run these three checks

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. For the full set of config.toml keys this post touches, the Codex CLI config.toml reference is the source of truth.

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 sandbox — the technical boundary

The approval policy — when Codex stops to ask

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.

Where the prompt comes from

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

So 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. 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."

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

Match your symptom to the cause before you change a setting. Picking the wrong one is why people spend an afternoon re-typing a config that was never the problem.

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.

Work top to bottom. Fix 1 is the one most Linux users are missing. The rest cover config, network, the version regression, and the writable-roots case.

LINUX / WSL2

# 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

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

APPROVAL POLICY

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

SANDBOX MODE

sandbox_mode = "workspace-write"

NETWORK

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

VERSION REGRESSION

# 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

MACOS / CROSS-PLATFORM

sandbox_mode = "workspace-write"

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

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

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

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.

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. Recent builds ship a codex doctor-style diagnostic; run codex --help to see the subcommands your version exposes, since these change between releases.

Capture a working setup as a profile

Once you have a setup that works, capture it as a named profile so you are not re-typing flags. 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"

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. You point it at whichever gateway or provider you already trust — your own, a hosted one, a self-hosted proxy — keep your sandbox and approval settings exactly as above, and route to whichever model you want:

# point Codex at any OpenAI-compatible endpoint of your choosing
export OPENAI_BASE_URL="https://your-gateway.example/v1"
export OPENAI_API_KEY="your-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. A unified gateway keeps one base_url and one key across many models, so switching a model is a one-string edit rather than a new provider block each time — and your local safety controls stay in place regardless of which backend you route to.

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

The honest default for most people is the first or second option: keep the sandbox, fix the root cause, and only loosen controls deliberately. The gateway option is about backend flexibility — not about removing safety.

The fixes above silence the prompt. The rest is the part worth acting on before the next regression.

You can read this prompt two ways. The narrow way: install bubblewrap, set on-request, move on. The useful way: a tool you depend on has a safety layer you don't own, and the only signal that it broke was that every routine command stopped to ask permission.

We see a version of this in nearly every AI system we audit. A team builds on one client and one default model, and a sandbox regression, a deprecation, or a quiet config default turns a working setup into a half-day of guessing. The Codex sandbox prompt is just the most recent, most specific instance of it.

Three things make a setup survive these changes:

If your workflow stops because one tool's sandbox regressed, the workflow failed the design test — not the tool.