VS Code Codex extension sandbox makes writable devcontainer workspace appear read-only in Linux

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

• #14338
• #14068

Powered by Codex Action

I encountered this problem as well after updating the Codex VS Code extension to 26.311.21342 and running a container in VS Code with the Codex extension enabled.

Even a plain sandboxed ``pwd`` immediately failed with:

``bwrap: No permissions to create a new namespace``

After rolling back to 26.304.20706, the sandbox worked again. Updating back to ``openai.chatgpt-26.311.21342-linux-x64`` reintroduced the sandbox failure.

I am experiencing the exact same issue. Thank you for summarizing the problem so clearly!

To add some context regarding different environments, I am running this on Windows using WSL and a devcontainer, and I am encountering the exact same Permission denied error.

I can confirm that this problem still persists in the current latest version (26.313.41514).

Like the original poster, I am currently working around the issue by rolling back the extension to version 26.304.20706. While this temporary fix works, it is quite inconvenient not being able to use the newest features.

Hoping for a quick fix!

I have similar problem, my setup is Windows VSCode + Dev Containers, my container is Ubuntu 24.04, Docker Desktop on Windows integrated with WSL.

I verified with different older Codex extensions in VSCode.

• 0.4.79 (3 wks ago) looks to be working correctly, which is temporary solution
• 26.304.20706 (2 wks ago) has broken network sandbox, but file editions still work
• 26.311.21342 (1 wk ago) sandbox issue with both network and file edition

I managed to find a solution to this issue!

It turns out the root cause is that the default bubblewrap package provided by apt in standard devcontainers (which are usually Debian/Ubuntu-based) is too old (e.g., v0.8.x). The newer versions of the Codex extension's sandbox seem to require the latest bwrap features (like the --argv0 option and updated namespace handling). When it uses the older version, it fails under the hood, resulting in these weird read-only mount behaviors and Permission denied errors.

Manually compiling and installing the latest version of bubblewrap (v0.11.0) directly from the source completely fixed the workspace write and permission issues for me.

Here is the script to update it. You can run this directly in your devcontainer terminal, or add it to your setup.sh / postCreateCommand to make it persistent:

# 1. Remove the old version of bubblewrap if it is installed
sudo apt-get remove -y bubblewrap

# 2. Install the necessary build dependencies
sudo apt-get update
sudo apt-get install -y git meson ninja-build libcap-dev gcc pkg-config

# 3. Clone, build, and install the latest bubblewrap from the source
git clone https://github.com/containers/bubblewrap.git /tmp/bubblewrap
cd /tmp/bubblewrap
meson setup builddir
meson compile -C builddir
sudo meson install -C builddir

# 4. Clean up the source files to save space
rm -rf /tmp/bubblewrap

After doing this, you no longer need to roll back to the older extension version. Everything works perfectly on the latest release. Hope this helps anyone else stuck on this!

Quick update to my previous comment:

While updating bubblewrap to v0.11.0 successfully restores general file write permissions in the workspace, I realized it is only a partial workaround.

It turns out that Git operations (like git commit) inside the Codex sandbox still fail with the following error:
fatal: Unable to create '/workspace/.git/index.lock': Read-only file system

As noted in the original issue description, the sandbox appears to intentionally mount the .git directory as a separate ro (read-only) mount. Updating bubblewrap fixes the normal file editing, but it does not override this specific read-only restriction on the .git folder.

So, if you rely on Codex to autonomously commit changes, this workaround won't be enough. We still need a proper fix from the extension team to handle the .git mount correctly. I will continue using this workaround for coding, but just wanted to clarify that the Git issue remains!

@artin-kagun thanks for investigating here! This change just brings the linux sandbox behavior in line with macOS where writes to .git are not allowed even in workspace-write mode. Landlock lacks the ability to make files/directories read-only within a writable directory which is why this was possible before.

@viyatb-oai How is that a helpful response? writes to .git need to be allowed. Running git commands as part of a workflow is standard and necessary. This makes CODEX unusable.
issue exists on Windows as well, for the record.

Any updates on this?

I’ve recently run into new issues with excessive token usage for very simple tasks — in one case, the entire 5-hour limit was consumed with a poor result. It looks like this might be caused by some kind of retry loop.

I’m still using version 26.304.20706 due to the devcontainer issue, but I’m wondering if this retry-loop behavior has been addressed in the latest version of the extension.

If this isn’t resolved, I don’t really see another option than switching to another provider...

I tried @artin-kagun 's workaround (macOS), but funnily enough now Codex complains about "tripping over the broken sandbox filesystem" and offers to run commands outside of it. 🤭 So, let's find something else, shall we?