Remote Extension host crash loop on Remote-SSH — regression in 3.19.13, fixed by downgrading to 3.18.9

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After my laptop auto-updated to Cursor 3.19.13, connecting to any Remote-SSH host triggers a crash loop: within seconds the remote workspace loads, then Cursor shows “Remote Extension host terminated unexpectedly 3 times within the last 5 minutes.” The Agent, shell tools, and file tools stop working because the extension host keeps dying and respawning.

Key detail: the SSH tunnel itself stays connected the whole time (status bar shows active SSH traffic) — it is specifically the remote extension host that crashes, not the connection.

This happens even when opening a brand-new empty folder, so it is not related to my project’s file count, file watchers, or any workspace content.

The remote extension host log shows a cursorsandbox preflight failure (ENOSPC on user-namespace unshare, sandbox unsupported), but the host continues past it and loads all extensions successfully before dying silently with no exception — so the sandbox preflight failure appears to be a red herring, not the cause.

Steps to Reproduce

Update Cursor to 3.19.13 (Windows x64 user-setup).
Connect to a Remote-SSH host (standard Debian 12 server, shared-hosting environment, no root).
Open any folder, including an empty one.
Within ~1 minute the “terminated 3 times” popup appears and repeats; extension host, agent, and terminal file tools become unusable.

Expected Behavior

Stable connection to the Remote-SSH host

Operating System

Windows 10/11
Linux

Version Information

Version: 3.19.13 (user setup)
VS Code Extension API: 1.128.0
Commit: dd066f332fcea7382764400fde902f61920648d0
Date: 2026-09-04T17:41:16.065Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Additional Information

Broken: Cursor 3.19.13, commit dd066f332fcea7382764400fde902f61920648d0, Electron 42.10.0, Node 24.18.1 (2026-09-04 build)
Working: Cursor 3.18.9, commit 2ba48ff3f7514cc4643c52ca9f7b3173d9b66137, Electron 40.10.3, Node 24.15.0 (2026-08-27 build)
Local OS: Windows 11 x64 (10.0.26200)
Remote OS: Debian 12, kernel 6.1.0-52-amd64, shared hosting, non-root user
Both machines connect to the same remote user/server
Log Remote Extension Host:
$ pkill -u USER -f cursor-server; sleep 2
$ rm -rf ~/.cursor-server
$ mkdir -p ~/test-empty
$ cat /proc/self/limits | grep -E “processes|files|memory”
Max processes 2048 2048 processes
Max open files 1024 1048576 files
Max locked memory 16871096320 16871096320 bytes

$ ps -u USER -o pid,ppid,etimes,rss,stat,comm | grep MainThread

five MainThread (extension host) processes accumulating, not cleaning up:

PID1 PPIDa 287s 54064 Sl MainThread
PID2 PPIDb 286s 121020 Sl MainThread
PID3 PID2 187s 70880 Sl MainThread
PID4 PID2 167s 66940 Sl MainThread
PID5 PID2 32s 85244 Sl MainThread

after pkill, hosts respawn again — crash/respawn loop

$ bash -lc ‘ulimit -n’
1024

dmesg not readable as non-root (empty), so no OOM confirmation either way

Remote OS: Debian 12, kernel 6.1.0-52-amd64, shared hosting, non-root user

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. We don’t often get this level of diagnostics.

From our side, we can see what’s happening: on 3.19.x the remote extension host on your server is being force-killed with SIGKILL about once a minute, and that kill is coming from the server OS, not from Cursor. On 3.18 sessions, the same process isn’t killed even once. The most likely explanation is a memory or resource limit on your hosting account: the remote server in 3.19 ships with a newer Node.js runtime, the footprint is a bit larger, and on a tightly limited shared host it crosses the limit that 3.18 stayed under. You’re right about the cursorsandbox preflight, it’s a red herring and not the cause.

To pinpoint which limit is triggering, can you reproduce this once on 3.19 and send the output of these commands from the remote host:

  1. Confirm the kill in the server log:
grep -h "Extension Host Process exited" ~/.cursor-server/data/logs/*/remoteagent.log | tail -n 5
  1. Full per-process limits last time we only got three lines:
cat /proc/self/limits
  1. Memory limit and OOM-kill counter for your session’s cgroup:
cat /proc/self/cgroup
cat /sys/fs/cgroup$(cut -d: -f3 /proc/self/cgroup)/memory.max /sys/fs/cgroup$(cut -d: -f3 /proc/self/cgroup)/memory.events
  1. free -m, plus anything your hosting panel shows about per-account memory or process limits.

For now, staying on 3.18 is a workable stopgap, so you can keep working. If your provider can raise the account memory limit, 3.19 should start working too. Either way, I’ll pass this to the team, and once you share the data we’ll confirm which limit it is and how much headroom you’re losing.

6

Im on v3.20.10 and have the same issue still.
Remote SSH is unusable atm as it crashes every few seconds.

Will this issue be fixed anytime soon or do we now have to stay on v3.18.9 forever?

7

Hey, thanks for posting. Quick nuance: the popup “Remote Extension host terminated unexpectedly 3 times” is a generic message that can come from a few different root causes. In the original thread, the crash was tied to a memory or resource limit on that user’s shared hosting, not a global issue across all setups. Your crash rate is different (every few seconds vs about once per minute), so it could be a different cause, for example a separate class of crashes on older Linux hosts.

To figure out what’s happening in your case, could you please share the following from the remote host after reproducing on 3.20.10:

  1. glibc and OS version:
ldd --version
  1. The Extension Host exit line from the logs (it will show the signal, like SIGKILL, SIGSEGV, or SIGABRT):
grep -h "Extension Host Process exited" ~/.cursor-server/data/logs/*/remoteagent.log | tail -n 5
  1. Your exact Cursor version (Help > About), plus whether you’re running as root or non-root, and what kind of hosting this is (regular VPS, shared hosting, HPC, etc).

Once we see the signal from step 2, it’ll be clear if this is the same class as in that thread or something else, and where to dig next. While we investigate, rolling back to 3.18.x is still a workable stopgap. I can’t give an ETA yet, but once we identify your case, I’ll share the next steps.

8

Vesion : 3.20.10 (user setup)

6.1.0-53-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.187-1 (2026-09-07) x86_64
Last login: Wed Aug 9 13:34:18 2023 from 62.0.84.118
~$ ldd --version
ldd (Debian GLIBC 2.36-9+deb12u14) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
~$ ^C
~$ grep -h “Extension Host Process exited” ~/.cursor-server/data/logs//remoteagent.log | tail -n 5
2026-09-11 15:02:06.362 [info] [127.0.0.1][8a9b536e][ExtensionHostConnection] <46681> Extension Host Process exited with code: 0, signal: null.
2026-09-11 15:02:49.427 [info] [127.0.0.1][4b70aa2d][ExtensionHostConnection] <14803> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:19.453 [info] [127.0.0.1][8b79b746][ExtensionHostConnection] <15072> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:49.446 [info] [127.0.0.1][c6f0faca][ExtensionHostConnection] <15322> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:06:19.444 [info] [127.0.0.1][fb02f33c][ExtensionHostConnection] <16818> Extension Host Process exited with code: null, signal: SIGKILL.
~$ cat /proc/self/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 2048 2048 processes
Max open files 1024 1048576 files
Max locked memory 16871092224 16871092224 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 514642 514642 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
~$ cat /proc/self/cgroup
cat /sys/fs/cgroup$(cut -d: -f3 /proc/self/cgroup)/memory.max /sys/fs/cgroup$(cut -d: -f3 /proc/self/cgroup)/memory.events
0::/system.slice/ssh.service
max
low 0
high 0
max 0
oom 0
oom_kill 0
oom_group_kill 0
:~$ nux dedi3509.your-server.de 6.1.0-53-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.187-1 (2026-09-07) x86_64
Last login: Wed Aug 9 13:34:18 2023 from 62.0.84.118
:~$ ldd --version
ldd (Debian GLIBC 2.36-9+deb12u14) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
~$ ^C
~$ grep -h “Extension Host Process exited” ~/.cursor-server/data/logs//remoteagent.log | tail -n 5
2026-09-11 15:02:06.362 [info] [127.0.0.1][8a9b536e][ExtensionHostConnection] <46681> Extension Host Process exited with code: 0, signal: null.
2026-09-11 15:02:49.427 [info] [127.0.0.1][4b70aa2d][ExtensionHostConnection] <14803> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:19.453 [info] [127.0.0.1][8b79b746][ExtensionHostConnection] <15072> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:49.446 [info] [127.0.0.1][c6f0faca][ExtensionHostConnection] <15322> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:06:19.444 [info] [127.0.0.1][fb02f33c][ExtensionHostConnection] <16818> Extension Host Process exited with code: null, signal: SIGKILL.
~$ cat /proc/self/limits
Limit Soft Limit Hard Limit Units
^Cm_group_kill 0/ssh.service/memory.events/cgroup)/memory.max /sys/fs/cgroup$(cu
~$ grep -h “Extension Host Process exited” ~/.cursor-server/data/logs/*/remoteagent.log | tail -n 5
2026-09-11 15:02:06.362 [info] [127.0.0.1][8a9b536e][ExtensionHostConnection] <46681> Extension Host Process exited with code: 0, signal: null.
2026-09-11 15:02:49.427 [info] [127.0.0.1][4b70aa2d][ExtensionHostConnection] <14803> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:19.453 [info] [127.0.0.1][8b79b746][ExtensionHostConnection] <15072> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:49.446 [info] [127.0.0.1][c6f0faca][ExtensionHostConnection] <15322> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:06:19.444 [info] [127.0.0.1][fb02f33c][ExtensionHostConnection] <16818> Extension Host Process exited with code: null, signal: SIGKILL.
~$ cat /proc/self/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 2048 2048 processes
Max open files 1024 1048576 files
Max locked memory 16871092224 16871092224 bytes
Max address space unlimited unlimited bytes
oom_group_kill 0/ssh.service/memory.events/cgroup)/memory.max /sys/fs/cgroup$(cu

9

3.20.10 (user setup)
ldd (Debian GLIBC 2.36-9+deb12u14) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

2026-09-11 15:02:06.362 [info] [127.0.0.1][8a9b536e][ExtensionHostConnection] <46681> Extension Host Process exited with code: 0, signal: null.
2026-09-11 15:02:49.427 [info] [127.0.0.1][4b70aa2d][ExtensionHostConnection] <14803> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:19.453 [info] [127.0.0.1][8b79b746][ExtensionHostConnection] <15072> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:03:49.446 [info] [127.0.0.1][c6f0faca][ExtensionHostConnection] <15322> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-11 15:06:19.444 [info] [127.0.0.1][fb02f33c][ExtensionHostConnection] <16818> Extension Host Process exited with code: null, signal: SIGKILL.

10

@gioras: thanks, this is enough data, and it’s important. Your log confirms SIGKILL, but at the same time memory.max = max and oom_kill 0, which means there’s no memory limit on this host and there were zero OOM kills. So the “memory limit in your environment” hypothesis doesn’t fit. This is a dedicated host with no limits, and the process is still being killed externally via SIGKILL. Also, glibc 2.36 is a modern linux-x64 server, so this isn’t one of the old crash classes on legacy hosts either.

So this looks like a separate issue with the remote server on the 3.19/3.20 line on normal Linux hosts, not what we discussed earlier. I’ve passed your logs to the team. I can’t share an ETA yet, but I’ll post an update in the thread when I have one. In practice, rolling back to 3.18.x is still a working stopgap.

@oooFreaKooo: your cadence is different every few seconds vs ~30 to 60s for gioras, so the root cause might be different. To check if it’s the same class or not, please share from step 2 above the line with the signal SIGKILL or SIGSEGV or SIGABRT, and the output of ldd --version from the remote host after reproducing on 3.20.10. The signal will immediately tell us where to dig. For now, rolling back to 3.18.x is a working workaround.

14

@gioras tarun here!!

Can you please the remote ssh log file from the output channel.

16

@deanrie Sorry for the late response.
I was working with v3.18.9, but today it automatically updated, so I have that issue again :frowning:

Version: 3.21.18 (Universal)
VS Code Extension API: 1.128.0
Commit: c4730f7d93d787d9ab120af715999f0345ee5bc0
Date: 2026-09-22T02:04:34.641Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

ldd --version:

ldd (Debian GLIBC 2.36-9+deb12u14) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

2026-09-24 12:04:50.891 [info] [127.0.0.1][9ec25671][ExtensionHostConnection] <67661> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-24 12:05:20.898 [info] [127.0.0.1][ddebcc3c][ExtensionHostConnection] <68302> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-24 12:18:20.894 [info] [127.0.0.1][fe2a555c][ExtensionHostConnection] <93145> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-24 12:18:50.909 [info] [127.0.0.1][e1e1c2f2][ExtensionHostConnection] <93400> Extension Host Process exited with code: null, signal: SIGKILL.
2026-09-24 12:19:20.929 [info] [127.0.0.1][59448c9d][ExtensionHostConnection] <93693> Extension Host Process exited with code: null, signal: SIGKILL.

17

Hey, thanks for coming back with logs. Your output confirms the same pattern the thread author saw: the remote extension host gets SIGKILL about every 30 seconds, glibc 2.36, and it’s not OOM.

What we see with this class of issues is that SIGKILL is coming from the server side (the host OS), not from Cursor. Cursor doesn’t kill its own remote extension host with SIGKILL. On many managed or shared hosts there’s a process monitor that force-kills processes that go over RAM limits or runtime limits. Starting with remote server 3.19, the Node.js runtime was updated and the footprint got a bit bigger. On these hosts it can cross a threshold that 3.18 stayed under. That also explains why rolling back to 3.18.x fixes it.

What can help you confirm and work around it:

  1. Ask your hosting provider if they run process monitoring or enforce per-process limits, and whether they killed your node processes at the SIGKILL times (based on timestamps in the log, like 12:04:50 / 12:05:20). If yes, ask them to add an exception for processes under ~/.cursor-server.
  2. Reduce the server footprint: open a smaller folder instead of your whole account, turn off Codebase Indexing and Index Repositories for Instant Grep for this remote workspace in Cursor Settings (not VS Code settings) > Indexing & Docs, and add large directories (uploads, caches, logs) to files.watcherExclude in Remote settings.
  3. Rolling back to 3.18.x is a working stopgap. To prevent auto-update from moving you back to a newer version, turn off auto-updates in settings (search for update).

We’re tracking this issue. I can’t share an ETA yet, but I’ll post in the thread when there’s an update.