Cursor CLI not updating? Sandboxing doesn't work

My agent cli is at the following version, which seems to be the most recent one:

$ agent --version
2026.02.13-41ac335
$ agent update
Checking for updates...
Already up to date

while the Changelog · Cursor has the newest CLI update with date 2026.02.18.

How can I get the newest CLI version?

I came across this because sandboxing fails in my CLI with the following message:

Sandbox requires kernel v6.2 or later and may require additional AppArmor policies to be set. Falling back to allowlist mode for this session.

Based on cursors investigation the reason why it’s not working is:

The CLI has the sandboxing code fully implemented and functional – the binary works, Landlock enforces properly, the preflight passes – but it’s gated behind a Statsig feature flag rollout (composer_sandbox_settings_visible) that is currently false for your account.

In IDE it works just fine under version 2.5.20:

Version: 2.5.20
VSCode Version: 1.105.1
Commit: 511523af765daeb1fa69500ab0df5b6524424610
Date: 2026-02-19T20:41:31.942Z
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: Darwin arm64 25.1.0

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.


Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!


Expected Behavior
What is meant to happen here that isn’t working correctly?


Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)


Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)


For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…


Additional Information
Add any other context about the problem here.


Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

Hey there!

Any chance you’re running the agent CLI inside a Linux container (e.g., Docker) or on a remote Linux machine via SSH? The error message you’re seeing, “Sandbox requires kernel v6.2 or later” , is specific to Linux and can’t be produced on native macOS. On macOS, the message would be “Sandbox is unavailable” instead.

Could you run agent about and share the output? That’ll tell us exactly what environment the CLI is seeing.

By the way, you’re using the latest version of the CLI – the changelog just sometimes lags behind a few days!

Sorry, yes, running via SSH on a remote machine:

$ agent about
About Cursor CLI

CLI Version         2026.02.13-41ac335
Model               Claude 4.6 Opus (Thinking)
OS                  linux (x64)
Terminal            unknown
Shell               bash

Regarding:

By the way, you’re using the latest version of the CLI – the changelog just sometimes lags behind a few days!

My point was it actually seems like it’s the opposite - that the CLI release seems to lag behind the changelog. Because it seems like the CLI is from 2026.02.13 and latest changelog is from 2026.02.18.

Also - a verification that the kernel supports Landlock:

$ ~/.local/share/cursor-agent/versions/2026.02.13-41ac335/cursorsandbox --sandbox-policy-cwd /tmp --sandbox-policy '{"type":"workspace_readonly", "cwd":"/tmp"}' --preflight-only true; echo $?
0

whereas on a different machine with a kernel without LandLock support:

$ ~/.local/share/cursor-agent/versions/2026.02.13-41ac335/cursorsandbox --sandbox-policy-cwd /tmp --sandbox-policy '{"type":"workspace_readonly", "cwd":"/tmp"}' --preflight-only true; echo $?
Error: Failed to apply sandbox: Failed to apply Landlock: Step 5/7 (landlock) failed: Failed to apply Landlock: Landlock V3 filesystem restrictions not supported. Error: fully incompatible access-rights: BitFlags<AccessFs>(0b111111111110010, WriteFile | RemoveDir | RemoveFile | MakeChar | MakeDir | MakeReg | MakeSock | MakeFifo | MakeBlock | MakeSym | Refer | Truncate). Ensure Landlock LSM is enabled (CONFIG_SECURITY_LANDLOCK=y) on a kernel with V3 support.
1

And those changes from the latest changelog were first implemented in 2026.02.13!

What linux flavor / kernel version is used on the remote machine?

$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.7 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.7"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.7 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.7"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.7"
$ uname -r
5.14.0-570.58.1.el9_6.x86_64

with backported landlock v5:

#define _GNU_SOURCE
#include <errno.h>
#include <stdio.h>
#include <sys/syscall.h>
#include <unistd.h>

/* Fallbacks in case headers are old */
#ifndef __NR_landlock_create_ruleset
# if defined(__x86_64__)
#  define __NR_landlock_create_ruleset 444
# elif defined(__aarch64__)
#  define __NR_landlock_create_ruleset 444
# else
#  error "Unknown arch: define __NR_landlock_create_ruleset for your arch"
# endif
#endif

#ifndef LANDLOCK_CREATE_RULESET_VERSION
#define LANDLOCK_CREATE_RULESET_VERSION (1U << 0)
#endif

int main(void) {
    int v = syscall(__NR_landlock_create_ruleset, NULL, 0,
                    LANDLOCK_CREATE_RULESET_VERSION);
    if (v < 0) {
        perror("landlock_create_ruleset(VERSION)");
        return 1;
    }
    printf("%d\n", v);
    return 0;
}
$ gcc -O2 -Wall landlock_abi.c -o landlock_abi && ./landlock_abi
5

Hey Matej!

Sorry for the late follow-up here. I dug into this because in fact, on my local Ubuntu install, I was also getting denied the sandbox.

You can get detailed debug information by running the CLI with --debug:

agent --debug

This starts a local log server at http://127.0.0.1:43111 that shows exactly why sandbox setup fails. For example, on my Ubuntu 24.04 machine I saw this in the debug logs:

[isSandboxHelperSupported] Stderr: Error: Failed to apply sandbox: IO error: Step 1-2/7 (user namespace) failed: IO error: Failed to write /proc/self/uid_map (mapping UID 0 -> 1000): Operation not permitted (os error 1) (errno 1)

This pointed to Ubuntu 24.04’s AppArmor restricting unprivileged user namespaces, even when kernel.unprivileged_userns_clone=1. The fix was:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Since you’re on Rocky Linux 9.7, your root cause may differ, but agent --debug will show you the exact preflight failure. Could you share what you see in the debug logs?

Hello Colin, thanks for getting back to me.

As far as I can tell the issue “resolved itself”.

Afaik nothing was done to the server I was experimenting with the sandboxing on and today (after some time off) I:

  1. Tried booting up the agent CLI again - still saw the warning message about unsupported system
  2. Headed back to this thread and saw your reply
  3. Exited agent, started it again with --debug and got no warning message this time

…aand the sandboxing works ever since.

I know an agent cli update was released in the meantime. But if I recall correctly I tried it before my vacation and it didn’t work either.

$ agent about
About Cursor CLI

CLI Version         2026.02.27-e7d2ef6
Model               Claude 4.6 Opus
OS                  linux (x64)
Terminal            unknown
Shell               bash
$ uname -r
5.14.0-570.58.1.el9_6.x86_64

From my point of view it seems like simply the sandboxing feature was enabled for my account in the meantime (we are on an Enterprise licence). I’m basing this guess on:

  • the fact that I had to re-launch the agent cli today for it to start working

  • the Cursor analysis of the CLI code I posted in the first post:

Today, after weekend, the error appeared again - for the 1st CLI startup.
For any following run the error was gone. Will try to catch it with agent --debug next time (perhaps next Monday? :slight_smile: )