This morning I updated Codex to v0.156.1, asked it to edit a local file and got this instead:
bwrap: setting up uid map: Permission deniedHuh. Not convenient when I just wanted to get things done.
The error suggests that bwrap, the Bubblewrap executable, which Codex uses for its sandbox on Linux, has a permission problem.
A sandbox is an isolated environment that restricts what a program can access or modify. It allows potentially risky code (like codex) to run, while limiting its ability to affect the rest of the system. It usually does this by restricting access to files, network resources or other processes.
Not being overly familiar with Linux sandboxes, I did a bit of research and found that this is not an issue unique to running codex, but can affect any process using Bubblewrap.
Bubblewrap (bwrap) is a lightweight sandboxing tool. It uses namespaces and filesystem bindings to give a process a restricted view of the system, allowing selected files and directories to be made read-only, writable or inaccessible without requiring a full virtual machine or container.
As the name implies, Bubblewrap wraps the child process in a sandbox environment. It creates the sandbox, but the Linux kernel enforces isolation of the processes running inside the sandbox.
AppArmor is a kernel-level Linux security system that restricts what applications are allowed to do. It applies per-application security profiles that can limit access to files, devices, network operations and other system resources, helping contain the damage if a program is compromised or behaves unexpectedly. AppArmor is not dependent on Bubblewrap and can apply a security profile to any process, regardless of whether it’s running in a sandbox.
Codex made Bubblewrap the default Linux sandbox in v0.115.0, released on 16 March 2026. I first saw the error after updating to v0.156.1. I’m not sure why it only surfaced on my machine today. For reference, I’m running Ubuntu 24.04.5 LTS with AppArmor v4.0.1.
Why Bubblewrap Couldn’t Start
Ubuntu 24.04 restricts unprivileged user namespaces through AppArmor. Bubblewrap needs a user namespace to construct a sandbox. If AppArmor doesn’t allow the bwrap executable to create it, then the sandbox fails before Codex can run any commands. I found a solution here.
Check where bwrap is installed and find its version.
which bwrap/usr/bin/bwrapbwrap --versionbubblewrap 0.9.0Check that this is the bwrap executable that’s being invoked by Codex by running command -v bwrap in a codex session. You should see the same path.
Codex’s sandbox documentation says it uses bwrap or falls back to a bundled helper. The solution presented below won’t work with the bundled helper.
Allow Bubblewrap to Create a Namespace
The most likely source of the problem is a missing Bubblewrap profile. Check if you have a /etc/apparmor.d/bwrap or /etc/apparmor.d/bwrap-userns-restrict. It’s quite likely that you don’t.
I’m assuming that you didn’t find a file in either location? Good, then it should be easy to fix. Create a file at /etc/apparmor.d/bwrap with the following content:
abi <abi/4.0>,
include <tunables/global>
profile bwrap /usr/bin/bwrap flags=(unconfined) {
userns,
include if exists <local/bwrap>
}That’s an AppArmor profile for bwrap. The userns rule lets bwrap create a user namespace. The unconfined flag leaves Bubblewrap’s other operations unrestricted. The include directive allows you to set up site-specific additions and overrides in a flexible way. We won’t be doing that, but it’s worthwhile setting it up anyway. This file will not impact AppArmor’s namespace restriction for anything except bwrap.
Restart AppArmor to apply those changes.
sudo systemctl reload apparmorRestart Codex. The problem should be resolved. If not, let me know. I’ll investigate other solutions.