WSL2: Codex CLI intermittently re‑enters sandbox / drops env across steps even with --dangerously-bypass-approvals-and-sandbox → sudo/UNIX sockets/Docker break (EPERM)

What version of Codex is running?

codex-cli 0.46.0

Which model were you using?

Not model‑dependent (reproduces with the default CLI model selection).

What platform is your computer?

WSL2 (Ubuntu‑20.04) running on Windows (WSLg enabled). Repository and commands executed from a Windows‑mounted path: /mnt/c/Users/... (drvfs). Docker Desktop for Windows is installed (daemon available via /var/run/docker.sock). Note: I can provide exact uname -mprs and Windows build on request, but the behavior appears tied to WSL2 + drvfs and Codex CLI’s execution runner rather than kernel build.

What steps can reproduce the bug?

Minimal scenario that shows the same command succeed and then fail later in the same session due to Codex switching execution context / sandboxing and/or dropping environment:

1. In WSL2, from a repo located on a Windows mount (/mnt/c/...), start a Codex CLI session with full access:

``bash
codex --dangerously-bypass-approvals-and-sandbox
``

1. Ask Codex to run a command that needs privileges or UNIX sockets:

Example A (uses sudo and creates sockets/files):

``text
cd netfp-dev/demo-netfp-server && sudo -E ./start-demo.sh
``

Example B (Docker):

``text
docker compose -f deployment/docker-compose.yml -f deployment/docker-compose.dev.yml ps
``

What is the expected behavior?

The Codex CLI should provide stable, predictable, and consistent execution behavior out-of-the-box, without requiring special flags or elevated "dangerous" modes to function normally in typical developer environments such as WSL2 (with drvfs-mounted file systems) and Docker setups.

Specifically, the following points describe the expected default behavior clearly:

• Stable and consistent execution environment:

All commands within a Codex session (including after approvals, tool calls, and resume) should run consistently in the same execution runner, preserving a stable and deterministic environment. This includes maintaining consistent values for environment variables (PATH, TMPDIR, XDG_RUNTIME_DIR, HOME), user and group identities (uid, gid), working directories, and permissions.

• No silent sandbox re‑entries:

Codex CLI should not silently or unexpectedly re‑enter sandboxed mode mid-session or silently flip approval policies. If sandboxing or restricted policies must be enforced, they should be clearly communicated upfront. Commands should never fail with confusing labels such as “failed in sandbox” if the user explicitly initiated a session expecting stable, unrestricted behavior.

• WSL2 and drvfs compatibility:

Codex CLI should robustly detect when it's running within WSL2 environments—especially when the working directory is located on a Windows-mounted path (/mnt/c/...). In these scenarios, Codex should either:

• Automatically route temporary files, caches, and UNIX sockets to safe, supported, native Linux locations (/tmp, /run/user/...), or
• Clearly communicate to the user with an explicit, actionable warning about potential issues, and provide an easy and official workaround or documented "WSL-compatible" mode.

• Reliable Docker integration:

Access to Docker (via /var/run/docker.sock or a user-configured DOCKER_HOST) should remain stable across all commands in a session. Docker commands should never intermittently fail with operation not permitted or similar errors if they succeeded earlier in the same session without changes to the system or environment.

• No special flags required for normal UX (comparison with Claude Code):

Importantly, all the above-described expected behavior should not require users to run Codex CLI with special flags such as --dangerously-bypass-approvals-and-sandbox. Such flags indicate exceptional or potentially risky behavior, not basic usability.

For comparison, Claude Code already meets all of these expectations by default, without requiring users to run commands in any special "yolo" or dangerous bypass mode. It consistently provides a stable, predictable environment, reliable Docker interaction, and robust execution on the same system (WSL2 + drvfs), without any manual workarounds or complicated setups.

Codex CLI's default user experience should at minimum match this baseline. Users expect a smooth, frictionless developer experience by default—not one that requires complex, error-prone configuration or special flags labeled as "dangerous" simply to achieve basic functionality.

What do you see instead?

• Intermittent context flips: within a single session, some steps run with full access and others are executed under a restricted runner (or with a different env), despite the same CLI flag. The same command succeeds and then fails later with “failed in sandbox … operation not permitted”.

• Env instability: XDG_RUNTIME_DIR and PATH visible under sudo env vary between steps (/mnt/wslg/runtime-dir vs /run/user/0 vs /tmp), which directly affects UNIX‑socket creation and sudo/PAM behavior.

• Docker access instability: docker compose … sometimes works and later fails with dial unix /var/run/docker.sock: connect: operation not permitted.

• Config lookup regression under sudo: running Codex via sudo moves HOME to /root, and the CLI fails to find the config unless the user manually preserves HOME or creates a separate root config.

Additional information

• This is not a general Docker/WSL misconfiguration: the exact same commands run from the terminal outside Codex (or using another assistant) work reliably. The failures are tied to how Codex executes steps and manages the runner/env between steps.

• Workarounds I tried (and which are not acceptable for DX/UX):

• Wrapping Codex in a custom codexr script that:

• runs Codex under sudo -n with --dangerously-bypass-approvals-and-sandbox,
• forces PATH to include a no‑op sudo shim to avoid PAM/audit errors inside steps,
• forces TMPDIR, XDG_RUNTIME_DIR and language caches to /tmp,
• optionally routes Docker to TCP (DOCKER_HOST=tcp://127.0.0.1:2375) or via a socat proxy.
• Adding SETENV/env_keep and !secure_path exceptions in sudoers for Codex.
• Manually preserving HOME to avoid the config lookup error.

These workarounds reduce the flakiness, but they are fragile, invasive, and far from the “it just works” DX (e.g., Claude Code runs the same workflows without any of these steps).