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

[gpuzio]

What version of the IDE extension are you using?

26.311.21342

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.17.0-19-generic x86_64 x86_64

What issue are you seeing?

Summary

After reinstalling the Codex VS Code extension, workspace-write no longer allows writes to the workspace inside a Linux devcontainer.

The workspace is writable outside the Codex sandbox, and Docker reports it as a normal RW bind mount, but inside the Codex sandbox writes fail with Permission denied.

This looks like a sandbox/runtime issue in the extension rather than a repo or filesystem permission problem.

Environment

• Codex VS Code extension: 26.311.21342
• Linux
• VS Code Remote Containers / devcontainer
• Container user: root

Expected behavior

With workspace-write, Codex should be able to write to the workspace path.

Actual behavior

Inside Codex:

• reading files in the workspace works
• writing to the workspace fails with Permission denied
• writing to /tmp works

Outside Codex sandbox:

• writing to the same workspace path works normally

Minimal repro

Inside a Codex session:

touch /workspaces/project/.sandbox-write-test


### What steps can reproduce the bug?


1. Open a Linux devcontainer in VS Code with the Codex extension enabled.
2. Start a Codex session using the default sandbox mode (`workspace-write`).
3. In the Codex session, try to write a file into the workspace, for example:

touch /workspaces/project/.sandbox-write-test

4. Observe that the write fails with:

touch: cannot touch '/workspaces/project/.sandbox-write-test': Permission denied

5. In the same environment, try writing to `/tmp`:

touch /tmp/.sandbox-write-test

6. Observe that writing to `/tmp` works.
7. Outside the Codex sandbox but inside the same container, writing to the workspace also works normally.

### What is the expected behavior?

What is the expected behavior?

Codex with `workspace-write` should be able to write to the workspace directory inside the devcontainer.

Additional information

This started after reinstalling the Codex VS Code extension.

Environment:
- Codex VS Code extension: `26.311.21342`
- Linux
- VS Code Remote Containers / devcontainer
- container user: `root`

What I verified:
- Reading files from the workspace works inside Codex.
- Writing to `/tmp` works inside Codex.
- Writing to the workspace fails only inside Codex sandbox.
- Outside Codex sandbox, the workspace is writable normally.
- Docker shows the workspace as a normal RW bind mount.
- Outside Codex sandbox, mount info also shows the workspace as RW.

Important diagnostic detail:
Inside the Codex sandbox, the workspace appears to be mounted twice on the same target:
- one mount is `ro`
- one mount is `rw`

Also, `.git` appears as a separate `ro` mount.

Outside the Codex sandbox, this duplicate `ro` + `rw` mount view does not appear. That suggests the incorrect mount layout is being introduced by the Codex sandbox layer rather than by Docker or the repository itself.

Additional repro:
Running the following also fails:

codex sandbox linux touch /workspaces/project/.manual-sandbox-test

with:

bwrap: loopback: Failed to create NETLINK_ROUTE socket: Operation not permitted


### Additional information


Suspected cause:
This looks like a regression in the Codex VS Code extension sandbox/runtime for Linux devcontainers, where the sandbox constructs an incorrect mount namespace for the workspace and effectively treats a writable workspace as read-only.

Possibly related issues:
- #4390
- #5034
- #5041

[github-actions]

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

• Allow writable gitdir for current worktree in sandboxed workspace-write mode #14338
• codex app-server tool commands run in read-only sandbox despite --dangerously-bypass-approvals-and-sandbox #14068

Powered by Codex Action

[ownEyes]

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.

[artin-kagun]

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!

[admroz]

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

[artin-kagun]

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!

[viyatb-oai]

@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.

[rentanything-nb]

@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.

[gpuzio]

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...