Linux sandbox lacks an actionable diagnostic when bwrap is blocked and Landlock is unavailable
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- linux, rust
- Domain
- cli, operating-systems, security
Research direction
Start in linux-sandbox/src/linux_run_main.rs and reproduce the two commands with codex sandbox linux, including the legacy Landlock configuration. Trace how Bubblewrap and Landlock failures are reported; done means both unavailable-backend conditions produce an actionable normal error and the Landlock path no longer panics.
Written by the indexing model from the issue text.
Description
What version of Codex CLI is running?
codex-cli 0.145.0
What subscription do you have?
Pro
Which model were you using?
N/A — the failure occurs during local sandbox startup, before a model-generated command can execute.
What platform is your computer?
Linux 5.4.0-171-generic x86_64 x86_64
What terminal emulator and version are you using (if applicable)?
Browser-based Jupyter terminal running in a Kubernetes/containerd container.
Codex doctor report
Not available — codex doctor --json was not captured before the
reproducing node was replaced. The replacement node does not have
Codex installed, so its doctor report would not describe the
reproducing environment.
What issue are you seeing?
Codex cannot start either Linux sandbox backend in this restricted container environment.
The default Bubblewrap backend fails because mount namespace and mount propagation operations are denied by the container/AppArmor policy:
bwrap: Failed to make / slave: Permission denied
The legacy Landlock backend also fails:
error applying legacy Linux sandbox restrictions:
Sandbox(LandlockRestrict)
The host is running Linux 5.4, which predates Landlock support. The environment may therefore be incapable of supporting either safe sandbox backend.
The issue being reported is the error handling and diagnostics: Codex shows a low-level Bubblewrap error, while the Landlock path terminates with a Rust panic. It does not clearly explain that neither safe sandbox
backend is available or state the host requirements needed to resolve the problem.
### What steps can reproduce the bug?
Thread ID: N/A — reproduced directly with `codex sandbox linux`,
outside an interactive Codex thread.
Environment:
- Codex CLI: `0.145.0`
- Bubblewrap: `0.9.0`
- Kernel: `5.4.0-171-generic`
- Architecture: `x86_64`
- AppArmor profile: `cri-containerd.apparmor.d (enforce)`
- Root mount propagation: `private,slave`
Run:
```bash
unshare --user --map-root-user true
echo $?
Result:
0
Run:
unshare --user --map-root-user --mount \
sh -c 'mount --make-rslave /'
Result:
unshare: cannot change root filesystem propagation: Permission denied
Run:
bwrap --ro-bind / / /bin/true
Result:
bwrap: Creating new namespace failed: Operation not permitted
Run the default Codex sandbox:
codex sandbox linux -- /bin/true
Result:
bwrap: Failed to make / slave: Permission denied
Run the legacy Landlock sandbox:
codex \
-c 'features.use_legacy_landlock=true' \
sandbox linux -- /bin/true
Result:
thread 'main' panicked at linux-sandbox/src/linux_run_main.rs:
error applying legacy Linux sandbox restrictions:
Sandbox(LandlockRestrict)
### What is the expected behavior?
Codex should detect that neither safe Linux sandbox backend is
available and exit cleanly with an actionable diagnostic.
The diagnostic should state that:
- Bubblewrap cannot operate because mount namespace operations are
denied by the container/AppArmor policy.
- Landlock is unavailable on the running kernel.
- `workspace-write` and `read-only` sandbox execution cannot start
until the host or container configuration is changed.
The Landlock path should return a normal error rather than a Rust panic.
Codex should not automatically fall back to unrestricted execution.
### Additional information
Related issues:
- #15434 and #23468 report the same Bubblewrap
`Failed to make / slave` error, but Landlock worked in those
environments.
- #29908 covers related AppArmor/user-namespace failures with different
Bubblewrap errors.
- #34008 covers both sandbox backends being unavailable for a different
`pivot_root` cause.
This case differs from #15434 and #23468 because Bubblewrap is blocked
by the container policy while Landlock cannot serve as a fallback on
the Linux 5.4 host.
This report is specifically about preflight detection, actionable error
reporting, and avoiding the Rust panic. It is not requesting that Codex
bypass AppArmor or silently fall back to unrestricted execution.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- Avg merge
- 1m
- Merged PRs (30d)
- 1k
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug CLI windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
macOS sandbox blocks hw.optional.arm64 sysctl, causing Flutter to misdetect Apple Silicon as x64 Openbug CLI sandbox
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug CLI TUI
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
CLI config enhancement skills
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
A-linter
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
oxc-project/oxc#26863 ·