I’m currently working with Cursor inside a Dev Container and ran into something I don’t fully understand.
On my setup, I noticed that the Auto-Run mode does not offer the “Auto-Run in Sandbox” option. Instead, I only see:
Ask Every Time
Use Allowlist
Run Everything
However, my colleagues do have the sandbox option available in the same context.
After some experimentation, I found that I can make the sandbox option appear by modifying my devcontainer.json and effectively disabling container security restrictions:
"securityOpt": ["seccomp=unconfined"]
Once I add this, the “Auto-Run in Sandbox” option becomes available again.
This raises a few questions:
Why is this setting required in my case, but not for my colleagues?
What exact condition determines whether the sandbox mode is available?
Is this related to the container running in privileged vs. unprivileged mode?
Are there host-level Docker settings or policies that could cause this difference, even if the devcontainer.json is identical?
From what I can tell:
Our devcontainer configurations are identical
My container seems to run unprivileged
A colleague’s container appears to be privileged (though not explicitly configured that way)
So it feels like there must be some external factor (Docker daemon config? platform differences? security profiles?) influencing this behavior.
I’d really appreciate any insight into:
how Cursor determines sandbox availability inside Dev Containers
and what the recommended/secure setup would be in this scenario
Additional Information
MacOs 26.4.1, M4
Using mcr.microsoft.com/devcontainers/base:ubuntu-24.04
You’ve basically figured this out yourself already. The sandbox on Linux works by creating user/mount namespaces (plus Landlock or Bubblewrap for filesystem isolation). When Cursor starts in a Dev Container, it runs a quick preflight test to see if that actually works. If the preflight fails, the sandbox option just doesn’t show up in the dropdown.
The problem is that Docker’s default seccomp profile blocks the syscalls needed to create those namespaces (clone, unshare). That’s why seccomp=unconfined fixes it (you’re removing those restrictions).
As for why your colleagues have it working with the same devcontainer.json, the most likely culprits are:
Different Docker Desktop version or settings
Different Docker daemon config on the host (custom seccomp profile, AppArmor settings, etc.)
Host kernel differences (the host’s user namespace policy carries into the container)
Worth comparing docker info output between your machines. The “Security Options” section should show if there’s a difference.
seccomp=unconfined works fine as a workaround. It’s broader than strictly necessary (it disables all syscall filtering, not just the namespace-related ones), but for a dev container that’s generally acceptable. If your team has stricter security requirements, you could also craft a custom seccomp profile that only allows the specific syscalls the sandbox needs.
I did some deeper investigation on my side and wanted to share my findings in case it helps others.
In the end, I compared the two container setups in detail and found the key difference:
On my colleague’s machine (where the sandbox option was available), the Dev Container is running with Docker-in-Docker (DinD) ("ghcr.io/devcontainers/features/docker-in-docker:2") enabled.
DinD significantly alters the effective security configuration of the container environment, which in turn allows Cursor’s sandbox mode to function properly. In my setup (without DinD), this was not the case.
As a quick test, I enabled the Docker-in-Docker feature in my Dev Container — and that immediately resolved the issue. The sandbox option became available and worked as expected.
That said, I’m not entirely comfortable relying on DinD as a workaround for this.
So I wanted to ask:
Would it be possible to provide a minimal seccomp profile (or documentation of required syscalls) that is sufficient for enabling the Cursor sandbox inside a Dev Container?
Having a more fine-grained and controlled setup (instead of fully disabling seccomp or relying on DinD) would be extremely helpful, especially for teams working in regulated environments.