Terminal sandbox is incorrectly reported as unsupported on OrbStack Linux kernel 7.0.x (AppArmor suggestion is misleading)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

The bug appear:
Remote SSH → Terminal Sandbox / Shell Exec

When connecting to an Ubuntu 22.04 VM running inside OrbStack via Remote SSH, Cursor displays:
Terminal sandbox could not start.
This may be caused by an AppArmor configuration on your Linux system (kernel 6.2+).

However, this environment does not use AppArmor.

After investigating, I confirmed:
-AppArmor is not present.
-User namespaces are enabled.
-Seccomp is enabled.
-Landlock is enabled.
-Cursor reports sandboxSupported=false.

The AppArmor recommendation appears to be generic and is misleading for OrbStack users.

Steps to Reproduce

  1. Install Cursor 3.14.7 on macOS.
  2. Create an Ubuntu 22.04 VM in OrbStack 2.2.2.
  3. Connect using Remote SSH.
  4. Open an Agent terminal (Shell Exec).

Cursor displays:
Terminal sandbox could not start. This may be caused by an AppArmor configuration on your Linux system (kernel 6.2+). See the documentation for how to resolve this.

Expected Behavior

Cursor should either:

  • successfully initialize the terminal sandbox, or
  • display the actual reason why sandbox initialization failed.
    The AppArmor recommendation should only be shown if AppArmor is actually detected or involved.

Operating System

Linux

Version Information

Version: 3.14.7
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
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

Remote 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

Kernel capabilities:
CONFIG_NAMESPACES=y
CONFIG_USER_NS=y
CONFIG_SECCOMP=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECURITY_LANDLOCK=y
CONFIG_BPF_LSM=y

AppArmor:
aa-status
apparmor not present

User namespaces work:
unshare --user --map-root-user id

Mount namespaces fail without elevated privileges:
unshare --mount
Operation not permitted

The bundled cursorsandbox binary contains support for:

  • Landlock
  • Bubblewrap
  • Automatic backend selection

It also contains messages including:

  • Step 3/7 (remount / as MS_PRIVATE) failed: Operation not permitted
  • Bubblewrap namespace setup failed
  • Linux auto backend selection failed

The renderer logs show that Cursor displays the AppArmor notification whenever sandboxSupported == false and the detected Linux kernel version is >= 6.2.

The notification appears even though AppArmor is not installed or enabled.

Could you clarify whether OrbStack is currently supported for Terminal Sandbox, or if this is a detection issue? If not supported, it would be helpful if Cursor displayed the actual backend failure instead of the generic AppArmor recommendation.

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey, thanks for the detailed report. The diagnostics really help.

Let’s break it down:

About the AppArmor message. You’re right, it’s generic. It shows up whenever sandbox detection fails on kernel 6.2+, even if AppArmor isn’t installed. This is a known issue and we’re tracking it. I don’t have an exact timeline yet, but showing the real backend failure reason instead of the generic AppArmor tip is already on our radar. I’ll post here if there’s an update.

Why the sandbox isn’t actually starting in your case. Based on your diagnostics, it’s not just the message. Terminal sandbox uses a mount namespace, and in your OrbStack VM it’s not available to an unprivileged process:

unshare --mount
Operation not permitted

User namespaces work, but mount namespaces don’t, so bubblewrap or the mount backend can’t do the remount step Step 3/7 remount / as MS_PRIVATE failed Operation not permitted. That’s an OrbStack environment limitation, not a Cursor setting. Without mount namespaces, the sandbox can’t initialize in this setup.

How to unblock things right now. Turn off terminal sandbox in Auto-Run settings. Then agent commands will run without the sandbox with manual confirmation, and Cursor will stop hitting this error. That should let you keep using the agent on this VM while the sandbox is unavailable.

Let me know if disabling the sandbox helped. If OrbStack has an option to allow unprivileged mount namespaces, it’s also worth trying.

5

Thanks for confirming.

Just to clarify, is this an intentional limitation of OrbStack, or is Cursor currently relying on Bubblewrap/mount namespaces in a way that is incompatible with OrbStack?

In other words, do you expect Terminal Sandbox to eventually work on OrbStack, or is it currently considered an unsupported environment?

ср, 5 авг. 2026 г. в 16:50, Dean Rie <[email protected]>:

6

Good question, I’ll answer both points.

This isn’t an intentional “exception” for OrbStack. Terminal Sandbox on Linux uses an unprivileged mount namespace. The backend bubblewrap or mount remounts / as MS_PRIVATE on startup, and without that step it can’t set up isolation. In your OrbStack VM, user namespaces work, but mount namespaces are blocked for unprivileged processes (unshare --mount returns Operation not permitted), so that step fails. So Cursor depends on a capability that OrbStack currently doesn’t allow for unprivileged processes. This is an environment limitation, not a Cursor setting.

So as of today, OrbStack is effectively unsupported for Terminal Sandbox. To change that, one of two things needs to happen: either OrbStack starts allowing unprivileged mount namespaces (if it has a config option for this, it’s worth trying), or we add a sandbox backend that doesn’t require a mount namespace. I can’t promise timelines or that the second option will definitely happen.

For now, the workaround is to disable terminal sandbox in Auto-Run settings. Then agent commands will go through manual confirmation without sandbox, and the error will go away.

Separately, about the misleading AppArmor message (when AppArmor isn’t even installed): we’re tracking that, and we plan to show the real denial reason instead of a generic hint. I’ll reply in the thread if there’s an update.