Summary
apply_patch and ordinary managed sandbox commands fail before the requested command can run. The failure appears to come from Bubblewrap sandbox setup, not from repository file permissions.
Environment
- OS: Ubuntu 24.04
- Kernel: 6.17.0-35-generic
- Bubblewrap: 0.9.0
kernel.unprivileged_userns_clone = 1kernel.apparmor_restrict_unprivileged_userns = 1/usr/bin/bwrap is a normal executable, not setuid, with no file capabilities
No local usernames, workspace paths, repository paths, or secrets are included in this report.
Observed behavior
apply_patch fails before it can read a file in the configured writable workspace. The same sandbox failure can also occur for simple sandboxed commands such as id, uname, or which bwrap.
Error from apply_patch:
fs sandbox helper failed with status exit status: 1:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
Minimal diagnostics
Outside the managed sandbox, Bubblewrap itself is present:
Minimal Bubblewrap tests fail:
bwrap --ro-bind / / true
# bwrap: setting up uid map: Permission denied
bwrap --unshare-net --ro-bind / / true
# bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
Expected behavior
apply_patch should be able to edit files under the configured writable workspace root, or Codex should provide a supported fallback edit path that still enforces workspace-write restrictions without requiring host-wide security changes.
Actual behavior
The file-edit path is unusable because the sandbox helper depends on Bubblewrap/user namespace/network namespace behavior blocked by the host security configuration.
Request
Please make the apply_patch / managed sandbox path robust on Ubuntu systems with AppArmor unprivileged user namespace restrictions, or provide a supported fallback that does not require changing host-wide sysctl/security settings.
Applied devbox recurrence — July 6, 2026
A Codex user on Applied devboxes reported that both apply_patch and general command execution became blocked after the local Bubblewrap sandbox could not read /proc/sys/kernel/overflowuid; /proc/sys/crypto/fips_enabled also returned an unexpected error. Codex escalated or used in-place editing fallbacks. Restarting the devbox restored operation, suggesting an unhealthy or disconnected proc mount rather than repository permissions.
Source: https://openai.enterprise.slack.com/archives/C08MGJXUCUQ/p1783397892149239
This is the same user-visible failure family—managed commands and apply_patch fail before the requested operation—but a different host-level trigger from the original loopback/user-namespace reproduction. Diagnostics should capture the Codex/CLI build, devbox image and kernel, mount namespace state, /proc mount health, the exact Bubblewrap command/error, and whether the failure began after a benchmark or sandbox lifecycle event. A restart is a recovery, not a fix.
Summary
apply_patchand ordinary managed sandbox commands fail before the requested command can run. The failure appears to come from Bubblewrap sandbox setup, not from repository file permissions.Environment
kernel.unprivileged_userns_clone = 1kernel.apparmor_restrict_unprivileged_userns = 1/usr/bin/bwrapis a normal executable, not setuid, with no file capabilitiesNo local usernames, workspace paths, repository paths, or secrets are included in this report.
Observed behavior
apply_patchfails before it can read a file in the configured writable workspace. The same sandbox failure can also occur for simple sandboxed commands such asid,uname, orwhich bwrap.Error from
apply_patch:Minimal diagnostics
Outside the managed sandbox, Bubblewrap itself is present:
Minimal Bubblewrap tests fail:
Expected behavior
apply_patchshould be able to edit files under the configured writable workspace root, or Codex should provide a supported fallback edit path that still enforces workspace-write restrictions without requiring host-wide security changes.Actual behavior
The file-edit path is unusable because the sandbox helper depends on Bubblewrap/user namespace/network namespace behavior blocked by the host security configuration.
Request
Please make the
apply_patch/ managed sandbox path robust on Ubuntu systems with AppArmor unprivileged user namespace restrictions, or provide a supported fallback that does not require changing host-wide sysctl/security settings.Applied devbox recurrence — July 6, 2026
A Codex user on Applied devboxes reported that both
apply_patchand general command execution became blocked after the local Bubblewrap sandbox could not read/proc/sys/kernel/overflowuid;/proc/sys/crypto/fips_enabledalso returned an unexpected error. Codex escalated or used in-place editing fallbacks. Restarting the devbox restored operation, suggesting an unhealthy or disconnected proc mount rather than repository permissions.Source: https://openai.enterprise.slack.com/archives/C08MGJXUCUQ/p1783397892149239
This is the same user-visible failure family—managed commands and
apply_patchfail before the requested operation—but a different host-level trigger from the original loopback/user-namespace reproduction. Diagnostics should capture the Codex/CLI build, devbox image and kernel, mount namespace state,/procmount health, the exact Bubblewrap command/error, and whether the failure began after a benchmark or sandbox lifecycle event. A restart is a recovery, not a fix.