Remote SSH extension host crashes on Minerva HPC (Out of memory / failed to spawn thread)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am using Cursor IDE with Remote SSH to connect to a remote HPC server (Minerva). The SSH connection initially succeeds, and the remote workspace opens normally. However, after a few seconds, Cursor shows the message:

“Remote Extension host terminated unexpectedly 3 times within the last 5 minutes.”

After this happens, the Cursor Agent stops working.

At first, the Agent panel shows “Waiting for extension host to respond”, and then it changes to:

Agent Execution Timed Out

At this point the agent becomes unusable.

After a few minutes, the log indicates that Cursor is trying to reconnect to the remote host automatically, but the reconnection fails. Cursor then prompts me to enter my SSH password again in order to reconnect to the remote system.

This cycle repeats:

SSH connects successfully
Remote extension host crashes
Agent stops working
Cursor attempts reconnection
SSH session resets and asks for password again

Because of this, I cannot reliably use the Cursor Agent in a remote SSH workspace.

Steps to Reproduce

Open Cursor IDE on Windows.
Connect to a remote server using Remote SSH.
Open a remote project folder.
Wait a few seconds after the workspace loads.

Cursor displays:

Remote Extension host terminated unexpectedly 3 times within the last 5 minutes.

Try to use Cursor Agent.
Agent first shows “Waiting for extension host to respond”, then “Agent Execution Timed Out”.
After a few minutes, Cursor attempts to reconnect to the remote host and asks for the SSH password again.

Expected Behavior

The remote extension host should start normally and allow Cursor Agent and extensions to run in the remote workspace.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

IDE:
Version: 2.6.20 (system setup)
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: add Request ID with privacy disabled

Request ID: 011737f9-4ec3-48a4-af71-d307076eb0d7
{“error”:“ERROR_CUSTOM”,“details”:{“title”:“Agent Execution Timed Out”,“detail”:“The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.”,“isRetryable”:false,“shouldShowImmediateError”:true,“additionalInfo”:{},“buttons”:[{“label”:“Reload Window”,“reloadWindow”:{}}],“planChoices”:}}
Agent Execution Timed Out [deadline_exceeded]
ConnectError: [deadline_exceeded] Agent Execution Timed Out
at vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:43805:12719
at async HJy.createExecInstance (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:43805:10479)
at async bTA (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34062:582888)
at async DJ.execute (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34263:6603)
at async _Ru.execute (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:43805:1323)
at async uMw.execute (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46878:2775)
at async v5u.buildComposerRequestContext (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46888:3965)
at async v5u.streamFromAgentBackend (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46888:5603)
at async v5u.getAgentStreamResponse (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46888:13663)
at async bMe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34329:17597)
at async Ea (vscode-file://vscode-app/d:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:45813:4826)

Does this stop you from using Cursor

Yes - Cursor is unusable

Thanks for taking a look at this issue.

I would like to add that Cursor works correctly when I am not using Remote SSH. When I open local files/projects, everything works perfectly. The AI agent functions normally and I can use it to process tasks without any problems.

The issue only appears when I connect to my remote server through SSH. After connecting, the remote extension host crashes, which causes the agent to stop responding and eventually show “Agent Execution Timed Out.”

Because the agent works reliably in local projects but fails only in Remote SSH sessions, I suspect the problem might be related to the SSH extension or the remote extension host environment, rather than the agent functionality itself.

Please let me know if there are additional logs or diagnostic information that would help investigate this issue.

Hey, thanks for the report and the detailed logs. This is a known issue with Remote SSH on HPC clusters.

The root cause is likely the sandbox preflight check cursorsandbox failing on Minerva because HPC environments typically restrict user namespaces max_user_namespaces = 0 and enforce strict memory limits. When the sandbox fails, the extension host crashes instead of falling back gracefully, which is why you see Agent Execution Timed Out.

A few things to try:

If you have sudo access, unlikely on HPC but worth checking:

sudo sysctl -w kernel.unprivileged_userns_clone=1

Or set setuid on the sandbox binary:

sudo chown root: ~/.cursor-server/bin/linux-x64/*/cursorsandbox
sudo chmod 4755 ~/.cursor-server/bin/linux-x64/*/cursorsandbox

If you don’t have sudo, most likely on Minerva:

  • Ask your HPC sysadmin if they can enable kernel.unprivileged_userns_clone=1 or increase max_user_namespaces on login and interactive nodes
  • Try requesting a compute node with more memory, if you’re on a login node with tight limits the extension host may OOM

To help investigate further, could you share:

  • Kernel version on the remote: uname -r
  • User namespace status: cat /proc/sys/user/max_user_namespaces
  • Extension host logs from ~/.cursor-server/data/logs/, the most recent folder

Similar report from another HPC user for reference: SSH Remote to HPC Error: Remote Extension host terminated unexpectedly 3 times within the last 5 minutes

The team is aware of this class of issues on restricted Linux environments. No ETA on a fix yet, but your report helps with prioritization.

looks like it has been fixed in the latest version which is 2.6.21

It happened again, but this time it happened an hour after I started using the cursor.

uname -r:
5.14.0-570.58.1.el9_6.x86_64

cat /proc/sys/user/max_user_namespaces:
6191235

~/.cursor-server/data/logs/:

Attach the latest folder

20260324T094111.zip (40.2 KB)

Hey, thanks for the logs and diagnostics. I can see you’re on kernel 5.14 and user namespaces aren’t restricted, so the original idea about namespace restrictions doesn’t look right.

Good news, we fixed a bug in the sandbox fallback over the last few days that was causing these timeouts on some Linux setups. The fix should be included in one of the next updates.

Once the next version is out, please update and check if you can still reproduce the issue. Let me know how it goes.

Hey @kaniel_quits!

The agent execution timeout on Remote SSH has been addressed in a recent Cursor update. Updating to the latest version should resolve this.

Still have this issue after I updated to the latest cursor.

Hi @mohitjain and @deanrie

I updated Cursor to the latest version, but the issue still persists.

I want to clarify one important detail: I can log into the same Minerva host successfully from my local terminal using normal SSH. So basic SSH access itself is working.

However, inside Cursor Remote SSH, the problem still occurs:

  • the Remote Extension host terminates unexpectedly

  • the Agent still times out

  • and now I also get:

    • “The terminal process failed to launch: forkpty failed”

So this seems to be specifically a Cursor Remote-SSH / remote extension host / PTY issue, not a general SSH login issue.

In other words:

  • Plain terminal SSH works

  • Cursor Remote SSH workspace does not work correctly

This suggests the failure happens after SSH login succeeds, when Cursor tries to start its remote extension host / terminal backend on the remote machine.

From previous logs, I also observed:

  • failed to spawn thread: Resource temporarily unavailable

  • JavaScript heap out of memory

  • forkpty failed

Please let me know if you want a fresh diagnostic bundle from the latest version.

Thanks for the detailed follow-up and the screenshot.

The fix that was shipped in the recent update addressed a specific scenario with the sandbox initialization, which appears to be different from what you’re running into. Your errors (failed to spawn thread, JavaScript heap out of memory, forkpty failed) point to the remote extension host hitting resource limits on the HPC node rather than a sandbox issue.

Since this is a distinct problem from what this thread originally tracked, could you create a new thread so our team can investigate it properly? Please include:

  1. ulimit -a output from the Minerva remote host

  2. ps aux | grep cursor output (to check for stale cursor-server processes from previous sessions)

  3. Fresh extension host logs from ~/.cursor-server/data/logs/ (latest folder)

  4. Your current Cursor version

  5. Whether you’re connecting to a login node or a compute node

In the meantime, a couple of things worth trying:

  • Disable Codebase Indexing for the remote workspace (Cursor Settings > Indexing & Docs > Codebase Indexing) to reduce memory pressure on the remote host

  • Kill any leftover cursor-server processes on the remote before reconnecting: pkill -f cursor-server

@mohitjain

Thanks for the guidance.

I’ve created a new thread with all the requested information (ulimit output, processes, logs, environment details, etc.) so your team can investigate further.

In the meantime, I also tried the two suggested steps:

  • Disabled Codebase Indexing for the remote workspace

  • Killed leftover cursor-server processes before reconnecting

Unfortunately, neither of these resolved the issue. The same problems persist:

  • Remote extension host crashes

  • Agent execution times out

  • Terminal fails to launch with forkpty failed

Please let me know if there are additional things I can try or provide.

Thanks again for your help!

Thanks for following up and creating the new thread!

@deanrie has already identified the root cause over in your new thread – the max user processes limit on Minerva is set to 256, which is too low for Cursor’s remote server processes. Getting your HPC admin to raise that limit should resolve all three symptoms (extension host crashes, agent timeouts, and forkpty failed).

Let’s continue the conversation over there.

Thanks for helping!

I have solved that issue with your help.

Thanks again!