3.15.6 Remote-SSH Agent Execution Timed Out on Ubuntu 22.04 (linux-x64 / glibc 2.35)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Cursor 3.15.6, Remote-SSH connects successfully (file explorer + integrated terminal work), but Agent chat always fails with:

Agent Execution Timed Out
The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.

This is NOT the linux-legacy / old-glibc SIGSEGV case. Remote is Ubuntu 22.04.5, kernel 5.15, glibc 2.35, remote server artifact linux-x64.

remoteexthost.log: cursor-agent-exec never activates. After ~52s the local renderer sends terminate and the extension host exits code 0.

Local Agent works. Remote Agent is unusable. Split from Agent Execution Timed Out / Remote Extension Host crash loop on Remote-SSH — regression in 3.15.6, fixed by downgrading to 3.14.27 at @deanrie’s request.

Steps to Reproduce

  1. Windows 10 client, Cursor 3.15.6 commit a1f686545fd0ce8917bbd2449f733551a9bce420
  2. Remote-SSH to Ubuntu 22.04.5 host (glibc 2.35, kernel 5.15.0-173-generic, linux-x64 server)
  3. Open a remote folder (reproduced on a large Linux SDK ~14GB)
  4. Confirm terminal and file tree work
  5. Send any Agent prompt (even “hi”)
  6. Observe Agent Execution Timed Out; remoteexthost.log shows no cursor-agent-exec activation, then terminate from renderer

Expected Behavior

Agent/Composer should register cursor-agent-exec on the remote extension host and respond over Remote-SSH, as it does locally and as it did on Cursor 3.14.27.

Operating System

Windows 10/11

Version Information

Version: 3.15.6 (system setup)
Commit: a1f686545fd0ce8917bbd2449f733551a9bce420
OS: Windows_NT x64 10.0.19045
Workaround that works: Cursor 3.14.27 commit 047548b00c1a079373d74d00183f32510a4a41e0

For AI issues: which model did you use?

Cursor Grok 4.6 (also reproduced on trivial prompts; fails before backend)

Additional Information

Remote: Ubuntu 22.04.5 LTS, kernel 5.15.0-173-generic, glibc 2.35, linux-x64 (not linux-legacy-x64), local XFS /home, 1.5TiB RAM, 224 CPUs.

remoteexthost.log:

  • cursor-agent-exec never activates
  • sandbox preflight fails (Landlock V3 / no bwrap), then Sandbox support detected: false
  • vscode.lock EEXIST (another window held the workspace lock)
  • ~52s later: Extension host terminating: received terminate message from renderer, exit code 0

Please track this separately from the CentOS 7 / Debian 9 linux-legacy-x64 SIGSEGV thread. Split requested by @deanrie here: Agent Execution Timed Out / Remote Extension Host crash loop on Remote-SSH — regression in 3.15.6, fixed by downgrading to 3.14.27 - #8 by deanrie

Does this stop you from using Cursor

Yes - Cursor is unusable

5

@oula thanks for splitting this into a separate thread and for the detailed write-up. The logs, commit, env, and a working workaround are exactly what we need.

What you’re describing is something we’re already tracking. It’s separate from the legacy-glibc SIGSEGV issue. It’s specifically the linux-x64 case where the extension host stays alive, but cursor-agent-exec never activates. I passed your details to the team, and they’ll be added to the tracker. I can’t share a timeline yet.

A couple notes:

  • The sandbox preflight fail (Landlock V3 / no bwrap → Sandbox support detected: false) and the vscode.lock EEXIST are expected and benign, and they’re not related to the timeout. The root cause is that the provider never registers.
  • Downgrading to 3.14.27 is still a working workaround until there’s an update.

If you can, please attach the full remoteexthost.log from the remote host, not just a snippet. It really helps with this specific scenario.

I’ll post an update in the thread as soon as I have one.

7

@deanrie thanks for confirming this is a separate linux-x64 tracker item, and for asking for the full log.

Still on 3.14.27 as of 2026-08-17. Remote-SSH Agent remains unusable on 3.15.6 on this Ubuntu 22.04 / glibc 2.35 host. Any update we can pass along — even a rough “still investigating / next build” note — would help.

Full `remoteexthost.log` from the failing 3.15.6 session (`linux-x64` commit `a1f686545fd0ce8917bbd2449f733551a9bce420`, pid 3243367). There is no `_doActivateExtension anysphere.cursor-agent-exec` line. After `Eager extensions activated` it sits until the renderer sends terminate (~52s) and exits 0.

```
2026-08-15 06:55:40.267 [info] Extension host with pid 3243367 started
2026-08-15 06:55:40.267 [info] [ExtHostShellExec] Detecting sandbox support…
2026-08-15 06:55:40.267 [info] [ExtHostShellExec] Platform: linux, Shell type: unknown
2026-08-15 06:55:40.267 [info] [ExtHostShellExec] dirname: /home/oula/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/out/vs/workbench/api/node
2026-08-15 06:55:40.267 [info] [ExtHostShellExec] Sandbox helper path: /home/oula/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/resources/helpers/cursorsandbox
2026-08-15 06:55:40.267 [info] [ExtHostShellExec] process.resourcesPath: undefined
2026-08-15 06:55:40.267 [info] [ExtHostShellExec] process.execPath: /home/oula/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/node
2026-08-15 06:55:40.267 [info] [ExtHostShellExec] ripgrep path for sandboxing: /home/oula/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/resources/helpers/rg
2026-08-15 06:55:40.267 [error] Error: EEXIST: file already exists, open ‘/home/oula/.cursor-server/data/User/workspaceStorage/57752490634d19c2371719ea62150fd2/vscode.lock’
2026-08-15 06:55:40.267 [info] Lock ‘/home/oula/.cursor-server/data/User/workspaceStorage/57752490634d19c2371719ea62150fd2/vscode.lock’: Could not acquire lock, checking if the file is stale.
2026-08-15 06:55:40.268 [info] Lock ‘/home/oula/.cursor-server/data/User/workspaceStorage/57752490634d19c2371719ea62150fd2/vscode.lock’: The lock does not look stale, elapsed: 673 ms, giving up.
2026-08-15 06:55:40.269 [info] Lock ‘/home/oula/.cursor-server/data/User/workspaceStorage/57752490634d19c2371719ea62150fd2-1/vscode.lock’: Lock acquired.
2026-08-15 06:55:40.298 [info] [ExtHostShellExec] Probing sandbox support from /home/oula/ob_x5_linux_sdk
2026-08-15 06:55:40.299 [info] [shell-exec:sandbox] [checkBinaryAvailable] Resolved binary path: /home/oula/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/resources/helpers/cursorsandbox
2026-08-15 06:55:40.299 [info] [shell-exec:sandbox] [checkBinaryAvailable] Binary path exists: true
2026-08-15 06:55:40.300 [info] [shell-exec:sandbox] [sandboxPreflight] Running preflight with binary: /home/oula/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/resources/helpers/cursorsandbox
2026-08-15 06:55:40.300 [info] [shell-exec:sandbox] [sandboxPreflight] CWD: /home/oula/ob_x5_linux_sdk
2026-08-15 06:55:40.309 [info] [ExtHostShellExec] Default shell changed:
2026-08-15 06:55:40.311 [info] Eager extensions activated
2026-08-15 06:55:40.326 [info] ExtHostSearch [cursorIgnore] internal fileSearch start reason=cursorIgnoreCheck roots=1 include=**/.cursorignore maxResults=0 numThreads=(default) folderQueries=[{“cwd”:“/home/oula/ob_x5_linux_sdk”,“disregardIgnoreFiles”:true,“disregardParentIgnoreFiles”:true,“disregardGlobalIgnoreFiles”:true,“ignoreSymlinks”:false,“rgNoIgnore”:true,“rgNoIgnoreParent”:false,“rgNoIgnoreGlobal”:true,“rgFollow”:true}]
2026-08-15 06:55:40.333 [info] ExtHostSearch /home/oula/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/node_modules/@vscode/ripgrep/bin/rg --files --hidden --case-sensitive --no-require-git -g ‘**/.cursorignore’ -g ‘!**/.git’ -g ‘!**/.svn’ -g ‘!**/.hg’ -g ‘!**/.DS_Store’ -g ‘!**/Thumbs.db’ -g ‘!**/node_modules’ -g ‘!**/bower_components’ -g ‘!**/*.code-search’ --no-ignore --follow --no-config --no-ignore-global

  • cwd: /home/oula/ob_x5_linux_sdk
  • Sibling clauses: {}
    2026-08-15 06:55:40.334 [info] [ExtHostShellExec] Default shell changed: /bin/bash
    2026-08-15 06:55:40.880 [info] ExtHostSearch Search finished. Stats: {“cmdTime”:552,“fileWalkTime”:552,“directoriesWalked”:0,“filesWalked”:0,“cmdResultCount”:0}
    2026-08-15 06:55:40.881 [info] ExtHostSearch [cursorIgnore] internal fileSearch done in 555ms limitHit=false failed=false resultCount=0 cmdTime=552 fileWalkTime=552 providerTime=(unknown)
    2026-08-15 06:55:40.998 [error] [shell-exec:sandbox] [sandboxPreflight] Preflight failed: preflight exited with code 2
    2026-08-15 06:55:40.998 [error] [shell-exec:sandbox] [sandboxPreflight] Exit status: 2
    2026-08-15 06:55:40.998 [error] [shell-exec:sandbox] [sandboxPreflight] Stderr: Error: Failed to resolve Linux sandbox backend: Unsupported sandbox configuration: Linux auto backend selection failed. Landlock error: Unsupported sandbox configuration: Failed to apply Landlock: Step 5/7 (landlock) failed: Failed to apply Landlock: Landlock V3 filesystem restrictions not supported. Error: partially incompatible access-rights: BitFlags(0b110000000000000, Refer | Truncate). Ensure Landlock LSM is enabled (CONFIG_SECURITY_LANDLOCK=y) on a kernel with V3 support.. Bubblewrap error: Unsupported sandbox configuration: Unsupported sandbox configuration: Bubblewrap backend requested but no root-owned executable ‘bwrap’ was found on PATH

2026-08-15 06:55:40.998 [info] [ExtHostShellExec] Sandbox support detected: false, platform: linux, kernelVersion: 5.15.0-173-generic
2026-08-15 06:56:32.067 [info] Extension host terminating: received terminate message from renderer
2026-08-15 06:56:32.069 [info] Lock ‘/home/oula/.cursor-server/data/User/workspaceStorage/57752490634d19c2371719ea62150fd2-1/vscode.lock’: Marking the lockfile as scheduled to be released in 6000 ms.
2026-08-15 06:56:32.070 [info] Extension host with pid 3243367 exiting with code 0
```

Contrast on the same host with 3.14.27 today: the extension host does `_doActivateExtension anysphere.cursor-agent-exec, startup: true, activationEvent: ‘*’`.

8

Thanks for the full remoteexthost.log, that’s exactly what we were missing. It confirms what we suspected. After Eager extensions activated, there’s no activation of cursor-agent-exec at all, and about 52s later the renderer sends a terminate. The sandbox preflight (Landlock V3 / no bwrap) and the vscode.lock EEXIST aren’t related here. The root issue is that the provider isn’t registering, like we discussed.

I’ve shared the log and session details with the team. They’ve been added to what’s already being tracked for this linux-x64 case, separate from the legacy-glibc SIGSEGV. Unfortunately, there’s no ETA yet. As soon as we have anything concrete, even “still investigating” or “next build”, I’ll reply right here.

For now, please stick with 3.14.27. It’s a working workaround until an update lands. Let me know if it starts reproducing on 3.14.27 too.

9

@deanrie thanks. Confirmed: 3.14.27 still works on this same Ubuntu 22.04 / linux-x64 host as of 2026-08-17. Remote Agent does activate `anysphere.cursor-agent-exec` (`startup: true, activationEvent: ‘*’`).

I’ll stay on 3.14.27 and report back if that workaround ever breaks. Happy to retest a 3.15.x / later build as soon as you have one.

10

@deanrie this is the follow-up you asked for: **3.14.27 is now reproducing** on the same Ubuntu 22.04 / linux-x64 host (2026-08-20). SSH, explorer, and terminal still work; Remote Agent is unresponsive again.

Still on client/server **3.14.27** commit `047548b00c1a079373d74d00183f32510a4a41e0`. Did not upgrade.

This looks different from the original 3.15.6 case (primary EH never activated `cursor-agent-exec` at all). On 3.14.27:

  • The remote `cursor-server` multiplex process has been up since 2026-08-17 03:05 UTC (~3 days; `remote.SSH.serverShutdownTimeout` is 86400). Overnight there were many SSH reconnects.
  • The previous **primary** extension host (exthost85, pid 2669963) **did** activate agent-exec and held the primary `vscode.lock`:

```
2026-08-19 12:26:26.178 [info] ExtensionService#_doActivateExtension anysphere.cursor-agent-exec, startup: true, activationEvent: ‘*’
2026-08-19 12:26:27.583 [info] Extension activated success: anysphere.cursor-agent-exec — 1405ms
```

It died at 2026-08-20 01:53 UTC with `Extension host terminating: renderer disconnected for too long`. `remoteagent.log`: `<2669963> Extension Host Process exited with code: 0`.

  • At 01:48 UTC a **second client** connected (`Another client has connected` + `New connection established`). New EH exthost115 / pid 3672757 launched, failed the primary lock (`EEXIST`, not stale), and acquired `…/57752490634d19c2371719ea62150fd2-1/vscode.lock`.
  • That log **never** contains `_doActivateExtension anysphere.cursor-agent-exec`. It stops after `Default shell changed` (13 lines) and then sat idle ~40+ minutes while the process was still alive. The primary lock file was gone by then; only the `-1` lock remained.

Full current `remoteexthost.log` (exthost115):

```
2026-08-20 01:51:06.917 [info] Extension host with pid 3672757 started
2026-08-20 01:51:06.917 [info] [ExtHostShellExec] Detecting sandbox support…
2026-08-20 01:51:06.917 [info] [ExtHostShellExec] Platform: linux, Shell type: unknown
2026-08-20 01:51:06.917 [info] [ExtHostShellExec] dirname: /home/oula/.cursor-server/bin/linux-x64/047548b00c1a079373d74d00183f32510a4a41e0/out/vs/workbench/api/node
2026-08-20 01:51:06.917 [info] [ExtHostShellExec] Sandbox helper path: /home/oula/.cursor-server/bin/linux-x64/047548b00c1a079373d74d00183f32510a4a41e0/resources/helpers/cursorsandbox
2026-08-20 01:51:06.917 [info] [ExtHostShellExec] process.resourcesPath: undefined
2026-08-20 01:51:06.917 [info] [ExtHostShellExec] process.execPath: /home/oula/.cursor-server/bin/linux-x64/047548b00c1a079373d74d00183f32510a4a41e0/node
2026-08-20 01:51:06.917 [info] [ExtHostShellExec] ripgrep path for sandboxing: /home/oula/.cursor-server/bin/linux-x64/047548b00c1a079373d74d00183f32510a4a41e0/resources/helpers/rg
2026-08-20 01:51:06.917 [error] Error: EEXIST: file already exists, open ‘/home/oula/.cursor-server/data/User/workspaceStorage/57752490634d19c2371719ea62150fd2/vscode.lock’
2026-08-20 01:51:06.918 [info] Lock ‘…/57752490634d19c2371719ea62150fd2/vscode.lock’: Could not acquire lock, checking if the file is stale.
2026-08-20 01:51:06.924 [info] Lock ‘…/57752490634d19c2371719ea62150fd2/vscode.lock’: The lock does not look stale, elapsed: 264 ms, giving up.
2026-08-20 01:51:06.926 [info] Lock ‘…/57752490634d19c2371719ea62150fd2-1/vscode.lock’: Lock acquired.
2026-08-20 01:51:10.899 [info] [ExtHostShellExec] Default shell changed:
```

`remoteagent.log` around the switch:

```
2026-08-20 01:48:03.778 [info] … Another client has connected, will shorten the wait for reconnection 5m before disposing…
2026-08-20 01:48:03.779 [info] … New connection established.
2026-08-20 01:48:03.816 [info] … <3672757> Launched Extension Host Process.
2026-08-20 01:53:03.857 [info] … The reconnection short grace time of 5m has expired, so the connection will be disposed.
2026-08-20 01:53:04.148 [info] … <2669963> Extension Host Process exited with code: 0, signal: null.
```

Happy to recycle the remote server and retest a 3.15.x / later build when you have one.

11

Thanks for the detailed follow-up. This is exactly what I asked for, and the logs are really telling.

What you caught on 3.14.27 looks like a different scenario than the original 3.15.6 case. Here the primary extension host activated cursor-agent-exec normally and held the primary vscode.lock. Then a second client connected Another client has connected, a new extension host came up, the old one died with renderer disconnected for too long, and the new extension host couldn’t take the primary lock EEXIST, not stale. It fell back to ...-1/vscode.lock, and _doActivateExtension anysphere.cursor-agent-exec was never called. So the provider still doesn’t register, but the trigger here is client switching or overlap plus a stuck primary lock, not the deferred activation issue from 3.15.6.

I forwarded this to the team with the logs and the PID from your message. This matches what we’re already tracking, separate from the legacy glibc SIGSEGV. There’s no ETA yet. Once we have something concrete, I’ll reply right here.

For now, try this workaround for this specific case:

  • Close all remote windows and clients connected to that host. Make sure there isn’t a second client left connected.
  • From the Command Palette using Cmd+Shift+P or Ctrl+Shift+P, run the server kill command on the host, something like Kill Cursor Server on Host. Or kill the cursor-server process on the remote manually. This should clear the stuck primary lock and the old extension host.
  • Reconnect with a single client and check whether _doActivateExtension anysphere.cursor-agent-exec shows up again in remoteexthost.log.

A couple questions to narrow it down:

  • After killing the server and reconnecting with a single client, does the Remote Agent start working again?
  • Does the lock only happen when multiple clients overlap or reconnect, or can it also happen on a fresh single client connection?

Let me know how it goes. And like we said, I’d really appreciate a retest on 3.15.x or a newer build once you have something to try.

12

image
image671×321 23.4 KB
Same happens to me every day, it is annoying.
Version: 3.17.19
VS Code Extension API: 1.128.0
Commit: ae3a2b7231dd56194447fe4570dfdc61640b1e90
Date: 2026-08-24T06:42:14.583Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 6.8.0-138-generic

13

@deanrie answering the two questions from #11, plus a correction: the operator did not open a second Remote-SSH window.

Still on 3.14.27 (047548b00c1a079373d74d00183f32510a4a41e0). Did not upgrade. Same Ubuntu 22.04.5 / glibc 2.35 / linux-x64 host.

1. After killing the remote server and reconnecting with a single client, does Remote Agent work again?
Yes. On 2026-09-02 we recycled this user’s cursor-server / multiplex, cleared vscode.lock (primary and -1), and killed leaked local Windows ssh.exe tunnels. The fresh extension host activated:

ExtensionService#_doActivateExtension anysphere.cursor-agent-exec, startup: true, activationEvent: '*'
Extension activated success: anysphere.cursor-agent-exec — 9295ms

2. Does the lock only happen when multiple clients overlap, or also on a fresh single client?
There is one remote folder window. Extra local ssh.exe processes are Remote-SSH’s own SOCKS / multiplex tunnels, not a second editor and not Agent-created sessions (device SSH runs on the remote host).

What the logs call Another client has connected is a reconnect that could not reuse the old ManagementConnection.

2026-09-02 timeline (UTC):

  • 02:29: previous EH pid 2339118 died FatalProcessOutOfMemory / SIGABRT (7 OOMs in this multiplex session; EH VmPeak had reached ~122GB). New primary EH pid 68227 acquired the primary lock (old pid gone / stale) and did activate cursor-agent-exec.
  • 03:13+: local Remote-SSH log: Proxy connection timed out on the SOCKS multiplex ping (~every 30s). Explorer/terminal still looked connected; Agent could not reach the still-living EH.
  • 03:26:04: client opened a new ManagementConnection and launched EH pid 214397. Old connection e223d97a then disconnected. Server logged Another client has connected and shortened the 3h wait to 5m.
  • New EH failed primary vscode.lock (EEXIST, not stale, 311ms) and took .../0c0a28f2...-1/vscode.lock.

So the -1 lock reproduces on a single window when the local tunnel dies and the client comes back as a new connection while the old EH is still holding the lock. Same pattern as #10, without a second editor window.

Note: on this particular -1 EH, cursor-agent-exec did still activate (~15s). The user-facing timeout that day was the dead local SOCKS (Proxy connection timed out), not missing provider registration. The #10 case (secondary EH never called _doActivateExtension) is still the other failure mode.

Staying on 3.14.27. Happy to retest a 3.15.x / 3.18.x build when you have one.

14

@oula thanks for the detailed breakdown, the answers to both questions, and especially the correction about there not being a second window. The logs are very telling again.

Here’s how I see it now. This clearly looks like several different scenarios, not one:

  1. Original on 3.15.6 (linux-x64). The primary extension host does not call _doActivateExtension anysphere.cursor-agent-exec at all. The provider never gets registered, which is what we’re tracking.
  2. Case from #10. Reconnect or overlap plus a stuck primary vscode.lock, the secondary extension host gets the -1 lock and does not activate agent-exec.
  3. New from #13. The primary extension host dies with FatalProcessOutOfMemory or SIGABRT (7 OOMs in one session, VmPeak grew to about 122 GB), then the local SOCKS tunnel drops (Proxy connection timed out), and the client comes back with a new connection. Here cursor-agent-exec did activate, so the user-facing timeout that day came from the dead local SOCKS tunnel, not from the provider registration being missing.

Everything matches what you asked about. Recycling cursor-server plus clearing both vscode.lock files plus killing leaked local ssh.exe brings activation back. And yes, the -1 lock can happen even with a single window if the local tunnel dies and the client reconnects while the old extension host still holds the primary lock.

I also want to call out the OOM. VmPeak around 122 GB for a remote extension host is way too high, and it looks like that’s the upstream trigger for scenario #13. To narrow it down, can you share the list of extensions installed on the remote host? Heavy workspace scanners, for example the Python extension on a large SDK, can blow up extension host memory to those numbers. If you can, try temporarily disabling the heaviest remote extensions and see if VmPeak stays in a reasonable range.

I’ve passed all of this to the team with the logs and PID, including the answers, the single-window -1 lock repro, and the OOM and dead-SOCKS mechanism. No ETA yet, but as soon as we have something concrete I’ll reply right here.

For now the workaround is still the same one you confirmed. Close all clients connected to the host, kill cursor-server, remove both lock files, primary and -1, kill any stuck local ssh.exe, then reconnect with a single client. I’d also appreciate a retest on a fresh 3.18.x when it’s convenient.

@javiermarcon to figure out which scenario you’re hitting on 3.17.19, can you attach remoteexthost.log from the remote host? We’re looking for a line like _doActivateExtension anysphere.cursor-agent-exec. Also please share your environment details, remote OS, glibc version, and artifact type like linux-x64 or linux-legacy-x64. The log will make it obvious if it’s the same mechanism or something separate.

15

@deanrie here is the extension list and a correction on the memory numbers.

Remote extensions installed (~/.cursor-server/extensions) — only three third-party:

  • eamodio.gitlens-19.1.0-universal
  • llvm-vs-code-extensions.vscode-clangd-0.6.0-universal (clangd runs out-of-process, /usr/bin/clangd, ~855 MB RSS as its own child, not in the EH heap)
  • ms-ceintl.vscode-language-pack-zh-hans-1.128.0-universal

No Python / Pylance on the Cursor remote. Everything else activated is built-in: anysphere.cursor-agent-exec, cursor-retrieval, cursor-shadow-workspace, cursor-explorer, cursor-commits, cursor-checkout, cursor-mcp, vscode.git, vscode.github, typescript/json/markdown-language-features, merge-conflict, emmet, etc.

Correction on “122 GB”: that was VmPeak (virtual address space, V8 reservation). It is not resident. The real numbers:

  • Peak resident (VmHWM) of the EH: ~4.8 GB
  • Every crash is the V8 default heap limit, not host memory (host has 1.5 TiB free):
Mark-Compact 4048.8 (4139.1) -> 4042.8 (4147.6) MB ... (average mu = 0.320, current mu = 0.007)
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 3: v8::internal::V8::FatalProcessOutOfMemory
 5: v8::internal::Heap::CollectGarbage
  • Frequency on 3.14.27 (047548b): 7 heap OOMs in the 2026-08-31 server session, 17 in the 2026-08-21 session. Time-to-OOM varies a lot: pid 2311911 hit ~4 GB 452 s after start; pid 1768783 after ~4.7 h; pid 2339118 after ~14 h.
  • The EH started today at 03:29 UTC is at RSS 4.19 GB / HWM 4.8 GB after ~10 h, so it will most likely OOM again overnight. Steady growth, not a single spike.

Likely upstream cause — workspace shape, not an extension: the remote window is a multi-root workspace whose first root is /home/oula/ob_x5_linux_sdk (~14 GB Linux SDK), plus mowerware_rn2602 (3.6 GB / 37k files), mowerware_rl2601, dailylogs. Each EH log starts with Probing sandbox support from /home/oula/ob_x5_linux_sdk. The 452-second OOM (exthost108) was filled with GitLens Git local changes (working tree) activity right after start. Because in-process JS is the only thing that can hit the V8 heap limit, candidates are cursor-retrieval / file watching over the 14 GB root, vscode.git + GitLens over multiple repos, not clangd.

Plan on our side (will report back):

  1. Drop ob_x5_linux_sdk from the workspace roots (open only mowerware_rn2602) and watch VmRSS/VmHWM over a day.
  2. If it still climbs, disable GitLens on the remote and repeat.
  3. Retest a current 3.18.x once #1/#2 give a baseline.

Would it be possible for the remote EH to log heap usage, or for Cursor to raise/configure --max-old-space-size for the remote extension host? A 4 GB ceiling with a large multi-root workspace is going to keep taking the primary lock holder down, and every crash is another chance to end up on a -1 lock.

16

@deanrie one more data point that rules out both “heavy extension” and “workspace too large” as the cause: a side-by-side with VS Code on the same host, same user, same 14 GB root (/home/oula/ob_x5_linux_sdk), measured at the same moment (2026-09-02 13:28 UTC).

Cursor 3.14.27 remote EH (047548b) VS Code Stable remote EH (8b640eef)
Uptime 10 h 2 d 8 h
VmRSS 4.2 GB 1.1 GB
VmHWM (peak resident) 4.8 GB 1.1 GB
V8 heap OOMs 7 (this server session) + 17 (2026-08-21 session) 0 across 10 server sessions since 2026-08-07
Third-party extensions GitLens 19.1.0, clangd 0.6.0, zh-hans pack GitLens 19.1.0, Pylance 2026.3.1, Python, debugpy, cpptools 1.33.8, cmake-tools, makefile-tools, git-graph, Claude Code, zh-hans pack

VS Code carries the heavier extension set (Pylance + cpptools) over the same root and sits flat at 1.1 GB for two days. Cursor, with only three light extensions, grows to ~4.2 GB in ~10 hours and dies at the 4 GB default heap limit. Both sides run the same GitLens build, so GitLens is unlikely to be the culprit.

That leaves the in-process built-ins that only Cursor loads on the remote EH — anysphere.cursor-retrieval, cursor-shadow-workspace, cursor-agent-exec, cursor-explorer / cursor-commits — as the growth source, amplified by the large root.

Removing ob_x5_linux_sdk from the roots will stretch the time between crashes, but it looks like a Cursor-side leak rather than an environment problem. Happy to capture a heap snapshot from the remote EH (--inspect-port is already on) if that helps the team.

17

@oula, thanks for the extension list and for correcting the memory metrics. VmPeak vs VmHWM and VmRSS really matters here, it changes the picture.

The side-by-side test with VS Code on the same host, same user, and the same 14 GB repo root is very telling. It rules out two things at once: it’s not a too-large workspace, and it’s not a heavy third-party extension. VS Code with a heavier set (Pylance + cpptools) stays stable at 1.1 GB for two days and doesn’t crash, while the remote extension host in Cursor with three light extensions climbs to about 4.2 GB in about 10 hours and hits the default V8 heap limit. Same GitLens build on both sides, and clangd is out-of-process, so what’s left is in-process built-ins that Cursor loads on remote extension host only (cursor-retrieval, cursor-shadow-workspace, cursor-explorer and cursor-commits), amplified by the large repo root. This isn’t about your environment.

Also important: this is a separate mechanism from the original case where cursor-agent-exec fails to activate. Here the provider does activate, and the user-facing timeout happens later as a secondary effect. First you get OOM on the remote extension host, then the local SOCKS tunnel dies. We’re tracking this as a separate scenario.

So one request: please start a new thread specifically for memory growth and V8 heap OOM on the remote extension host. This thread originally is about cursor-agent-exec not activating, and we want to keep that separate. The memory growth issue is its own topic and has a different owner on our side. In the new thread, it’s enough to copy what you already gathered in #15 and #16:

  • side-by-side results vs VS Code (RSS and VmHWM, number of OOMs, extension sets)
  • the V8 heap OOM from remoteexthost.log (Reached heap limit)
  • the list of remote extensions and workspace details (multi-root, 14 GB repo root)
  • and the heap snapshot once you get it

Drop the link to the new thread here and I’ll pick it up right away and route it to the right place.

On your questions:

  • Heap snapshot on remote extension host via --inspect-port: yes, please capture it. The retained objects will show what’s growing in old-space, it’s the fastest way to narrow down the source.
  • I shared the requests for heap logging on remote extension host and a configurable --max-old-space-size with the team. I can’t promise timelines.

Your isolation plan (remove ob_x5_linux_sdk from the roots, disable GitLens if needed, then retest on a fresh 3.18.x) makes sense. Please share results when you have them. I also forwarded everything from #15 and #16, including logs and the PID, to the team. No ETA yet. As soon as we have something concrete, I’ll reply here.