Regression in v0.116.0 Linux sandbox startup: bwrap fails with "Failed to make / slave", while Landlock works

Resolved 💬 4 comments Opened Mar 22, 2026 by crabshellman Closed Apr 21, 2026

What version of Codex CLI is running?

Codex CLI: 0.116.0

What subscription do you have?

Plus

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

Summary

After upgrading to Codex CLI 0.116.0, Linux sandbox startup regressed in my container environment.

workspace-write sessions repeatedly trigger approval prompts like:

command failed; retry without sandbox?

because sandbox startup fails with:

bwrap: Failed to make / slave: Permission denied

In the same environment, forcing Landlock works, and 0.114 did not show this problem.

---

Version / Environment

  • Codex CLI: 0.116.0
  • OS: Linux 5.15.0-141-generic x86_64
  • Running inside container (overlay root mount)
  • Launch flags: --sandbox workspace-write --ask-for-approval on-request
  • User: root in container, but without CAP_SYS_ADMIN in bounding set

---

Reproduction

  1. Start Codex in normal mode:
codex --sandbox workspace-write --ask-for-approval on-request

2. Ask it to create a file in current workspace (simple edit).
3. Observe approval prompt: command failed; retry without sandbox?

Minimal CLI repro:

codex --version
# codex-cli 0.116.0

codex sandbox linux -- pwd
# bwrap: Failed to make / slave: Permission denied

codex sandbox linux --enable use_legacy_landlock -- pwd
# <prints cwd successfully>

Extra diagnostics:

unshare -m /bin/true
# unshare: unshare failed: Operation not permitted

unshare -Urnm /bin/true
# unshare: cannot change root filesystem propagation: Permission denied

———

### Expected behavior

- If bwrap fails with this known permission pattern (mount propagation / EPERM), Codex should:
  - auto-fallback to Landlock when possible, or
  - provide a clear actionable message (e.g. suggest --enable use_legacy_landlock) without repeatedly prompting for unsandboxed retry for ordinary workspace edits.

———

### Actual behavior

- Sandbox fails via bwrap.
- Interactive flow keeps asking for unsandboxed retry.
- This makes normal workspace-write usage noisy and confusing.
- "Yes and don't ask again" in the prompt does not solve it across new sessions, since root cause persists.

———

### Regression signal

- Same environment on 0.114 did not have this issue.
- 0.116.0 release notes mention Linux sandbox startup changes and preferring system bwrap, which may be related.

———

### Workaround

Running with:

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

works in this environment.

### What steps can reproduce the bug?

Described above

### What is the expected behavior?

_No response_

### Additional information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗