Terminal sandbox fails on first start in 2.5.26: "loopback: failed to look up lo interface"

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Body:

SummaryAfter upgrading to Cursor 2.5.26, the terminal sandbox fails to start. The error appears on first launch. Previous versions worked without this issue.## Environment- Cursor version: 2.5.26- OS: Ubuntu (Linux)- Kernel: 6.17.0-14-generic- Environment: VMware guest- Installation: System package (deb) at /usr/share/cursor## ErrorThe sandbox preflight fails with:

Error: Failed to apply sandbox: IO error: Step 2.5/7 (loopback setup) failed: IO error: loopback: failed to look up lo interface

Log locationFull error in: ~/.config/Cursor/logs/*/window*/exthost/exthost.logExample log lines:

[shell-exec:sandbox] [isSandboxHelperSupported] Preflight failed: Command failed: /usr/share/cursor/resources/app/resources/helpers/cursorsandbox … --preflight-only – /bin/true
Error: Failed to apply sandbox: IO error: Step 2.5/7 (loopback setup) failed: IO error: loopback: failed to look up lo interface

Additional context- The default loopback interface (lo) exists and is UP in the host namespace.- The renderer reports sandboxSupported=false after the preflight fails, so Cursor falls back to non-sandbox mode.- The user sees the “terminal sandbox cannot be started” message during startup.- This started in 2.5.26; earlier versions did not show this error.- User namespaces: kernel.apparmor_restrict_unprivileged_userns = 1## Expected behaviorThe sandbox should initialize successfully, as it did in previous versions.## Reproduction1. Upgrade to Cursor 2.5.262. Start Cursor3. Observe “terminal sandbox cannot be started” and the preflight failure in the logs

Steps to Reproduce

Start cursor 2.5.26 in ubuntu LTS 24.04 in VMWare Workstation 17.0

Expected Behavior

Start without error

Operating System

Linux

Version Information

Version: 2.5.26
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-14-generic

Does this stop you from using Cursor

Yes - Cursor is unusable

3

Hey, thanks for the detailed report. This is a known class of issues with the sandbox and AppArmor on newer Linux kernels, especially when apparmor_restrict_unprivileged_userns = 1.

The loopback lookup failure at step 2.5/7 is likely happening because the sandbox can’t set up a network namespace under your current AppArmor restrictions. A few things to try:

  1. Create an AppArmor profile for Cursor at /etc/apparmor.d/cursor-system:
abi <abi/4.0>,
include <tunables/global>
profile cursor-system "/usr/share/cursor/cursor" flags=(unconfined) {
  userns,
  include if exists <local/cursor>
}

Then load it:

sudo apparmor_parser -r /etc/apparmor.d/cursor-system
  1. Check for and remove any stale sandbox profile:
sudo aa-status | grep cursor

If cursor_sandbox shows up:

sudo apparmor_parser -R /etc/apparmor.d/cursor_sandbox
sudo rm /etc/apparmor.d/cursor_sandbox
sudo systemctl restart apparmor
  1. Set the setuid bit on the sandbox binary:
sudo chmod 4755 /usr/share/cursor/resources/app/resources/helpers/cursorsandbox

Restart Cursor after all steps.

This has worked for several other Linux users with similar setups. More context here:

I flagged the specific loopback error with the team. It’s a new variant we haven’t seen before in VMware environments. Let me know if the above helps.

5

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.