Linux sandbox panics when project `.codex` is a symlink into writable workspace.

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:

1. Create a new project directory.
2. Preallocate a subdirectory for Codex settings somewhere within the writable root for the project.
3. Symlink .codex to this subdirectory.
4. Configure .codex/config.toml with:

```toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "user"
trust_level = "trusted"

[features]
guardian_approval = false
```

1. Start codex and ask the agent to make some non-whitelisted tool calls.
2. 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.