Default bubblewrap sandbox is incompatible with standard unprivileged Replit workspaces and similar restricted container environments

[bromdun]

What version of Codex CLI is running?

0.117.0 CLI (Also observed in 0.115.0+)

What subscription do you have?

Pro

Which model were you using?

gpt-5.4 xhigh

What platform is your computer?

Linux / Replit workspace

What terminal emulator and version are you using (if applicable)?

No response

What issue are you seeing?

This issue is separate from #15340 and the system-bwrap lookup fixes.

Even when bwrap is installed and available in the environment, Codex’s default bubblewrap sandbox backend appears incompatible with a standard unprivileged Replit workspace and likely other similar restricted remote/container environments.

Replit uses a Nix-managed environment, so binaries can be present and usable in the shell without living under /usr/bin. The lookup side of that is already being addressed elsewhere. The issue here is different: the default Codex Linux bubblewrap pipeline explicitly uses user/PID namespace isolation, and in this environment bwrap fails because it cannot create the required namespaces.

Running bwrap directly in Replit fails with an error along the lines of:

bwrap: No permissions to create new namespace, likely because the kernel does not allow non-privileged user namespaces

So even after system bwrap discovery is fixed, Codex still cannot use the default bubblewrap sandbox in this environment.

What steps can reproduce the bug?

1. Open a standard Replit workspace.
2. Install bubblewrap in the workspace environment.
3. Confirm that bwrap is available in the shell.
4. Run a Codex action that requires the Linux sandbox.
5. Observe that sandbox startup fails because bwrap cannot create the required namespaces.

What is the expected behavior?

Codex should do one of the following:

• detect at startup that the environment denies the namespace operations required by the default bubblewrap backend and surface a clear message,
• document Replit and similar restricted container environments as unsupported for the default bubblewrap sandbox, and/or
• suggest or automatically fall back to an alternative supported backend when available instead of presenting this as a missing-package problem.

Additional information

This seems to affect standard unprivileged remote/container workspaces where:

• packages are provided by the environment rather than installed into /usr/bin, and/or
• unprivileged user namespaces are unavailable.

In my case, older Codex behavior worked in this environment before the bubblewrap-based default became the active path. The regression is specifically with the current default bubblewrap sandbox backend, not with Codex in general.

A clearer startup error would help a lot here, because installing or locating bwrap inside the workspace does not resolve the underlying incompatibility when namespace creation itself is blocked.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• workspace-write sandbox fails in Flatpak VS Code with bwrap: No permissions to create a new namespace, while danger-full-access works #15678
• Linux sandbox fails on Ubuntu with AppArmor userns restrictions: bwrap loopback RTM_NEWADDR EPERM #15057
• bwrap namespace error when using apply_patch #15517
• bwrap: Failed RTM_NEWADDR: Operation not permitted #14919

Powered by Codex Action

[etraut-openai]

I think this is a duplicate of #15678.