Codex 0.153.4 fails to recognize the expected /proc mount failure when using bubblewrap 0.12.0

What version of Codex CLI is running?

v0.153.4

What subscription do you have?

Plus

Which model were you using?

Multiple, gpt-5.6 mainly

What platform is your computer?

Debian Trixie Podman container running on Fedora 44 host

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

No response

Codex doctor report

What issue are you seeing?

I think bubblewrap 0.12.0 exposed a bug in Codex's /proc mount fallback.

Codex currently checks for this exact string in is_proc_mount_failure():

stderr.contains("/newroot/proc")

With older bubblewrap versions, a denied proc mount was reported like:

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

But bubblewrap 0.12.0 changed the diagnostic to:

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

I think that change comes from this bubblewrap commit:

https://github.com/containers/bubblewrap/commit/c77dd38ebe75b4eabec3c9349d7099287886eeec

The underlying failure is the same, but Codex no longer recognizes it and doesn't fall back to mount_proc = false.

Would it make sense to avoid depending on the literal /newroot/proc path here, or also accept /proc?

Environment:

• Codex 0.153.4
• bubblewrap 0.12.0

What steps can reproduce the bug?

This is occurring when running Codex in a Debian Trixie Podman container on Fedora 44. The container has this custom SELinux label:

policy_module(codex_bwrap, 1.0)

gen_require(`
    attribute container_net_domain;

    type container_file_t;
    type device_t;
    type devpts_t;
    type proc_t;
')

# Create a standard confined container domain with MCS isolation and
# normal access to container_file_t.
container_domain_template(codex_bwrap, container)

# Codex requires network access.
typeattribute codex_bwrap_t container_net_domain;

# Bubblewrap-specific filesystem operations.
allow codex_bwrap_t device_t:filesystem remount;
allow codex_bwrap_t devpts_t:filesystem mount;
allow codex_bwrap_t proc_t:filesystem { mount remount };

What is the expected behavior?

No response

Additional information

No response

Start by locating the is_proc_mount_failure() entry point and the fallback that sets mount_proc = false. Compare its handling of the older /newroot/proc diagnostic with bubblewrap 0.12.0's /proc diagnostic, then verify that the expected fallback is recognized in the reported Debian Trixie Podman environment.