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-genericx86_64 - Running inside container (overlay root mount)
- Launch flags:
--sandbox workspace-write --ask-for-approval on-request - User:
rootin container, but withoutCAP_SYS_ADMINin bounding set
---
Reproduction
- 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_This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗