Critical: Terminal Sandbox fails on OrbStack VMs, breaking Agent and Remote SSH workflow

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

This issue is a follow-up to the investigation on the Cursor forum:

The forum discussion confirmed that the AppArmor message is misleading, but after extensive debugging the underlying issue remains unresolved. This GitHub issue summarizes the technical findings and focuses on the actual impact.
I’m reporting this as a critical issue because Cursor has become unusable for my Remote SSH development workflow.
Terminal Sandbox consistently fails inside OrbStack VMs. As a result, Agent does not work correctly, extensions fail to function properly, and my normal development workflow is completely blocked.
I spent many hours debugging this together with Cursor support. We verified AppArmor, namespaces, Landlock, Bubblewrap, kernel configuration, PATH, Cursor Server installation, and tested multiple Ubuntu versions. The issue remains fully reproducible.
The exact same OrbStack VMs work correctly with Antigravity IDE and OpenCode. Cursor also works perfectly on macOS itself. The problem only appears when using Cursor through Remote SSH into an OrbStack VM.

Steps to Reproduce

Install Cursor 3.14.27 on macOS.
Create an Ubuntu VM in OrbStack 2.2.2.
Connect to the VM using Remote SSH.
Open an Agent terminal or use Agent features.
Cursor reports:
Terminal sandbox could not start.
This may be caused by an AppArmor configuration on your Linux system (kernel 6.2+).
Agent functionality becomes unusable and extensions no longer function correctly.

The issue is reproducible on both:

  • Ubuntu 22.04
  • Ubuntu 26.04

Expected Behavior

Cursor should successfully initialize Terminal Sandbox on OrbStack, or clearly report the actual reason why sandbox initialization failed.
Even if Terminal Sandbox cannot be enabled, Remote SSH development should remain fully functional. Agent functionality and extensions should continue working instead of becoming unusable.

Operating System

Linux

Version Information

Host
macOS 26.6 (Apple Silicon)

OrbStack
Version 2.2.2 (20903)

Cursor IDE
Version: 3.14.27
VS Code Extension API: 1.128.0
Commit: 047548b00c1a079373d74d00183f32510a4a41e0
Date: 2026-08-04T03:29:11.183Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Guest operating systems tested:
Ubuntu 22.04
Ubuntu 26.04

Kernel:
Linux 7.0.14-orbstack

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

The following has been verified during debugging:
AppArmor is not installed.
CONFIG_NAMESPACES=y
CONFIG_USER_NS=y
CONFIG_SECCOMP=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECURITY_LANDLOCK=y
CONFIG_BPF_LSM=y
Landlock is active (landlock: Up and running).
Active LSMs: capability,landlock,yama,bpf.
Bubblewrap is installed and functional.
Ubuntu 22.04 uses Bubblewrap 0.6.1.
Ubuntu 26.04 uses Bubblewrap 0.11.1.
User namespaces work correctly.
unshare --mount fails for unprivileged users but succeeds with sudo.
Cursor Server was completely removed and reinstalled.
Cursor caches were cleared and rebuilt.
The issue remains fully reproducible after a clean installation.

I also verified that the exact same OrbStack VMs work correctly with:

  • Antigravity IDE 2.1.1
  • OpenCode 1.18.14

Both IDEs provide fully functional agent workflows on the same machines. Only Cursor fails.
I appreciate the time the Cursor team has already spent investigating this issue, but it has now become a critical blocker for my daily work.
At this point I have exhausted all reasonable troubleshooting steps that I can perform as an end user.
If there is a diagnostic build, additional logging, or an experimental flag that could help identify the root cause, I would be happy to test it and provide feedback.
However, if this issue cannot be resolved, I unfortunately won’t have a practical choice other than moving away from Cursor for my Remote SSH development workflow, because Agent functionality and extensions are essential for my daily work.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Additional investigation results

I continued investigating this outside of Cursor and gathered some additional data.

cursorsandbox

The bundled helper is available at:

~/.cursor-server/bin/linux-x64/<commit>/resources/helpers/cursorsandbox

It is a statically linked ELF executable.

Running --help shows that it supports a dedicated preflight mode:

--preflight-only
Only perform sandbox preflight (no exec); exits 0 on success, 2 if unsupported

Manual preflight

Using a minimal policy:

cursorsandbox \
  --policy ~/policy.json \
  --preflight-only \
  -- /bin/true

returns:

Failed to resolve Linux sandbox backend:

Landlock error:
Landlock V3 filesystem restrictions not supported.
Error: fully incompatible access-rights:
BitFlags<AccessFs>(
    WriteFile |
    RemoveDir |
    RemoveFile |
    MakeChar |
    MakeDir |
    MakeReg |
    MakeSock |
    MakeFifo |
    MakeBlock |
    MakeSym |
    Refer |
    Truncate
)

Bubblewrap error:
Bubblewrap preflight failed with exit code Some(1):

Failed to run Linux inner sandbox stage:
Failed to apply seccomp:
Bubblewrap inner dangerous syscall seccomp failed:
Error calling `seccomp`:
Invalid argument (os error 22)

The command exits with status:

2

This means both Linux backends fail during preflight:

  • Landlock backend
  • Bubblewrap backend

which results in:

Linux auto backend selection failed

Environment verification

Verified:

  • AppArmor is not present.
  • Bubblewrap is installed.
  • Bubblewrap executes successfully.
  • bwrap --unshare-all ... works.
  • User namespaces work.
  • CONFIG_SECCOMP=y
  • CONFIG_SECCOMP_FILTER=y
  • CONFIG_SECURITY_LANDLOCK=y
  • landlock appears in the active LSM list.
  • Kernel reports:
landlock: Up and running.

Comparison

Exactly the same environment:

  • same OrbStack VM
  • same kernel
  • same SSH connection
  • same user

works correctly with:

  • Antigravity IDE
  • OpenCode

Only Cursor fails because the terminal sandbox preflight rejects both available Linux backends.

Question

Is there any additional debug mode, environment variable, or diagnostic build for cursorsandbox that can expose:

  • which exact Landlock capability check fails;
  • which seccomp filter causes EINVAL;
  • why both backends are considered unsupported on this environment?

I can run additional diagnostics if needed.

6

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:

  1. 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?
  2. 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.

7

Thanks for the follow-up.

I ran the requested Bubblewrap test in the same OrbStack VM:

$ bwrap --unshare-all --dev-bind / / true
$ echo "exit=$?"
exit=0

So Bubblewrap itself is able to create an unprivileged sandbox successfully in this environment.

This seems inconsistent with the statement that OrbStack does not support the required unprivileged mount namespace for an unprivileged process.

At the same time, cursorsandbox --preflight-only still reports:

  • Landlock backend rejected (Landlock V3 filesystem restrictions not supported)

  • Bubblewrap backend rejected during the seccomp stage (Error calling seccomp: Invalid argument (EINVAL))

Based on these results, it looks like the failure is not simply “Bubblewrap cannot create an unprivileged sandbox” because the standalone Bubblewrap test succeeds.

Could you clarify which specific syscall or preflight step leads to the conclusion that this is an OrbStack limitation?

If there is a particular namespace operation, mount operation, or seccomp rule that cursorsandbox expects but OrbStack does not support, I’d be happy to test that directly.

I’ll also test the Remote SSH workflow with Terminal Sandbox disabled and provide fresh logs from ~/.cursor-server/data/logs/ as requested.

чт, 6 авг. 2026 г. в 15:38, Dean Rie <[email protected]>:

8

Thanks, this result is exactly what we needed to unblock this.

bwrap --unshare-all --dev-bind / / true → exit=0 is important. It means unprivileged user namespace and mount namespace work in your OrbStack VM. So my wording from the previous thread that OrbStack doesn’t support the required unprivileged mount namespace was inaccurate for your case, and I’m correcting it.

Here’s what your data points to:

  1. Bubblewrap backend. Standalone bwrap works, but cursorsandbox fails specifically when it tries to apply our internal seccomp filter inner dangerous syscall seccomp failed: EINVAL. The difference between the two runs is the extra seccomp policy our helper adds on top of bwrap. So the bottleneck is not namespace operations. It’s that the seccomp() call with our filter returns EINVAL on kernel 7.0.x. This doesn’t look like an OrbStack limitation anymore. It looks like our filter is incompatible with that kernel, and I’m taking it to the team. I can’t give an ETA yet, but I’ll reply in the thread.

  2. Landlock backend. This is a separate, independent issue: Landlock V3 filesystem restrictions not supported. The OrbStack kernel doesn’t support the required Landlock ABI, so this backend won’t work there even if we fix Bubblewrap.

On your direct request about which syscall or step leads to the conclusion: it’s the step where we install our seccomp BPF filter seccomp() -> EINVAL. Since standalone bwrap works without this filter, we need to isolate the specific rule. That’s on our side. There’s currently no flag you can use to disable or tweak it yourself.

Now the second part, to avoid mixing two different cases. Terminal Sandbox won’t come up on this kernel right now, but the Agent should not fail because of that. If sandbox is unavailable, commands should fall back to manual approval. So please help confirm two things:

  1. Turn off terminal sandbox in Auto-Run settings, then check if the Agent works over Remote SSH after that.
  2. If the Agent still doesn’t work, then it’s likely not the sandbox preflight. It’s more likely the extension host. Please share logs from the remote side at ~/.cursor-server/data/logs/ from a fresh session right after you try to start the Agent, plus the exact extension names and their errors.

About the misleading AppArmor message: as we discussed, this is a known issue we’re tracking. The message shows for any preflight failure on kernel 6.2+ without actually checking AppArmor. We’ll replace it with the real cause, but there’s no ETA yet.

9

I checked Cursor 3.14.27, but I couldn’t find the Terminal Sandbox setting you mentioned.

I looked through the current Agents settings (including Run Mode, Allowlist Options, Legacy Terminal Tool, etc.), as well as VS Code settings, but there doesn’t appear to be any option to disable Terminal Sandbox anymore.

Could you point me to the exact setting or tell me if it has been removed in recent versions?

I’m happy to test Agent with Terminal Sandbox disabled, but at the moment I don’t have a way to disable it in the current release.

чт, 6 авг. 2026 г. в 16:12, Dean Rie <[email protected]>:

10

I also received confirmation from OrbStack support regarding the namespace behavior.

They tested the same operations on several standard Linux systems and reproduced the exact same behavior:

unshare --user --map-root-user id

→ works

unshare --mount id

→ Operation not permitted

sudo unshare --mount id

→ works

unshare --user --map-root-user --mount id

→ works

OrbStack explicitly confirmed that Linux requires a user namespace for an unprivileged mount namespace, and that OrbStack supports both unprivileged user namespaces and mount namespaces inside unprivileged user namespaces.

This is also consistent with my direct Bubblewrap test:

bwrap --unshare-all --dev-bind / / true

echo “exit=$?”

Result:

exit=0

So the namespace capability itself is not the issue.

At this point the remaining Cursor-specific failure is the additional seccomp policy applied by cursorsandbox:

Bubblewrap inner dangerous syscall seccomp failed:

Error calling `seccomp`:

Invalid argument (os error 22)

11

Thanks for sharing the info from OrbStack support and for taking the debugging all the way to the end. That closes the namespace question.

The root cause matches what we saw in post #8. An unprivileged user plus mount namespace in your OrbStack VM works (bwrap --unshare-all --dev-bind / / true → exit=0, and OrbStack confirmed it). So the issue isn’t namespaces. It’s an extra seccomp filter that cursorsandbox adds on top of bwrap. The seccomp() call returns EINVAL on kernel 7.0.x. That’s on our side, I’ve passed it to the team. I can’t share an ETA yet, I’ll update the thread when I have news. The Landlock backend also isn’t available on this kernel (missing the required Landlock ABI), so we can’t rely on that either.

About post #9 and why you can’t find the setting to disable Terminal Sandbox. The “Auto-Run in Sandbox” toggle in Cursor Settings > Agents only shows up when the sandbox preflight passes. Yours fails, so the option is hidden, and that’s expected. You don’t need to separately disable sandbox. In this state, Agent commands should go through manual approval instead of being fully blocked.

So let’s check one thing. In Run Mode, set a mode where commands require confirmation (not Auto-Run), then try using Agent over Remote SSH. Does it work that way?

If Agent still doesn’t work after that, then it’s probably not the sandbox preflight. It’s more likely the extension host, and that’s a separate case. If so, please send:

  • Logs from the remote side in ~/.cursor-server/data/logs/ from a fresh session right after you try to start Agent
  • The exact extension names that don’t work, and their errors

This will help us separate the two cases, sandbox vs extension host, and figure out where to dig next.

12

The latest Cursor Network Diagnostics strongly confirms that this is NOT a network/connectivity problem.

Network services are working:

DNS: Success
HTTP/2: Success or HTTP1/1: Success
SSL: Success
API: Success
Ping: Success
Chat: Success
Agent: Success
Marketplace: Success
Authentication: Success

The Agent endpoint itself successfully responds:

Agent: Success
Starting stream
Pushing first message
Response: ‘foo’
…
Result: true

However, three UI-level checks fail with the exact same error:

Authentication UI: Timeout waiting for EverythingProvider
Cursor Tab: Timeout waiting for EverythingProvider
Agent Endpoint: Timeout waiting for EverythingProvider

This strongly points to a broken/unresponsive local or Remote Extension Host / EverythingProvider rather than a Cursor API or network problem.

This also matches the remote Extension Host logs I previously provided.

The Remote Extension Host repeatedly crashes with:

TypeError: Converting circular structure to JSON
→ starting at object with constructor ‘Object’
— property ‘issuerCertificate’ closes the circle
at JSON.stringify
at serializeRequestArguments

followed by:

Extension Host Process exited with code: 7

The Extension Host is then repeatedly restarted.

There is also this TLS error immediately before the crash:

Hostname/IP does not match certificate’s altnames:
Host: mobile.events.data.microsoft.com
is not in the cert’s altnames:
DNS:basis.orb.local, IP Address:192.168.139.175

Therefore the current problem appears to be:

Cursor Network/API: WORKING
Agent Endpoint: WORKING
Remote Extension Host / EverythingProvider: NOT WORKING

Please investigate the EverythingProvider timeout and the Remote Extension Host crash separately from the network diagnostics and sandbox/seccomp issue.

сб, 8 авг. 2026 г. в 11:38, Dean Rie <[email protected]>:

13

Great diagnosis. Post #12 basically puts everything in the right place. This is exactly the second case we were trying to separate. It’s not sandbox preflight, it’s the Remote Extension Host. Network and the Agent endpoint work, and Timeout waiting for EverythingProvider is a symptom, not the cause.

The cause is the Extension Host crash loop you found:

TypeError: Converting circular structure to JSON
--- property 'issuerCertificate' closes the circle
... at serializeRequestArguments
Extension Host Process exited with code: 7

Same mechanics as in the previous thread about issuerCertificate: Remote SSH: Extension Host crashes with TypeError: Converting circular structure to JSON (issuerCertificate). Right before the crash, the logs show a TLS error:

Host: mobile.events.data.microsoft.com is not in the cert's altnames:
DNS:basis.orb.local, IP Address:192.168.139.175

So inside the OrbStack VM, a request to Microsoft’s telemetry endpoint mobile.events.data.microsoft.com resolves via DNS to a local OrbStack address and certificate basis.orb.local. The cert altnames don’t match, TLS verification fails, and Node attaches the full certificate chain to the error. That chain references itself via issuerCertificate. When serializeRequestArguments tries to serialize it, the whole Extension Host crashes, restarts in a loop, and EverythingProvider never gets a chance to come up. That’s why Auth UI, Tab, and Agent time out.

What to try right now to unblock yourself is to remove the trigger, the request to MS telemetry:

  1. On the remote side in Remote settings, set telemetry.telemetryLevel to off, then reconnect. This should remove the HTTPS requests to mobile.events.data.microsoft.com that hit the TLS failure.
  2. If that doesn’t help, also enable Disable HTTP/2 Settings → search for HTTP/2, then reconnect again.

If after telemetry off the Extension Host stops crashing and Agent and extensions come back, that confirms this is specifically about that external request, not something in your config.

On our side, a single failed TLS request taking down the whole remote Extension Host should not happen. The full stack serializeRequestArguments is exactly what we were missing, I’ve shared it with the team. I can’t give an ETA yet, I’ll post in the thread when there’s an update.

On sandbox and seccomp seccomp() → EINVAL on kernel 7.0.x, no change since post #8 and #11. That’s on our side, no ETA. But based on your data, it’s separate from the current blocker. Agent should work even without sandbox.

Let me know how telemetry off goes.

14

Telemetry OFF did NOT fix the issue.
I tested exactly as requested:

  • “telemetry.telemetryLevel”: “off”
  • HTTP/1.1 instead of HTTP/2
  • Reconnected to the Remote SSH host
  • Tried Agent again

The Cursor Network Diagnostic now reports ALL relevant services as successful:
DNS: Success
SSL: Success
API: Success
Chat: Success
Agent: Success
Authentication UI: Success
Cursor Tab: Success
Agent Endpoint: Success
Marketplace: Success

However, Agent still fails with:
ERROR_EXTENSION_HOST_TIMEOUT
Agent Execution Timed Out
Request ID: 7330735a-45fa-4d21-ab5e-de9e354b27be
I also checked the fresh remote Extension Host logs.
The Extension Host is still crashing repeatedly with exactly the same error:
TypeError: Converting circular structure to JSON
— property ‘issuerCertificate’ closes the circle
at … serializeRequestArguments
Extension Host Process exited with code: 7

This is not a single crash. The same crash repeats with different ExtensionHostConnection instances/PIDs throughout the session.
For example:
2026-08-08 14:25:39
Extension Host Process exited with code: 7
2026-08-08 14:25:44
Extension Host Process exited with code: 7
2026-08-08 14:25:48
Extension Host Process exited with code: 7
2026-08-08 14:25:58
Extension Host Process exited with code: 7
2026-08-08 14:26:32
Extension Host Process exited with code: 7
2026-08-08 14:26:36
Extension Host Process exited with code: 7
2026-08-08 14:26:39
Extension Host Process exited with code: 7
and again around 14:28.

The important point is that disabling telemetry and forcing HTTP/1.1 did not change the Extension Host crash loop.
Therefore, the current evidence does not support the hypothesis that mobile.events.data.microsoft.com telemetry traffic is the trigger, or at least it is not the only trigger.
The Extension Host is independently crashing inside Cursor’s own RPC serialization path:
serializeRequestArguments()
because an object containing issuerCertificate is being serialized.
This prevents the Extension Host from staying alive, which in turn prevents EverythingProvider from registering, and finally causes:

ERROR_EXTENSION_HOST_TIMEOUT
Agent Execution Timed Out

The same issuerCertificate / serializeRequestArguments crash was already present in the remote logs on August 6, so this is reproducible and not specific to today’s session.
Please investigate what RPC request/extension is passing a TLS error/certificate object containing issuerCertificate into the Extension Host RPC serializer.
At this point the network diagnostics are clean, telemetry is disabled, HTTP/2 is disabled, and the Extension Host itself is still crashing.
I can provide the complete remoteagent.log if needed.

сб, 8 авг. 2026 г. в 17:00, Dean Rie <[email protected]>:

15

Great result, this is exactly what we needed to narrow down the cause.

What it confirms: turning telemetry off removed one trigger mobile.events.data.microsoft.com, but since the crash loop is still happening, there’s at least one more outbound request inside the VM that hits the same TLS mismatch the host resolves via OrbStack DNS to basis.orb.local, and the cert doesn’t match. The actual crash is in our RPC serializer. One failed TLS request should not crash the Extension Host. The error should be serialized in a circular-safe way, not with raw JSON.stringify. This is on our side. I’ve sent the stack trace with serializeRequestArguments to the team. No ETA yet, I’ll post here when there’s an update.

To unblock you faster without waiting for the hardening fix, we need to find the remaining host. From a fresh session, right after you try to start the Agent, run this on the remote:

grep -rniE "altnames|issuerCertificate|serializeRequestArguments" ~/.cursor-server/data/logs/ | tail -n 80

I need all the ... is not in the cert's altnames lines right before the crashes. I want to see which other hosts besides mobile.events.data.microsoft.com are failing TLS right now. Once we have the full list, we can temporarily neutralize these requests at the VM level, for example via /etc/hosts or by blocking outbound traffic to them, and the crash loop should stop while we fix the serializer.

Please also attach the full remoteexthost.log and remoteagent.log from the same session. It can help.

About sandbox and seccomp EINVAL on kernel 7.0.x, no change from posts #8 and #11. That’s on our side and separate from the current blocker. The Agent should work without sandbox, so right now the focus is the Extension Host crash loop.

Send the grep output and we’ll take the next step.