Codex 0.153.4 fails to recognize the expected /proc mount failure when using bubblewrap 0.12.0
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- linux, rust
- Domain
- cli, operating-systems, security
Research direction
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.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- Avg merge
- 1m
- Merged PRs (30d)
- 1k
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug CLI windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
macOS sandbox blocks hw.optional.arm64 sysctl, causing Flutter to misdetect Apple Silicon as x64 Openbug CLI sandbox
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug CLI TUI
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
CLI config enhancement skills
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
bitcoindevkit/bdk-ffi#1125 ·