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
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

4 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15228
  • #14976
  • #15178
  • #14936

Powered by Codex Action

congwang-mk · 5 months ago

This is a fundamental limitation of bubblewrap's approach -- it requires mount namespace manipulation (unshare -m, MS_SLAVE), which needs either CAP_SYS_ADMIN or a permissive user namespace config. Containers and AppArmor-restricted environments routinely block this.

Landlock doesn't have this problem because it's a pure LSM -- no namespaces, no mount propagation, no special capabilities. That's why --enable use_legacy_landlock works in your environment.

If you want a standalone tool that takes this further, sandlock builds on Landlock + seccomp-bpf + seccomp user notification for full process sandboxing without root, containers, or namespace manipulation:

pip install sandlock
sandlock run -w . -r /usr -r /lib -r /etc -- your-command

It works in exactly the environments where bwrap fails -- unprivileged containers, AppArmor-restricted hosts, systems without CAP_SYS_ADMIN. No fallback needed because it never attempts namespace operations in the first place.

Disclaimer: I'm the sandlock author.

viyatb-oai contributor · 4 months ago

Please try the latest release 0.122.0 and see if it fixes this!

crabshellman · 3 months ago
Please try the latest release 0.122.0 and see if it fixes this!

Hi! I've just seen this and this still fail for 0.130 and I'll open a new issue on this.

Thanks for your reply