Codex CLI (and VSCode extension) sandbox unable to handle /proc mounting failures

What version of Codex CLI is running?

0.153.4

What subscription do you have?

Plus

Which model were you using?

gpt-6 Astra

What platform is your computer?

Linux 7.1.13-200.fc44.x86_64 x86_64 unknown

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

No response

Codex doctor report

What issue are you seeing?

I run Codex CLI and VSCode with Codex extension inside a Podman container. Codex's Bubblewrap Linux sandbox fails while trying to mount a fresh /proc:

bwrap: Can't mount proc on /proc: Operation not permitted

Codex seems to have a fallback for environments where mounting a fresh /proc is not permitted.

However, it failed to use the fallback because it wrongly identified as mounting /proc worked.

So in the end the sandbox cannot work and Codex keeps on asking user to run commend outside of the sandbox

The reason for the failure:

The failure detection expects the Bubblewrap error to contain:

/newroot/proc

Bubblewrap 0.12.0 on Fedora instead reports:

bwrap: Can't mount proc on /proc: Operation not permitted

As a result, Codex does not recognise the failure and does not fall back to running Bubblewrap without mounting a fresh /proc.

What steps can reproduce the bug?

podman run --rm -it fedora:44 bash -lc '
  dnf -y install nodejs npm bubblewrap &&
  npm install -g @openai/codex@0.153.4 &&
  echo "== bwrap ==" &&
  bwrap --unshare-user --unshare-pid --ro-bind / / --proc /proc true || true &&
  echo "== codex ==" &&
  codex sandbox linux -- true
'

What is the expected behavior?

It should detect correctly not being able to mount /proc via this Bubblewrap error:

bwrap: Can't mount proc on /proc: Operation not permitted

and automatically fall back to running Bubblewrap without --proc /proc.

Or there might be a better and secure solution to avoid mounting /proc in the first place?

Additional information

The relevant detection currently appears to require /newroot/proc:

fn is_proc_mount_failure(stderr: &str) -> bool {
    stderr.contains("Can't mount proc")
        && stderr.contains("/newroot/proc")
        && (stderr.contains("Invalid argument")
            || stderr.contains("Operation not permitted")
            || stderr.contains("Permission denied"))
}

A possible fix would be to avoid depending on the exact path reported by Bubblewrap:

fn is_proc_mount_failure(stderr: &str) -> bool {
    stderr.contains("Can't mount proc")
        && (stderr.contains("Invalid argument")
            || stderr.contains("Operation not permitted")
            || stderr.contains("Permission denied"))
}

Or, more conservatively, accept both path formats:

fn is_proc_mount_failure(stderr: &str) -> bool {
    stderr.contains("Can't mount proc")
        && (stderr.contains("/newroot/proc")
            || stderr.contains("on /proc"))
        && (stderr.contains("Invalid argument")
            || stderr.contains("Operation not permitted")
            || stderr.contains("Permission denied"))
}

A regression test for the Bubblewrap 0.12.0 output could be:

#[test]
fn detects_proc_mount_operation_not_permitted_on_proc() {
    assert!(is_proc_mount_failure(
        "bwrap: Can't mount proc on /proc: Operation not permitted"
    ));
}

Start by locating is_proc_mount_failure and its existing tests, then compare the Fedora Bubblewrap 0.12.0 output in the issue with the current detection. Add coverage for the reported /proc error and verify that the sandbox falls back without mounting a fresh /proc using the provided reproduction command.