# Remote SSH Extension Host repeatedly SIGKILLed when user namespaces are disabled (max\_user\_namespaces=0) – Cursor 3.21.16 **URL:** \ **Category:** Bug Reports\ **Tags:** sandbox, linux, crashes, ssh\ **Created:** [September 21, 2026, 8:47am UTC](https://forum.cursor.com/t/remote-ssh-extension-host-repeatedly-sigkilled-when-user-namespaces-are-disabled-max-user-namespaces-0-cursor-3-21-16/172486 "2026-09-21T08:47:33Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![C24](https://avatars.discourse-cdn.com/v4/letter/c/a9adbd/32.png) [@C24](https://forum.cursor.com/u/C24)\ **Post date:** [September 21, 2026, 8:47am UTC](https://forum.cursor.com/t/remote-ssh-extension-host-repeatedly-sigkilled-when-user-namespaces-are-disabled-max-user-namespaces-0-cursor-3-21-16/172486/1 "2026-09-21T08:47:33Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug Hi, I’m experiencing a reproducible Remote SSH Extension Host crash loop with **Cursor 3.21.16** on a managed Debian 12 server. The SSH connection itself works and the Cursor Server starts successfully. However, the Remote Extension Host is killed approximately 30 seconds after startup. Cursor automatically restarts it, and after three crashes Cursor shows: > The remote extension host terminated unexpectedly 3 times within the last 5 minutes. ### Steps to Reproduce ## Environment ### Local - macOS - Cursor 3.21.16 - Connection via Cursor Remote SSH ### Remote - Managed hosting environment - No root access - Debian GNU/Linux 12 (bookworm) - x86\_64 - Kernel: ```plaintext Linux XXX.your-server.de 6.1.0-53-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.187-1 (2026-09-07) x86_64 GNU/Linux ``` User namespaces are disabled by the hosting provider: ```bash $ cat /proc/sys/user/max_user_namespaces 0 ``` The hosting provider has confirmed that user namespaces cannot be enabled in this environment. Trying to create a user namespace manually: ```bash $ unshare --user --map-root-user true unshare: unshare failed: No space left on device $ echo $? 1 ``` The “No space left on device” message is not caused by actual disk or memory exhaustion. User namespaces are explicitly disabled (`max_user_namespaces=0`). ## Memory / OOM checks The server has plenty of available memory: ```plaintext total used free shared buff/cache available Mem: 251Gi 14Gi 6.4Gi 182Mi 232Gi 237Gi Swap: 4.0Gi 731Mi 3.3Gi ``` The process is not being killed by the cgroup OOM killer: ```plaintext memory.max: max memory.events: low 0 high 0 max 0 oom 0 oom_kill 0 oom_group_kill 0 ``` The process belongs to: ```plaintext 0::/system.slice/ssh.service ``` Relevant process limits: ```plaintext Max processes 2048 2048 Max open files 1024 1048576 Max resident set unlimited unlimited Max address space unlimited unlimited ``` So I don’t see evidence of a memory/OOM-related SIGKILL. ## Cursor Remote logs The Extension Host initially starts normally: ```plaintext 2026-09-21 10:27:08.571 [info] [127.0.0.1][cbf22b78][ExtensionHostConnection] <58667> Launched Extension Host Process. ``` Shortly afterwards, the Remote Extension Host starts detecting sandbox support: ```plaintext [ExtHostShellExec] Detecting sandbox support... [ExtHostShellExec] Platform: linux, Shell type: unknown [ExtHostShellExec] Sandbox helper path: /usr/home/planrt/.cursor-server/bin/linux-x64/8ae78e8eee1e63479c7e0504b664bc0a80c68000/resources/helpers/cursorsandbox [ExtHostShellExec] Probing sandbox support... [shell-exec:sandbox] [sandboxPreflight] Running preflight with binary: .../resources/helpers/cursorsandbox ``` The sandbox preflight then times out after exactly 15 seconds: ```plaintext 2026-09-21 10:27:25.038 [error] [shell-exec:sandbox] [primeSandboxHelperSupport] Preflight timed out after 15000ms, treating sandbox as unsupported 2026-09-21 10:27:25.038 [info] [ExtHostShellExec] Sandbox support detected: false, platform: linux, kernelVersion: 6.1.0-53-amd64 ``` About 12 seconds later, the Extension Host receives SIGKILL: ```plaintext 2026-09-21 10:27:37.182 [info] [127.0.0.1][cbf22b78][ExtensionHostConnection] <58667> Extension Host Process exited with code: null, signal: SIGKILL. ``` The File Watcher is also killed: ```plaintext 2026-09-21 10:27:37.240 [error] [File Watcher (universal)] restarting watcher after unexpected error: terminated by itself with code null, signal: SIGKILL (ETERM) ``` Cursor immediately launches another Extension Host: ```plaintext 2026-09-21 10:27:37.462 [info] [127.0.0.1][d5804022][ExtensionHostConnection] <59140> Launched Extension Host Process. ``` The exact same sequence happens again: ```plaintext 2026-09-21 10:27:53.899 [error] [shell-exec:sandbox] [primeSandboxHelperSupport] Preflight timed out after 15000ms, treating sandbox as unsupported 2026-09-21 10:27:53.899 [info] [ExtHostShellExec] Sandbox support detected: false, platform: linux, kernelVersion: 6.1.0-53-amd64 ``` followed by: ```plaintext 2026-09-21 10:28:07.222 [info] [127.0.0.1][d5804022][ExtensionHostConnection] <59140> Extension Host Process exited with code: null, signal: SIGKILL. ``` Cursor launches the Extension Host again as PID 59538 and the same sequence repeats for a third time. So the behavior is consistently: ```plaintext Remote Extension Host starts | v Cursor detects sandbox support | v cursorsandbox preflight starts | v preflight hangs for 15 seconds | v "Sandbox support detected: false" | v ~12-14 seconds later | v Extension Host receives SIGKILL | v File Watcher also receives SIGKILL | v Cursor restarts Extension Host | v same sequence repeats ``` ## Extensions appear to initialize successfully The Cursor extensions themselves appear to activate successfully before the Extension Host is killed: ```plaintext Extension activated success: anysphere.cursor-agent-exec Extension activated success: anysphere.cursor-explorer Extension activated success: anysphere.cursor-shadow-workspace Extension activated success: anysphere.cursor-retrieval ``` There are also messages such as: ```plaintext No bundle location found for extension anysphere.cursor-agent-exec No bundle location found for extension anysphere.cursor-checkout No bundle location found for extension anysphere.cursor-polyfills-remote ``` However, those extensions subsequently report successful activation, so I’m not sure whether these messages are related. ## Attempted workaround: disable sandbox Since user namespaces cannot be enabled on this server, I tried explicitly disabling Cursor’s sandbox. I created: ```plaintext ~/.cursor/sandbox.json ``` with: ```json { "type": "insecure_none" } ``` I then stopped the existing Cursor Server: ```bash pkill -u "$USER" -f cursor-server ``` and completely restarted Cursor on the Mac before reconnecting via Remote SSH. Unfortunately, this does not change the behavior. Even with: ```json { "type": "insecure_none" } ``` the Remote Extension Host still executes the `cursorsandbox` preflight: ```plaintext Detecting sandbox support... Probing sandbox support... Running preflight with binary: .../cursorsandbox Preflight timed out after 15000ms Sandbox support detected: false ``` and the Extension Host is subsequently SIGKILLed again. ## Important observation The server explicitly has: ```plaintext /proc/sys/user/max_user_namespaces = 0 ``` and therefore: ```bash unshare --user --map-root-user true ``` fails. At the same time, Cursor’s Remote Extension Host repeatedly tries to probe `cursorsandbox`, waits 15 seconds for the probe to time out, correctly determines: ```plaintext Sandbox support detected: false ``` but the Extension Host is then SIGKILLed shortly afterwards. I don’t want to claim that the sandbox preflight itself is definitely causing the SIGKILL, but the sequence is highly reproducible and happens on every Extension Host restart. There is also no evidence of an OOM kill (`oom_kill=0`) and memory availability is \>200 GiB. ## Questions 1. **Should Cursor Remote SSH support Linux servers where `max_user_namespaces=0`?** 2. Once Cursor detects: ```plaintext Sandbox support detected: false ``` should the Remote Extension Host simply continue without sandboxing? 1. Is there a supported configuration or environment variable to **completely disable the `cursorsandbox` capability/preflight check** for Remote SSH hosts? 2. Should: ```json { "type": "insecure_none" } ``` prevent this preflight, or does this setting only affect sandboxing of Agent command execution? 1. Could Cursor itself be sending the SIGKILL after the sandbox detection/preflight fails, or is there another Cursor subprocess/watchdog that could explain both the Extension Host and File Watcher receiving SIGKILL? 2. Is this a known regression in Cursor 3.21.x? Unfortunately, enabling user namespaces is not an option because this is a managed hosting environment and the hosting provider explicitly disables them. If useful, I can provide the complete: - `remoteagent.log` - `remoteexthost.log` - `Cursor Agent Exec.log` or run additional diagnostics. Thanks! ### Operating System Linux ### Version Information 3.21.16 on MacOs ### Does this stop you from using Cursor Yes - Cursor is unusable ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [September 21, 2026, 10:45am UTC](https://forum.cursor.com/t/remote-ssh-extension-host-repeatedly-sigkilled-when-user-namespaces-are-disabled-max-user-namespaces-0-cursor-3-21-16/172486/7 "2026-09-21T10:45:47Z")
Hey @C24, thanks for the thorough report. Short version: this isn’t the sandbox, and it isn’t Cursor killing the host. The SIGKILL is coming from the server itself. Your remote looks like a Hetzner Managed Server, and their Managed Server agreement (section 9, “Process Monitoring”) describes a monitor that terminates processes for excessive runtime or RAM. That fits what you measured: no cgroup OOM, plenty of free RAM, but the extension host and file watcher killed together on a fixed cadence. `max_user_namespaces=0` is fully supported (Cursor just runs without the command sandbox), and the preflight and `~/.cursor/sandbox.json` aren’t involved - that config is read on your local machine, not the remote, so `insecure_none` was never going to change this. Best next step is host-side: ask Hetzner support whether their process monitoring killed your `node` processes at 10:27:37 / 10:28:07, which limit applied, and whether they can add an exception for processes under `~/.cursor-server`. If you can also paste this from a plain SSH session at ~10s and ~25s after connecting, it shows how big things get right before the kill: ```auto ps -u $(whoami) -o pid,rss,etime,cmd --sort=-rss | head -n 15 ``` To keep working meanwhile: open a smaller project folder and turn off codebase indexing for that remote workspace; an earlier build also has a lighter remote footprint and may stay under the limit as a stopgap. This is an issue we’re tracking, and I’ll follow up here when there’s an update. ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [October 20, 2026, 9:31am UTC](https://forum.cursor.com/t/remote-ssh-extension-host-repeatedly-sigkilled-when-user-namespaces-are-disabled-max-user-namespaces-0-cursor-3-21-16/172486/10 "2026-10-20T09:31:00Z")
Hey @C24, Following up on this as promised. We dug further, and everything still points to the server side: the extension host and file watcher are being stopped by the host’s process monitoring, not by Cursor. An exception from your hosting provider for processes under `~/.cursor-server` remains the most reliable fix. We’ve also made changes that reduce how much work the remote file watcher does when a folder opens, and absolute paths in `files.watcherExclude` (Remote settings) are now respected. If your project has large folders (uploads, caches, logs, vendor directories), excluding them there helps keep the server’s footprint down. Could you let us know whether the extension host is still being killed on the latest version? If it has settled down for you, no need to reply. ---
**Author:** ![C24](https://avatars.discourse-cdn.com/v4/letter/c/a9adbd/32.png) [@C24](https://forum.cursor.com/u/C24)\ **Post date:** [October 21, 2026, 9:46am UTC](https://forum.cursor.com/t/remote-ssh-extension-host-repeatedly-sigkilled-when-user-namespaces-are-disabled-max-user-namespaces-0-cursor-3-21-16/172486/11 "2026-10-21T09:46:18Z")
Hi Colin, Thank you for getting back to us. We spoke with our hosting provider, and they did indeed add an exception for the folder, which resolved the issue. Thanks again and best regards, Arne