Linux sandbox regression: default backend denies /dev/null and /dev/zero; legacy Landlock works
Summary
On Linux with codex-cli 0.118.0, the default sandbox backend denies access to /dev/null and /dev/zero, which breaks normal shell redirections and device-file reads. Enabling use_legacy_landlock=true in the same environment fixes the problem immediately.
This looks like a regression in the default bubblewrap-backed Linux sandbox path rather than a general Ubuntu or host configuration issue.
Environment
- Codex CLI:
0.118.0 - OS: Ubuntu 24.04
- Kernel:
6.17.0-19-generic - bubblewrap:
0.9.0 - Sandbox mode:
workspace-write - Approval policy:
never
Reproduction
With the default Linux sandbox backend:
cat /dev/null
printf test >/dev/null
head -c 8 /dev/zero | od -An -tx1
Observed results:
cat: /dev/null: Permission denied
/bin/bash: line 1: /dev/null: Permission denied
head: cannot open /dev/zero for reading: Permission denied
This also caused shell startup noise in some cases because startup scripts that touched /dev/null would fail.
Control / Comparison
In the same environment, after enabling legacy Landlock:
codex --enable use_legacy_landlock
The same tests succeed:
cat /dev/null
printf test >/dev/null
head -c 8 /dev/zero | od -An -tx1
Observed results:
<success>
<success>
00 00 00 00 00 00 00 00
codex features list reports:
use_legacy_landlock stable true
Why this matters
Blocking /dev/null breaks common shell patterns like:
>/dev/null
2>/dev/null
</dev/null
That has a wide blast radius across wrappers, probes, installers, test harnesses, and scripts that rely on standard Unix device semantics.
Related context
I found a related earlier issue/PR in the repo about Linux sandbox device handling:
- #12056
- #12081
This report may be the same class of bug, or a regression / alternate code path where the /dev fix is not taking effect.
Expected behavior
The default Linux sandbox should allow standard access to /dev/null and /dev/zero.
Actual behavior
The default backend denies access, while use_legacy_landlock=true restores expected behavior in the same environment.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Adding explicit repro steps for maintainers.
Repro steps
Default backend path:
Then, from inside the Codex session, run:
Observed in my environment:
Comparison case
Launch Codex with legacy Landlock enabled:
Then run the same commands inside the Codex session:
Observed in the same environment:
That comparison is what makes me think this is specifically the default Linux sandbox backend path rather than a general host or Ubuntu issue.
Quick version update: this issue is still present in
codex-cli 0.122.0.Proposed fix for this issue:
Root cause:
/devworks correctly when mounted with--dev /dev/devover that synthetic mount when/devitself was treated as a writable rootbwrap --ro-bind / / --proc /proc --dev /dev ...worksbwrap --ro-bind / / --proc /proc --dev /dev --bind /dev /dev ...fails for/dev/nulland/dev/zeroProposed fix:
/dev, keep bubblewrap's synthetic/devin place instead of rebinding host/dev/dev/nulland/dev/zerounder the rootless bwrap pathValidation I ran against the patched tree:
cargo test -p codex-linux-sandboxcargo test -p codex-cli --test sandbox_linux_devices -- --nocaptureworkspace-write+/devwritable-root path:/dev/nullwrite succeeds/dev/zeroread succeedsPatch (
issue-16451-proposed-fix.patch):<details>
<summary>Show patch</summary>
</details>
This is still an issue on 0.125.0.
Reproduction notes and proposed fix path
I took a pass at reducing this to an actionable code path before suggesting a fix.
Breakdown:
Proposed approach:
Precedent: #29189 Codex Desktop 26.616.41845 node_repl fails: codex/sandbox-state-meta missing sandboxPolicy
How I shaped this comment from prior successful threads:
This analysis was prepared with AI assistance.
<!-- fkst:codex-saga:engage:codex-triage:dup:openai/codex#16451 -->