Regression in 0.115.0: shell commands fail in WSL due to bubblewrap namespace setup

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

• #16018
• #15678
• #14976

Powered by Codex Action

This looks very closely related to #15678.

My repro is on WSL rather than Flatpak/Replit, but the underlying issue appears to be the same: the newer default
bubblewrap sandbox path fails when the required namespace setup is unavailable.

For reference:

• 0.114.0: works
• 0.115.0+: fails

WSL error:

`bwrap: Creating new namespace failed, likely because the kernel does not support user namespaces.
bwrap must be installed setuid on such systems.`

Leaving this to maintainer judgment in case the WSL-specific repro is still useful.

The issue was caused by the Dev Container running without the required bubblewrap binary and without user namespace support exposed to the container, which prevented Codex from starting its internal sandbox. In that state, Codex showed this warning:

Codex could not find system bubblewrap at /usr/bin/bwrap. Please install bubblewrap with your package manager. Codex will use the vendored bubblewrap in the meantime.

and also failed to modify files or apply patches.

After debugging, the key findings were:

• Before rebuilding the container:
• which bwrap returned nothing
• bwrap --version failed with command not found
• unshare -U true failed with Operation not permitted
• This showed that:
• system bubblewrap was not available in the running container
• unprivileged user namespaces were not usable inside the container
• The repository config itself was already correct, but the running container had not actually picked it up yet

The fix was:

1. Install bubblewrap in the Dev Container image.
2. Run the container with relaxed security settings so bubblewrap can create namespaces.
3. Rebuild the Dev Container so the new config actually takes effect.

Example working configuration:

Dockerfile

RUN apt-get update && apt-get install -y bubblewrap

devcontainer.json

{
  "runArgs": [
    "--security-opt=seccomp=unconfined",
    "--security-opt=apparmor=unconfined",
    "--cap-add=SYS_ADMIN"
  ]
}

After rebuilding the container, these checks succeeded:

which bwrap
bwrap --version
cat /proc/sys/user/max_user_namespaces
unshare -U true

Results:

• which bwrap -> /usr/bin/bwrap
• bwrap --version -> bubblewrap 0.11.0
• cat /proc/sys/user/max_user_namespaces -> 31141
• unshare -U true -> success

At that point Codex sandboxing started working normally again, and file edits / patch application worked.

One additional note: if the warning still appears after the container is fixed, it may just be a stale Codex session. Restarting the Codex session or reloading the VS Code window resolves that.

I am seeing the same issue in 0.115.0 to at least 0.118.0, a regression compared to 0.114.0. WSL2 ubuntu with either image standard or recompiled latest bwrap from git. The procedure in the comment above does not fix the issue, although I'm not further degrading any container security settings to fix a codex regression.

Could you please provide the output of the following four commands from inside the dev container?

which bwrap
bwrap --version
cat /proc/sys/user/max_user_namespaces
unshare -U true

My environment (WSL1):

> which bwrap
/bin/bwrap
> bwrap --version
bubblewrap 0.6.1
> cat /proc/sys/user/max_user_namespaces
cat: /proc/sys/user/max_user_namespaces: No such file or directory
> unshare -U true
unshare: unshare failed: Invalid argument

My environment (WSL1): `` > which bwrap /bin/bwrap > bwrap --version bubblewrap 0.6.1 > cat /proc/sys/user/max_user_namespaces cat: /proc/sys/user/max_user_namespaces: No such file or directory > unshare -U true unshare: unshare failed: Invalid argument ``

Based on my research, Codex has started using bubblewrap since version 0.116. The minimum required version for bubblewrap is 0.10.x. The failure occurs because your container environment has disabled the user namespace feature, rendering bubblewrap ineffective.

Thanks. I think there are two separate questions here:

1. Current requirements:

I understand that recent Codex versions require bubblewrap >= 0.10.x and usable user namespaces, which WSL1 does not provide.

1. Regression behavior:

My point is that codex-cli 0.114.0 worked in WSL1, while 0.115.0+ stopped working. So even if WSL1 is no longer considered a supported environment, this still looks like a regression in compatibility or a change in runtime requirements between releases.

If WSL1 is now intentionally unsupported, could you clarify that explicitly?
If so, it would help to document:

• the minimum required bubblewrap version
• the requirement for user namespace support
• the fact that WSL1 is unsupported
• from which codex-cli version this became true

Also, my local testing showed 0.114.0 works and 0.115.0 already fails, so the effective regression boundary seems to be 0.115.0 rather than 0.116.

Thanks. I think there are two separate questions here: 1. Current requirements: I understand that recent Codex versions require bubblewrap >= 0.10.x and usable user namespaces, which WSL1 does not provide. 2. Regression behavior: My point is that codex-cli 0.114.0 worked in WSL1, while 0.115.0+ stopped working. So even if WSL1 is no longer considered a supported environment, this still looks like a regression in compatibility or a change in runtime requirements between releases. If WSL1 is now intentionally unsupported, could you clarify that explicitly? If so, it would help to document: the minimum required bubblewrap version the requirement for user namespace support the fact that WSL1 is unsupported from which codex-cli version this became true Also, my local testing showed 0.114.0 works and 0.115.0 already fails, so the effective regression boundary seems to be 0.115.0 rather than 0.116.

Apologies for the confusion! I want to clarify right away that I am not a Codex developer, just a regular user like you.

I ran into a similar problem and managed to track down the cause and successfully bypass it on my end. I found the information about the bubblewrap and user namespace requirements through some online searching, specifically in this Reddit thread.

Your points about the exact regression boundary being 0.115.0, officially documenting the drop of WSL1 support, and updating the runtime requirements are completely valid. we will have to wait for the maintainers/developers to chime in, clarify their official stance on WSL1, and handle those documentation updates.

hey @k-talo! With codex linux sandbox migrating to bubblewrap, we will be dropping support for WSL1 going forward. I'm going to make the error message better and will update the docs with the next mainline release.

Thanks for the clarification in this PR — making the unsupported status explicit is definitely an improvement over failing later with a raw bwrap error.

That said, I’d like to raise a design concern regarding WSL1 support.

It seems that the current assumption is effectively:

• WSL1 = legacy / unsupported Linux
• WSL2 = the intended Linux environment

However, WSL1 is not just an “older WSL2”, but a fundamentally different environment with its own valid use cases. In particular, some users intentionally choose WSL1 because it integrates more tightly with the Windows filesystem and has different performance characteristics compared to WSL2.

The issue here is not that WSL1 is “broken”, but that bubblewrap relies on kernel features (e.g. user namespaces) that WSL1 does not implement and likely never will.

Given that, the current behavior:

• making bwrap mandatory
• and treating WSL1 as unsupported

effectively removes a previously working setup without offering an alternative path.

So I’d like to suggest considering a fallback strategy for environments where bwrap is not available, such as:

• falling back to a non-sandboxed mode (with explicit warnings)
• or providing an alternative, lighter-weight sandbox mechanism
• or allowing users to opt out of bwrap via configuration

Even a clearly marked “degraded / unsafe mode” would be preferable to a hard failure, especially for users who understand the trade-offs.

In short, the problem is not WSL1 itself, but the lack of a non-bwrap execution path.

I believe restoring some form of fallback would significantly improve usability without compromising the default security model.

Thanks again for the work on improving error handling — I hope this perspective is helpful.

Hey @k-talo, thanks for the feedback! unfortunately we won't be supporting WSL1 - you can use the native Windows sandbox if you need to in place of WSL/linux sandbox.