The error means bubblewrap can't create an unprivileged user namespace, which requires CAP_SYS_ADMIN plus a permissive seccomp policy on the container Codex is running in — not just the host kernel setting. Nested sandboxing (a sandbox inside your sandbox) needs the outer container to explicitly grant that.

Multi-tenant container platforms typically withhold CAP_SYS_ADMIN from tenant containers specifically because nested user-namespace creation is a known container-escape vector; several real CVEs have chained through it. If Railway Sandbox does this (and the error pattern strongly suggests it does), it's very likely intentional isolation hardening, not a missing feature, and probably isn't something exposed as a per-sandbox config option, since loosening it would weaken Railway's own security boundary for every tenant.

Given that, the practical path likely isn't "configure bubblewrap to work"; it's recognizing that Railway Sandbox's own container boundary is your isolation layer, so running Codex without its own nested Linux sandbox (relying on the outer Railway Sandbox for isolation instead) is the intended pattern here, not a security downgrade.

Could someone from Railway confirm: (1) whether Sandbox containers grant CAP_SYS_ADMIN + the seccomp permissions Bubblewrap needs, by design or as an opt-in, and (2) whether Cloud Agents differ from Sandbox on this specific point?

Thank you for the explanation. We have not tried any further configuration changes, and the original issue remains unresolved. The disposable test sandbox and project were deleted after the failed check.

Our only confirmed diagnostic result is that codex sandbox linux --help returned:

bwrap: No permissions to create a new namespace, likely because the kernel does not allow non-privileged user namespaces.

We did not inspect the effective capabilities, seccomp policy, or AppArmor configuration, so the exact cause remains unverified.

Our requirement includes preventing agent-executed commands from accessing authentication credentials and controller data. Relying solely on the outer Railway boundary would require a design that also protects those resources from commands running inside it.

Could Railway confirm whether its Sandboxes support Codex's built-in bubblewrap sandbox without disabling its protections? If not, do Cloud Agents differ on this point, and what supported architecture would meet the separation requirement above?

Root cause: Codex's Linux sandbox needs bubblewrap to create an unprivileged user namespace. Inside any container (Railway Sandbox included), that requires the outer container to have been granted CAP_SYS_ADMIN plus a seccomp policy permitting unshare/clone(CLONE_NEWUSER not just a host kernel setting. Most multi-tenant container platforms deliberately withhold that capability from tenant containers, because nested user-namespace creation is a known container-escape vector. The error you're seeing is the expected symptom if Railway Sandbox does this, which is very likely.

Given your actual requirement isolating the agent's executed commands from credentials and controller data, not just isolating the Sandbox from the host here are the options, ranked by how directly they solve it:

1. Keep credentials out of the Sandbox's reach entirely (recommended). Don't try to nest a second security boundary inside one that shouldn't hold the secrets in the first place. Run the orchestrating process that holds Railway API tokens, deploy credentials, and controller access outside the Sandbox. Inject into the Sandbox only what the specific task needs: short-lived, narrowly-scoped tokens, or nothing at all if the task doesn't require them. The agent's commands then have nothing to exfiltrate regardless of whether Codex's internal sandbox is active inside the Sandbox. This meets your separation requirement without depending on a platform capability that may not exist here.

2. Split the architecture: run Codex outside the Sandbox, use the Sandbox as a disposable execution target. Run Codex itself (with its full environment and credentials) on infrastructure where unprivileged user namespaces work: a regular VM, a self-hosted runner, or any host where kernel.unprivileged_userns_clone=1 and you control the container's capabilities. Have it treat the Railway Sandbox purely as a throwaway, credential-free place to execute the specific commands it decides to run. The Sandbox does the job it's actually built for (isolating untrusted execution from your infrastructure and other tenants); credential protection happens one layer up, before anything reaches the Sandbox.

3. Ask Railway for a capability grant, if they offer one. Some platforms expose an opt-in flag that grants CAP_SYS_ADMIN + a looser seccomp profile to a specific sandbox at the cost of weakening its isolation from the host. If Railway has this, you could in principle get nested bwrap working but you'd be trading away part of the Sandbox's own security guarantee to gain Codex's, which is usually not a good trade. I'd only pursue this if options 1 and 2 are both infeasible for your setup.

4. Use Codex's own alternative isolation modes instead of its Linux sandbox. If Codex supports running with --sandbox read-only or an approval-gated mode rather than its full bwrap-based isolation, that shifts protection from "OS-level namespace isolation" to "the agent must ask before doing anything risky." Weaker than a true sandbox, but it doesn't depend on nested user namespaces at all, and may be enough combined with option 1.

One thing only Railway can confirm, quickly: does a Sandbox container get CAP_SYS_ADMIN and the seccomp permissions Bubblewrap needs, by default or as an opt-in, and does a Cloud Agent differ on this? That's a yes/no about their platform internals, not something I can verify from outside, but it's a fast question for their team and would settle whether option 3 is even on the table.

Railway sandboxes are VMs, not containers. The issue was caused by a bug in a VMs setup. It is fixed now and codex sandbox should work.