bubblewrap sandbox creates empty file in workspace named `.codex`

What version of Codex CLI is running?

0.121.0

What subscription do you have?

Pro

Which model were you using?

Default

What platform is your computer?

Linux, Ubuntu 24.04

What terminal emulator and version are you using (if applicable)?

VSCode integrated terminal

What issue are you seeing?

Running codex with features.use_linux_sandbox_bwrap=true always produces an empty .codex file in the workspace. I think it also keeps getting recreated whenever bwrap is internally invoked by codex, but not 100% sure. I've stopped using bwrap for now, since these files keep winding up everywhere on my computer

What steps can reproduce the bug?

Here's a fully self-contained repro (works on Linux).

The repro runs inside Docker for reproducibility purposes but I can reliably repro on my host machine as well.

curl -fsSL https://github.com/openai/codex/releases/latest/download/codex-x86_64-unknown-linux-musl.tar.gz | tar -xzO >/tmp/codex && chmod +x /tmp/codex

docker run --rm --privileged --mount type=bind,src=/tmp/codex,dst=/usr/local/bin/codex ubuntu:24.04 \
  bash -ec '
    codex sandbox linux --full-auto -c features.use_linux_sandbox_bwrap=true true
    stat .codex
  '

What is the expected behavior?

The empty .codex file should not be created.

Additional information

Here is Codex's theory as to the root cause:

• My working theory, backed by strace, is:

  - In Linux workspace-write + bubblewrap mode, Codex treats .codex as a protected read-only subpath inside the writable repo.
  - If repo/.codex does not exist, the sandbox builder deliberately emits --ro-bind /dev/null repo/.codex to block creation of that path
    inside the sandbox. That logic is in /home/b/src/github.com/openai/codex/codex-rs/linux-sandbox/src/bwrap.rs:255 and documented in /home/
    b/src/github.com/openai/codex/codex-rs/linux-sandbox/README.md:24.
  - To perform that bind mount, bubblewrap first creates the destination mountpoint as an empty regular file. Because the repo itself is a
    bind-mounted host path, that mountpoint creation leaks back into the real workspace as a persistent zero-byte 0444 .codex file.