J.D. Hodges

TL;DR: Codex sandbox errors on Ubuntu 24.04 frequently trace back to one thing on freshly installed boxes: AppArmor blocking bwrap. A five-line /etc/apparmor.d/bwrap profile fixed it on my system. If you use Codex in conjunction with Claude Code and you’re hitting the same wall, paste your error into Claude Code and let it walk you through. 💪

The Issue: Codex Sandbox Hangs on Ubuntu 24.04

My Codex setup on a fresh Ubuntu 24.04 VM was not working well. Every codex exec call burned a ton of tokens over 2 or 3 minutes retrying fallback paths, then died. The MCP Codex tool connected in about 3 seconds and worked well but could not read local files or fetch URLs. A workaround was cat-ing every file into the prompt. Slow and goofy. 😜

The actual error, once I ran the simplest possible repro:

$ bwrap --dev-bind / / --unshare-net echo ok
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

If you see that line on your system, the AppArmor userns restriction is worth checking before anything else.

The Fix: Five Lines of AppArmor

Create /etc/apparmor.d/bwrap with this body:

abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}

Then load it:

sudo apparmor_parser -r /etc/apparmor.d/bwrap

That’s it. The profile shape is the same one Ubuntu ships for flatpak and chrome, scoped to /usr/bin/bwrap.

Verify

$ bwrap --dev-bind / / --unshare-net echo ok
ok
$ sudo aa-status | grep bwrap
   bwrap

If the canary still fails, look at the kernel log for AppArmor denials:

sudo journalctl -k | grep 'apparmor.*DENIED'

Why Ubuntu 24.04 Breaks Codex Sandboxes

Ubuntu 23.10+ sets kernel.apparmor_restrict_unprivileged_userns=1 by default. Bubblewrap needs unprivileged user namespaces to build its sandbox, and the restriction blocks unshare(CLONE_NEWUSER) unless a permitted AppArmor profile applies. Per the Launchpad thread, Canonical opted against shipping a default bwrap profile since bwrap can launch arbitrary binaries; admins opt in consciously. The five-line profile above is the pragmatic opt-in.

If you want tighter confinement than a compatibility stub, there is an upstream bwrap-userns-restrict profile that strips capability from bwrap‘s children via profile stacking. Heavier to install and maintain, so I’m leaving it for a later session.

One Gotcha After the Fix

After installing the profile, MCP Codex started reading my local files again. Good. Fetching URLs still failed inside sandbox=read-only with “Could not resolve host.” That was not a profile bug. The read-only preset on my Codex version uses bwrap --unshare-net, which isolates the sandbox from the network on purpose. Switching the call to sandbox=workspace-write made URL fetches work. Your Codex build may map the presets slightly differently, so try both before you blame the profile.

Bottom Line

The fix itself took 30 seconds. Getting to the right five lines was a bit of Claude Code and Codex trading hypotheses: reading Ubuntu’s userns spec, pulling the upstream profile for comparison, flipping the sysctl as a diagnostic, and verifying each success criterion one at a time. Same CC and Codex loop I use every day, just in need of some optimizing to get full functionality.

If you hit codex sandbox errors on your Ubuntu 24.04 box, it is definitely work a quick fix and I hope the fix lands on yours as fast as it did on mine. 👍 Also, if you have a better method or other tips, feel free to comment below!

Sources and Further Reading

• Ubuntu spec on unprivileged user namespace restrictions via AppArmor: Canonical’s rationale for the default restriction.
• Launchpad bug 2046844: AppArmor userns creation restrictions causing bwrap failures; where the community landed on the per-binary profile fix.
• Upstream bubblewrap issue #632: bwrap broke on Ubuntu 24.04 (tracking the same symptom).
• Upstream AppArmor bwrap-userns-restrict profile: the tighter two-profile design if you want more than a compatibility stub.

Sources cited against primary docs where possible. If something here does not match what you are seeing, drop a comment and I will update the post.