Sign up
View stargazersSign up

[Bug]: Cursor Auto fails on Ubuntu AppImage because AppArmor blocks the bundled cursorsandbox helper#30348

opened7d agobyBbrunomartinsmv

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server — Cursor provider, with Linux desktop/AppArmor setup implications.

Steps to reproduce

  1. On Ubuntu with kernel.apparmor_restrict_unprivileged_userns=1 and no AppArmor profile allowing the bundled Cursor helper, launch the T3 Code desktop AppImage.
  2. Sign in to the Cursor provider and select Grok 4.7.
  3. Set the conversation's permission mode to Auto.
  4. Send a short message such as teste.

Reproduced in ordinary and delegated conversations. Retrying with the same configuration fails again.

Expected behavior

Auto can start a sandboxed Cursor turn after the host prerequisites are configured. If the host blocks the sandbox, T3 should identify that prerequisite and provide a specific setup action or command.

Actual behavior

The turn fails before the model responds. The UI shows only:

The provider could not start this turn. Retry the turn; if it keeps failing, check the provider setup and server logs.

The server reports a Cursor SDK sandbox ConfigurationError. The kernel journal identifies the actual cause: AppArmor denies the bundled helper's namespace setup.

Full access starts and completes a response on the same host/account/model.

Impact

Major degradation or frequent failure. Auto cannot start Cursor turns on this host without a manual AppArmor rule; Full access works.

Version or commit

T3 Code desktop/server 0.1.7-nightly.20261103.4119, bundled @cursor/sdk 1.2.0.

Environment

Ubuntu 24.04.5 LTS, Linux 7.0.0-42-generic, x86_64, Wayland. Desktop AppImage, Cursor provider, grok-4.7 with high reasoning effort and 256k context.

text
1kernel.unprivileged_userns_clone = 1
2kernel.apparmor_restrict_unprivileged_userns = 1

Logs or stack traces

Server, 2026-11-03 20:17:23 UTC:

text
1ProviderAdapterTurnStartError
2 cause: CursorAgentSdkRunnerError
3 method: run.start
4 cause: ConfigurationError
5 operation: agent.send
6 isRetryable: false
7 message: Local SDK sandboxing was requested, but sandboxing is not supported in this environment. Disable local.sandboxOptions.enabled or remove ~/.cursor/sandbox.json to run without sandboxing.

Kernel journal for the same failed attempt (PID and mount suffix redacted):

text
1apparmor="AUDIT" operation="userns_create" class="namespace"
2 profile="unconfined" comm="cursorsandbox"
3 target="unprivileged_userns"
4 execpath="/tmp/.mount_T3-CodXXXXXX/resources/node_modules/@cursor/sdk-linux-x64/bin/cursorsandbox"
5
6apparmor="DENIED" operation="capable" class="cap"
7 profile="unprivileged_userns" comm="cursorsandbox"
8 capability=21 capname="sys_admin"

Running that helper's preflight before applying the rule fails with:

text
1Failed to write /proc/self/uid_map (mapping UID 0 -> <host UID>):
2Operation not permitted (os error 1)

Workaround and verification

The original AppImage already includes the helper at:

text
1resources/node_modules/@cursor/sdk-linux-x64/bin/cursorsandbox

Installing/loading this narrowly scoped AppArmor profile, then restarting T3, resolved the failure:

apparmor
1abi <abi/4.0>,
2include <tunables/global>
3
4profile t3-cursor-sdk /tmp/.mount_T3-Cod*/resources/node_modules/@cursor/sdk-linux-x64/bin/cursorsandbox flags=(unconfined) {
5 userns,
6}

The global AppArmor restriction stayed enabled.

Verification after loading the rule:

  • The helper actually used by T3 passed preflight.
  • A real sandboxed command could write inside its workspace.
  • A write to an existing file outside that workspace was denied; its contents stayed unchanged.
  • After restarting T3, Grok 4.7 answered the short test. The thread API confirmed runtimeMode: auto and status: completed on 2026-11-03 at 20:21:25 UTC.

The successful end-to-end test used the original AppImage, SHA-256:

text
1153033c81932ce011fb8ed10f88896f4f6a7c0d5047a9b88f073e9f4ba354f2e

An initial local investigation mistakenly treated the helper as missing and tested an added copy at a different path. That change was reverted before the successful end-to-end test. The confirmed fix is the AppArmor rule for the original helper under resources/node_modules.

  • #22626: missing AppArmor setup guidance for the bundled preview browser. This report concerns the Cursor SDK helper.
  • #27702 / #27715: the same SDK error in auxiliary text generation, with a fallback that disables sandboxing. This report concerns normal Auto conversations retaining their sandbox.
  • #25921: Linux packaged dependency checks; the native helper is already present in the AppImage tested here.

A setup/preflight path for the Cursor helper, analogous to browser setup, and an actionable startup error would prevent users from needing Full access to get past this host prerequisite.