Split from parent thread topic 168464 at deanrie request (post #17). This is the memory-growth / V8 heap OOM path. cursor-agent-exec DOES activate; the user-facing timeout is secondary after OOM.
Still on Cursor 3.14.27 commit 047548b00c1a079373d74d00183f32510a4a41e0. Did not upgrade.
Two crashes on the same install:
Remote extension host (Linux). Same host/user/large SDK root vs VS Code (2026-09-02): Cursor EH VmRSS 4.2GB / VmHWM 4.8GB in 10h then FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory (Mark-Compact ~4048 MB). VS Code same root: 1.1GB for 2d8h, 0 OOMs. Cursor third-party: GitLens 19.1.0, clangd (out of process), zh-hans. VS Code has heavier Pylance+cpptools. Same GitLens both sides.
Local renderer (Windows) 2026-09-17 16:13 CST. Dialog: window terminated unexpectedly (reason: oom, code: -536870904) = Chromium 0xE0000008. Renderer pid 41392 started 2026-09-16 11:34 (~28h; already ~1.6GB RSS the previous evening). Cursor wrote %APPDATA%\Cursor\debugging-data\renderer-41392-1789632806844.heapsnapshot but the file is 0 bytes (process died while writing). Crashpad reports folder empty.
Remote EH memory should stay near VS Code on the same repo (~1.1 GB, no V8 OOM). Local renderer should not die with Chromium oom. A renderer heap snapshot taken at crash should be a non-empty .heapsnapshot that can be uploaded.
deanrie asked for a separate thread plus a heap snapshot. Snapshot path: %APPDATA%\Cursor\debugging-data\renderer-41392-1789632806844.heapsnapshot — size 0 bytes. Happy to recapture via Command Palette then Capture and Send Debugging Data (Renderer heap snapshot) before the next crash if a 0-byte file is not useful.
Parent thread is topic 168464 (linked once in the description).
Hey, thanks for splitting this into a separate thread, and especially for the side by side numbers and the GC trace. They make the situation much easier to read right away. From the screenshots I can see both the dialog window terminated unexpectedly (reason: oom, code -536870904) and the memory comparison Cursor vs VS Code on the same root.
There are two separate stories here.
Heap growth in the remote extension host.
A steady increase up to the 4 GB ceiling with a light set of third party extensions, while VS Code on the same root stays flat, points to something in process on our side. We don’t know which component yet. The fastest way to identify it is a heap snapshot from the remote extension host, so yes, that would help a lot. One important detail. Take the snapshot when the host is around 1.5 to 2.5 GB, not at 4 GB. The snapshot generator needs a lot of extra memory, and near the ceiling it can take the process down with it. That is exactly what happened with your renderer snapshot. Two snapshots a couple hours apart are even better so we can diff them and see what grew.
On the remote host, find the extension host pid: pgrep -u $USER -f 'type=extensionHost'
Run kill -USR1 <pid>. The host already starts with --inspect-port=0, so it will open an inspector on a random port. Find it with ss -ltnp | grep "pid=<pid>" Also it gets logged as Debugger listening on ws://127.0.0.1:<port>
Port forward: ssh -L <port>:127.0.0.1:<port> <host>, then in Chrome open chrome://inspect, go to Configure, add localhost:<port>, pick the extension host target, then Memory tab, Take snapshot
Gzip the .heapsnapshot and attach it here along with the pid and RSS at capture time. It can include content from files in your workspace, so if you’d rather, you can send it privately.
A 0 byte renderer snapshot.
Its timestamp matches the crash down to the second, so the capture itself pushed the window over the limit. This isn’t anything on your side. It shouldn’t happen, and I’ve passed it to the team. If you need a working renderer snapshot, run Capture and Send Debugging Data and check the Renderer heap snapshot box while the window is around 1.5 to 2 GB, before the high memory toast shows up. For your account the upload happens automatically, just tell me what time you ran it.
Two temporary workarounds:
On 3.14.27 you can raise the remote host ceiling. Export NODE_OPTIONS=--max-old-space-size=8192 in your login shell environment on the remote host, for example in ~/.profile, then run Kill Cursor Server on Host from the Command Palette and reconnect. To verify: tr '\0' '\n' < /proc/<pid>/environ | grep NODE_OPTIONS. This only buys more time between restarts, and on newer versions NODE_OPTIONS is no longer passed through, so treat this as a 3.14.27 only measure.
For the local Agents window, doing Developer: Reload Window daily, or closing and reopening it, resets the renderer. There have been improvements in recent versions in how this window holds conversation data, so once the Remote SSH activation issue from the other thread is resolved and you can move off 3.14.27, this should get easier on that side too.
Waiting on the snapshot. Once you attach it, we’ll dig deeper.
