What version of Codex CLI is running?
0.128.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.5
What platform is your computer?
Linux 6.17.0-1014-nvidia aarch64 aarch64
What terminal emulator and version are you using (if applicable)?
No response
What issue are you seeing?
While whitelisted commands succeed, non-whitelisted commands induce the following panic, which the agent sees and which is visible in the transcript file, even though it does not surface directly in the TUI:
thread 'main' (1119830) panicked at linux-sandbox/src/linux_run_main.rs:385:27:
error building bubblewrap command: Fatal("cannot enforce sandbox read-only path /home/me/src/lm-scribbles/.codex because it crosses writable symlink /home/me/src/lm-scribbles/.codex")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
This was not a problem with use_legacy_landlock = true. Since you're pushing Linux users towards Bubblewrap, I am trying to get my setup to work with your Bubblewrap sandbox.
What steps can reproduce the bug?
Reproduction:
- Create a new project directory.
- Preallocate a subdirectory for Codex settings somewhere within the writable root for the project.
- Symlink
.codex to this subdirectory.
- Configure
.codex/config.toml with:
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "user"
trust_level = "trusted"
[features]
guardian_approval = false
- Start
codex and ask the agent to make some non-whitelisted tool calls.
- Observe the results in the transcript file for the session as well as the agent's own reported experience.
Example from typical symlink farm for my projects:
$ find -maxdepth 1 -type l -exec ls -l {} +
lrwxrwxrwx 1 me me 34 Apr 2 22:31 ./AGENTS.md -> .auxiliary/configuration/AGENTS.md
lrwxrwxrwx 1 me me 38 Nov 15 12:02 ./.claude -> .auxiliary/configuration/coders/claude
lrwxrwxrwx 1 me me 34 Apr 2 22:31 ./CLAUDE.md -> .auxiliary/configuration/AGENTS.md
lrwxrwxrwx 1 me me 37 Apr 2 22:31 ./.codex -> .auxiliary/configuration/coders/codex
lrwxrwxrwx 1 me me 38 Apr 2 22:31 ./.gemini -> .auxiliary/configuration/coders/gemini
lrwxrwxrwx 1 me me 34 Apr 2 22:31 ./GEMINI.md -> .auxiliary/configuration/AGENTS.md
lrwxrwxrwx 1 me me 41 Nov 15 12:02 ./.mcp.json -> .auxiliary/configuration/mcp-servers.json
lrwxrwxrwx 1 me me 40 Nov 15 12:02 ./.opencode -> .auxiliary/configuration/coders/opencode
lrwxrwxrwx 1 me me 55 Nov 15 12:02 ./opencode.jsonc -> .auxiliary/configuration/coders/opencode/settings.jsonc
lrwxrwxrwx 1 me me 35 Apr 2 22:31 ./openspec -> documentation/architecture/openspec
What is the expected behavior?
Clean escalation to user rather than a panic which distracts the agent and fills the session transcript file needlessly.
Additional information
The official Codex sandboxing instructions, including the Ubuntu 24.04 AppArmor policies installation, were followed. Also, #15725 and #17079 were read before filing this issue.
Here is GPT 5.5's recollection of what we did:
• We first verified the host was failing the documented Bubblewrap path:
/usr/bin/bwrap --unshare-user --unshare-net \
--ro-bind / / \
--proc /proc \
--dev /dev \
/bin/true
Before the AppArmor fix, that failed with:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
And this also failed from outside the project:
cd /tmp && codex sandbox linux /bin/true
with the same RTM_NEWADDR error.
Then you installed/loaded the documented Ubuntu 24.04 profile:
sudo apt update
sudo apt install -y apparmor-profiles apparmor-utils
sudo install -m 0644 \
/usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
/etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict
We verified the files existed:
/etc/apparmor.d/bwrap-userns-restrict
/usr/share/apparmor/extra-profiles/bwrap-userns-restrict
Then reran the smoke tests:
/usr/bin/bwrap --unshare-user --unshare-net \
--ro-bind / / \
--proc /proc \
--dev /dev \
/bin/true
Result:
bwrap exit=0
cd /tmp && codex sandbox linux /bin/true
Result:
codex sandbox exit=0
So the host-level Bubblewrap/AppArmor setup was brought into line with the OpenAI sandboxing documentation, and the remaining .codex symlink panic is independent of the generic Ubuntu
AppArmor/userns failure.
In case someone wants to say "don't use symlinks", I have a good reason for doing so. This allows me to commit my agent harness preferences while not imposing them on others. I have created a tool which maintains the symlink farm in my clones and worktrees. No other major agent harness, with which I have worked, has a problem with this.
What version of Codex CLI is running?
0.128.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.5
What platform is your computer?
Linux 6.17.0-1014-nvidia aarch64 aarch64
What terminal emulator and version are you using (if applicable)?
No response
What issue are you seeing?
While whitelisted commands succeed, non-whitelisted commands induce the following panic, which the agent sees and which is visible in the transcript file, even though it does not surface directly in the TUI:
This was not a problem with
use_legacy_landlock = true. Since you're pushing Linux users towards Bubblewrap, I am trying to get my setup to work with your Bubblewrap sandbox.What steps can reproduce the bug?
Reproduction:
.codexto this subdirectory..codex/config.tomlwith:codexand ask the agent to make some non-whitelisted tool calls.Example from typical symlink farm for my projects:
What is the expected behavior?
Clean escalation to user rather than a panic which distracts the agent and fills the session transcript file needlessly.
Additional information
The official Codex sandboxing instructions, including the Ubuntu 24.04 AppArmor policies installation, were followed. Also, #15725 and #17079 were read before filing this issue.
Here is GPT 5.5's recollection of what we did:
In case someone wants to say "don't use symlinks", I have a good reason for doing so. This allows me to commit my agent harness preferences while not imposing them on others. I have created a tool which maintains the symlink farm in my clones and worktrees. No other major agent harness, with which I have worked, has a problem with this.