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

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.

kernel.unprivileged_userns_clone = 1
kernel.apparmor_restrict_unprivileged_userns = 1

Logs or stack traces

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

ProviderAdapterTurnStartError
  cause: CursorAgentSdkRunnerError
    method: run.start
    cause: ConfigurationError
      operation: agent.send
      isRetryable: false
      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):

apparmor="AUDIT" operation="userns_create" class="namespace"
  profile="unconfined" comm="cursorsandbox"
  target="unprivileged_userns"
  execpath="/tmp/.mount_T3-CodXXXXXX/resources/node_modules/@cursor/sdk-linux-x64/bin/cursorsandbox"

apparmor="DENIED" operation="capable" class="cap"
  profile="unprivileged_userns" comm="cursorsandbox"
  capability=21 capname="sys_admin"

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

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

Workaround and verification

The original AppImage already includes the helper at:

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

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

abi <abi/4.0>,
include <tunables/global>

profile t3-cursor-sdk /tmp/.mount_T3-Cod*/resources/node_modules/@cursor/sdk-linux-x64/bin/cursorsandbox flags=(unconfined) {
  userns,
}

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:

153033c81932ce011fb8ed10f88896f4f6a7c0d5047a9b88f073e9f4ba354f2e

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.

Related reports

• Linux desktop onboarding doesn't mention the AppArmor browser setup step until browser tools fail #22626: missing AppArmor setup guidance for the bundled preview browser. This report concerns the Cursor SDK helper.
• [Bug]: Cursor thread titles never generate on Windows: the sandbox fallback catches Agent.create, but SDK 1.0.38 throws from agent.send #27702 / fix(cursor): thread titles generate when the SDK cannot sandbox #27715: the same SDK error in auxiliary text generation, with a fallback that disables sandboxing. This report concerns normal Auto conversations retaining their sandbox.
• fix(desktop): Linux builds fail when the packaged server cannot resolve a dependency #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.