Bubblewrap regression on Linux/WSL: missing writable_roots fail command startup and detached children are reaped

[escape0707]

What version of Codex CLI is running?

0.115.0-alpha.11+ (last known good: 0.115.0-alpha.9)

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 unknown

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

VSCode integrated terminal on WSL, Windows Terminal

What issue are you seeing?

After 04892b4 (refactor: make bubblewrap the default Linux sandbox), Linux/WSL workspace-write behavior regressed in two ways:

1. If sandbox_workspace_write.writable_roots contains a well-formed path that does not exist, that sandboxed command invocation fails during setup.
2. If a normal non-elevated shell tool call starts a detached child process, that child is reaped when the one-shot tool call ends.

The first regression makes it harder to share or combine Windows Codex App and WSL Codex homes, because a Windows-only or misparsed writable_root is no longer harmless on Linux.

The second regression is what makes Playwright extension sessions unstable: the Playwright MCP Bridge bar appears, then disappears a few seconds later because the detached bridge process does not survive.

Environment:

• Host: Codex CLI, VSCode Codex Extension on WSL2
• OS: ArchLinux on WSL2
• Sandbox mode: workspace-write

Regression window:

• Last known good published version: 0.115.0-alpha.9
• First known bad published version: 0.115.0-alpha.11
• Exact last known good source commit: b5f927b97327ab62047dba9eaf0e998bfaa7dab3
• Likely introducing commit: 04892b4ceb3ba6516eddd21c3f7ed2920a977442
• First runnable bad source commit: e99e8e4a6bc2959266d4dd34c34e2b84e472ac52

What steps can reproduce the bug?

Regression A: Missing writable_root fails command startup

1. Configure workspace-write with one existing and one missing writable root:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true
writable_roots = [
  "~/.cache/codex-writable-root-existing",
  "~/.cache/codex-writable-root-missing",
]

Assume ~/.cache/codex-writable-root-existing exists and ~/.cache/codex-writable-root-missing does not.

2. Start a fresh Codex session in WSL.
3. Run any normal non-elevated tool command, for example pwd.

Regression B: Detached child is reaped when the one-shot tool call ends

1. Create /tmp/codex-detach-probe.js:

const { spawn } = require("child_process");

const log = "/tmp/codex-detach.log";
const child = spawn(
  process.execPath,
  [
    "-e",
    'const fs = require("fs"); const log = process.argv[1]; setInterval(() => fs.appendFileSync(log, Date.now() + "\\n"), 500)',
    log,
  ],
  { detached: true, stdio: "ignore" },
);

child.unref();

2. In a fresh VSCode Codex Extension session on WSL, run node /tmp/codex-detach-probe.js as a single normal non-elevated shell tool call.
3. After the tool call returns, wait about 2 seconds.
4. Check whether /tmp/codex-detach.log exists and keeps growing.

What is the expected behavior?

Missing optional writable_roots should be ignored or skipped instead of failing that command invocation during sandbox setup.

A detached unref() child should remain alive after the parent tool process exits.

Additional information

This reproduces without Playwright. Playwright only makes the symptom obvious because the Playwright MCP Bridge session disappears a few seconds after connect.

The same detached-child probe succeeds in 0.114.0, 0.115.0-alpha.9, and from a persistent PTY shell on the same machine, so this is not a generic Linux/WSL limitation.

A separate writable_roots config for Windows and Linux would be preferable, but that likely belongs in a separate issue. The regression here is that a non-applicable path is no longer harmless. (But IIRC that's by design of bubblewrap.)

If preferred, these can be split into two issues, but they appear to share the same bubblewrap-switch regression window.

---

Edit:

Oh my! I didn't expect such a speedy review and solution of my issue from OpenAI. I'll be available today to test the fixes on my machine as soon as both of the PRs are merged!

---

Edit 2:

For now I'm using:

pnpm add -g @openai/codex@0.115.0-alpha.9 --save-exact

and in VSCode's settings.json:

"chatgpt.cliExecutable": "codex",

as a workaround.