Codex sandbox on Linux: `error building bubblewrap command: mountinfo path is not absolute` after a ChatGPT app / VS Code extension update

Context

Source(s): https://github.com/openai/codex/issues/47345 Status: reported working by source, not reproduced by us.

Problem

Right after the ChatGPT Linux desktop app or the Codex VS Code extension auto-updated (late September 2026, builds bundling codex-cli 0.155.0-alpha.16), every sandboxed shell command and every apply_patch fails with the error above, so the agent cannot write any files. Restarting the app or the machine does not help. The system bwrap binary itself still works.

Error (redacted / normalized)

error building bubblewrap command: mountinfo path is not absolute

error building bubblewrap command: app-server socket directory has an unsupported host mount at /mnt/wslg/distro; remove the bind-mount alias or nested mount before starting the sandbox

Applies when

Ubuntu 24.04 and other distros (deb and rpm installs), ChatGPT desktop 26.917.x, Codex VS Code extension 26.917.x / 26.5917.x (pre-release). Bundled codex-cli 0.155.0-alpha.16.

Confirm it is this problem

1. Run the Codex binary bundled with the app or extension directly: <bundled-codex> sandbox /bin/true → expect: error building bubblewrap command: mountinfo path is not absolute, exit status 1.
2. Check the bundled version: <bundled-codex> --version → expect: codex-cli 0.155.0-alpha.16 (or a .x suffix of it).
3. Optional: list mount entries whose root field is not a path: awk '$4 !~ /^\// {print}' /proc/self/mountinfo. A commenter found an nsfs entry such as mnt:[4026532574] /run/snapd/ns/cups.mnt only on the affected machine. (Command adapted by us from the commenter's finding; our inference.)

Not this when / boundary

The WSL2 error about /mnt/wslg/distro (see error_samples) is a separate bug with its own fix; it is not solved by the snapd explanation. Also, after updating to 26.928.31416 some commenters saw a different problem (messages dropped, logs showing thread ... already has an active writer); that is not this bug.

Root cause

A project contributor said it is a known Linux sandbox bug with namespace mounts such as the ones snapd creates. The fix was already merged into a newer Codex CLI, but the desktop app and the extension were still shipping an older bundled CLI.

Fix

1. Update the VS Code Codex extension to 26.928.31416 or later (release channel). → expect: a commenter confirmed the sandbox works again on that version.
2. For the ChatGPT desktop app, install the next release that bundles the newer CLI (a project contributor said the fix ships in the next desktop release). The original poster later confirmed it was fixed.
3. If you can't update yet, roll the VS Code extension back to 26.908.40401 (two commenters confirmed this works; you lose models added after that build).
4. Alternative used by a commenter: install a newer standalone Codex CLI and point the extension at it with the VS Code setting "chatgpt.cliExecutable": "<path-to-newer-codex>". In one commenter's comparison the standalone CLI passed codex sandbox -- /bin/true on the same machine.

How to verify

<bundled-codex> sandbox /bin/true; echo $? → expect: 0, and the agent can apply patches again.

What did not work

Restarting Codex, restarting the ChatGPT app, and checking /proc/self/mountinfo mount points (field 5) did not help or show anything.

Risks

Rolling back loses newer models. our note: do not "fix" this by turning the sandbox off or approving every command to run outside it; that removes the protection the sandbox is there for.

Verified scope

ChatGPT desktop / Codex VS Code extension builds from 2026-09-22 to early October 2026.

Becomes obsolete when

All channels ship a bundled CLI that includes the fix.