Ubuntu bwrap failure causes excessive permission prompts for every read-only command
What issue are you seeing?
Codex asks for permission repeatedly—often around 15 times in a single turn—even after the user explicitly authorizes broader access.
On an Ubuntu 24.04 remote server using a managed workspace-write permission profile, every normal sandboxed shell command fails immediately with:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
Codex must then retry each read-only operation with escalated execution, producing a separate permission prompt. This affects harmless workspace discovery such as pwd, find, rg --files, sed, Git metadata reads, and Docker status inspection.
Saved approvals are frequently too narrow or are recorded as exact compound shell invocations, so they do not prevent the next closely related read-only command from prompting again.
Steps to reproduce
- Connect Codex to an Ubuntu 24.04 server where Bubblewrap cannot configure its loopback interface.
- Use a managed
workspace-writeprofile with the project directory writable. - Ask Codex to familiarize itself with an operational Docker project.
- Observe the first sandboxed read-only command fail with
Failed RTM_NEWADDR. - Approve the escalated retry and choose persistent approval where offered.
- Continue ordinary read-only inspection using
find,sed,git, anddocker ps. - Observe repeated approval prompts throughout the same turn despite the broader user authorization.
Expected behavior
- Read-only operations within an authorized workspace should not require repeated prompts.
- If sandbox initialization fails for a known host-level reason, Codex should surface one clear prompt offering a task- or session-scoped fallback.
- Persistent approvals should apply predictably to safe command families rather than exact compound command strings.
- The UI should explain whether “broader permissions” remain constrained by sandbox initialization failure.
- A single approval should allow a bounded read-only discovery workflow to continue without repeated interruption.
Actual behavior
Every new command category or slightly different command shape triggers another prompt. The user cannot grant an effective session-scoped read-only fallback, making routine server orientation highly disruptive.
Environment
- Ubuntu 24.04.3 LTS
- Linux 6.8 x86_64
- Remote/headless server
- Managed permission profile
sandbox_mode = workspace-write- Workspace root: user home/project directory
- Initial sandbox failure:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
Related issues
- #30898 — full access and approved prefixes still trigger prompts
- #29406 — “don’t ask again” does not persist across related operations
- #15769 — same Bubblewrap loopback failure blocks review commands
This report focuses on the combined failure mode: sandbox initialization fails on Ubuntu, and the escalation UX then produces excessive per-command prompts with no usable task/session-scoped fallback.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗