workspace-write sandbox fails in Flatpak VS Code with bwrap: No permissions to create a new namespace, while danger-full-access works
What version of the IDE extension are you using?
26.323.20928
What subscription do you have?
expensive
Which IDE are you using?
VS Code
What platform is your computer?
Linux 6.17.7-ba28.fc43.x86_64 x86_64 unknown
What issue are you seeing?
I’m using the Codex VS Code extension inside Flatpak VS Code (com.visualstudio.code). In my environment, sandbox_mode = "workspace-write" with approval_policy = "never" does not provide usable workspace-bounded autonomy. Routine shell commands inside the current project, such as sed -n '1,20p' file or rg --files, fail immediately with bwrap: No permissions to create a new namespace. However, switching to danger-full-access makes the exact same commands work immediately. This strongly suggests the failure is specific to the workspace-write sandbox backend rather than project access, VS Code permissions, or shell execution in general.
Environment details: Flatpak VS Code has features=devel, filesystems=host, and flatpak run --command=sh --devel com.visualstudio.code works. The host also reports large positive values for /proc/sys/user/max_user_namespaces and /proc/sys/user/max_mnt_namespaces, so this does not appear to be a simple host-wide “user namespaces disabled” case. My config.toml is:
personality = "pragmatic"
model = "gpt-5.4"
model_reasoning_effort = "medium"
sandbox_mode = "workspace-write"
approval_policy = "never"
allow_login_shell = false
[sandbox_workspace_write]
network_access = falseWhat steps can reproduce the bug?
Under workspace-write, run sed -n '1,20p' test.py or rg --files; both fail with the bwrap namespace error. Under danger-full-access, both succeed immediately.
Expected behavior: workspace-write should allow normal read/write/command execution inside the workspace without requiring a failing nested sandbox path, especially when the documented config is used for no-prompt local work.
What is the expected behavior?
The workspace sandbox is effectively unusable, forcing a choice between broken local autonomy and fully unrestricted access.
Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I’m seeing what looks like the same underlying class of failure in Replit, even though my original issue (#15340) was about system bwrap discovery.
In my case, there are really two separate problems:
Discovery/path issue — Codex not finding bwrap correctly in Nix-style environments where it is available in the shell but not under /usr/bin (that’s what my #15340 was about).
Runtime/sandbox issue — even when bwrap is installed and visible in the environment, a standard unprivileged Replit workspace still fails because the bubblewrap-based sandbox path cannot create the required namespaces.
That seems very similar to what this issue shows in Flatpak VS Code: workspace-write fails specifically at the bwrap namespace step, while the less-restricted mode works.
So I think this may be broader than just Replit or just Flatpak. It looks like a class of restricted / nested Linux environments where Codex’s default bubblewrap sandbox backend is not viable, even when Codex itself and ordinary shell commands otherwise work.
From the Replit side, this means fixing bwrap lookup alone would not fully solve the problem there. It would be helpful if Codex treated this as a distinct compatibility issue for restricted containerized environments and either:
detected the namespace restriction early and surfaced a clearer message, or
suggested / used an alternative supported sandbox path when available.
Adding my environment to the pile here in case it helps confirm that this is not an isolated Flatpak-specific case.
I am encountering the same issue, which happens under Fedora with Flatpak.
bwrapis able to run under host terminal, but not inside the flatpak terminal. This results in Codex basically unable to do anything:Codex CLI has the same issue. Is there any plan to fix it?