Hey, thanks for running the diagnostics to the end. The preflight output for both backends is really helpful, and it’s clearly more accurate than in the previous thread Terminal sandbox is incorrectly reported as unsupported on OrbStack Linux kernel 7.0.x (AppArmor suggestion is misleading).
I’ll go point by point:
Misleading AppArmor message. Like we agreed in the previous thread, this is a known issue we’re tracking. Right now that message shows up for any terminal sandbox preflight failure on kernel 6.2+ without actually checking AppArmor. We have a task to replace it with the real backend failure reason, no ETA yet. I’ll update this thread when there’s news.
The sandbox itself on OrbStack. Your new preflight confirms what we suspected. Both backends fail, Landlock with Landlock V3 filesystem restrictions not supported, and Bubblewrap at the seccomp step with Invalid argument, EINVAL. Terminal Sandbox on Linux relies on an unprivileged mount namespace plus a seccomp filter, and in the OrbStack VM those steps don’t work for an unprivileged process. This is an environment limitation, not a Cursor setting.
About Agent and extensions becoming unusable. When the sandbox is unavailable, Agent should still work by design. Commands should go through manual approval or an allowlist, not get fully blocked. A couple questions to understand what you’re seeing:
- Did you try the workaround from the previous thread, turning off terminal sandbox in Auto-Run settings? If yes, does Agent work over Remote SSH after that, or is it still broken?
- Which extensions stop working exactly, and what errors do you see?
Important detail: if Agent still doesn’t work over Remote SSH after disabling the sandbox, then this isn’t a sandbox preflight block. It’s a different scenario, likely at the extension host level. In that case the preflight output isn’t enough. Please send logs from the remote side from ~/.cursor-server/data/logs/ from a fresh session after you try to start Agent. Those logs will show whether the extension host starts at all.
One more diagnostic test. You mentioned bwrap --unshare-all ... works standalone. Can you run this exact command in the same VM and share the result?
bwrap --unshare-all --dev-bind / / true; echo "exit=$?"
This will help confirm whether the root cause is OrbStack itself or our bundled helper. That difference matters. On your question about an extra debug mode for cursorsandbox, I’ll check with the team and get back to you.
I get that this is a big blocker for a Remote SSH workflow. Let’s first separate the two cases, sandbox blocked vs extension host issue. That decides what we should dig into next.