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 = false

What 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_