Cursor 3.24.9: Agent Host Bridge timeout on Remote SSH to Zaratan HPC 5

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent works normally in local folders but fails in every Remote-SSH window connected to the University of Maryland Zaratan HPC cluster.

Every Agent request fails with:

Timed out waiting for the agent host bridge to register; please retry.

Environment:

  • Cursor: 3.24.9 Universal
  • Commit: cd6d2a1f2e56e9841f0ed9c7c24542087b4e69b0
  • Local OS: macOS arm64 24.6.0
  • Remote OS: Red Hat Enterprise Linux 8.10
  • Remote connection: Anysphere Remote SSH 1.1.16

What works:

  • Agent in a local Mac folder
  • SSH authentication
  • Remote file editing
  • Zaratan terminal
  • Normal Remote-SSH connection

What I checked:

  • Storage quota is not exceeded.
  • /tmp has sufficient space.
  • Inode usage is normal.
  • I am using only 27 of my 256 allowed processes.
  • I stopped and restarted my Cursor remote processes.
  • I removed a stale Cursor installation lock.
  • Local and remote Cursor commits match.
  • cursorAgentHost.remoteInferenceRoute is set to always.
  • The Running Extensions screen shows cursor-always-local and cursor-socket.
  • No cursor-agent-host or cursor-agent-exec directory exists under ~/.cursor-server.

Command used:
find “$HOME/.cursor-server” -type d 2>/dev/null | grep -E ‘cursor-agent-(host|exec)’ | head -50

The command returned no output.

Request IDs:

  • ccc24220-de33-49ab-b491-6fbcbe5e2763
  • c12005c2-96b6-4da7-a525-5635f50e6f0e
  • c8a1f52a-d1a2-492d-b5af-ebe3010c50de
  • c7def8dd-c4c3-44e1-a373-9682f02b6cbc

Steps to Reproduce

  1. Open Cursor IDE 3.24.9 on macOS.
  2. Use “Remote-SSH: Connect to Host” to connect to the Zaratan HPC cluster.
  3. Open any folder on the remote system.
  4. Open Agent inside the Remote-SSH Cursor window.
  5. Start a new Agent conversation.
  6. Send a simple message such as “hello.”
  7. Wait for the request to process.
  8. Agent fails with “Timed out waiting for the agent host bridge to register; please retry.”

The same Agent works normally when I open a local folder on my Mac. The problem occurs only in the Remote-SSH window.

Expected Behavior

After connecting to Zaratan through Remote SSH, Cursor Agent should start normally, register the Agent Host Bridge, and respond to prompts such as “hello.” Agent should be able to access and work with files in the remote workspace without timing out.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.24.9 (Universal)
VS Code Extension API: 1.128.0
Commit: cd6d2a1f2e56e9841f0ed9c7c24542087b4e69b0
Date: 2026-10-08T05:37:28.393Z
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
Local OS: Darwin arm64 24.6.0
Remote OS: Red Hat Enterprise Linux 8.10
Remote extension: Anysphere Remote SSH 1.1.16

For AI issues: which model did you use?

Grok 4.7 High Fast

For AI issues: add Request ID with privacy disabled

c7def8dd-c4c3-44e1-a373-9682f02b6cbc

Other requests showing the same failure:
ccc24220-de33-49ab-b491-6fbcbe5e2763
c12005c2-96b6-4da7-a525-5635f50e6f0e
c8a1f52a-d1a2-492d-b5af-ebe3010c50de

Additional Information

Agent works normally when I open a local folder on my Mac. The problem occurs only inside a Remote-SSH window connected to the University of Maryland Zaratan HPC cluster.

SSH authentication, remote file editing, and the integrated terminal work normally. Storage, inode usage, /tmp space, and process limits are healthy.

I stopped and restarted my Cursor remote processes and removed a stale Cursor installation lock. The local and remote Cursor commits match.

I set cursorAgentHost.remoteInferenceRoute to always and reloaded the window. The Running Extensions screen shows cursor-always-local and cursor-socket, confirming that the setting was applied, but Agent still fails.

No cursor-agent-host or cursor-agent-exec directory was found under ~/.cursor-server.

Command:
find “$HOME/.cursor-server” -type d 2>/dev/null | grep -E ‘cursor-agent-(host|exec)’ | head -50

Result: no output.

I have attached a screenshot of the Running Extensions screen and the Agent connection error.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey @dlian_22, thanks for the detailed report and the request IDs. They made this much quicker to look into. The error you were seeing comes from the Agent component that runs inside the Cursor server on Zaratan. In Remote SSH windows, recent versions run the Agent on the remote machine, so if that part of the server doesn’t start, every request times out with that message even though SSH, editing, and the terminal all work. In the failing windows it wasn’t starting at all, even several minutes after connecting.

A couple of notes on what you tried:

  • cursorAgentHost.remoteInferenceRoute only changes how Agent requests reach our servers. It’s read by that same remote Agent component when it starts, so it can’t help if the component never starts. You don’t need it for this.
  • cursor-always-local and cursor-socket always run on your Mac, so seeing them in Running Extensions doesn’t tell us anything about the remote side.

From what we can see, Agent started responding normally in your SSH window a little after you posted, and your most recent requests all went through. Is it still working for you? And did you do anything right before it recovered, like reconnecting, reloading the window, or landing on a different login node?

If it happens again, could you grab these before changing anything:

  1. In the SSH window, run Capture and Send Debugging Data from the Command Palette (Cmd+Shift+P), then let me know here. If it saves a zip to your Desktop instead of uploading, attach that.
  2. On Zaratan, the output of hostname, df -T ~, and ls -ld ~/.cursor-server
  3. The output of find -L ~/.cursor-server -maxdepth 6 -type d -name '*cursor-agent*'. Your earlier find wouldn’t look inside ~/.cursor-server if it’s a link to another folder, which is common on clusters.

Then try a clean reinstall of the remote server, since the stale install lock you found suggests an earlier install may not have finished:

  1. Close the Remote SSH window in Cursor.
  2. SSH into Zaratan from a normal terminal and run pkill -u "$USER" -f cursor-server
  3. Run mv ~/.cursor-server ~/.cursor-server.old
  4. Connect again with Remote-SSH, wait for the window to fully load, and send a short Agent message.

This resets any Cursor settings saved on the remote side, but doesn’t touch your project files.

Thanks for investigating this. The Agent is currently not working. SSH, file editing, and the terminal still work, but Agent requests fail.

I ran “Capture and Send Debugging Data” from the affected Remote-SSH window.

Here is the requested Zaratan output:

(base) login-1:~$ hostname
login-1.zaratan.umd.edu

(base) login-1:~$ df -T ~
Filesystem                         Type  1K-blocks       Used  Available Use% Mounted on
fs-1.zaratan.umd.edu:/home/dlian   nfs4  4259966976 3165934592 879266816 79% /home/dlian

(base) login-1:~$ ls -ld ~/.cursor-server
lrwxrwxrwx. 1 dlian zt-niruroy-prj 68 Oct 5 14:43 /home/dlian/.cursor-server -> /scratch/zt1/project/niruroy-prj/user/dlian/home-cache/cursor-server

(base) login-1:~$ find -L ~/.cursor-server -maxdepth 6 -type d -name '*cursor-agent*'
/home/dlian/.cursor-server/bin/linux-x64/c4730f7d93d787d9ab120af715999f0345ee5bc0/extensions/cursor-agent-worker
/home/dlian/.cursor-server/bin/linux-x64/c4730f7d93d787d9ab120af715999f0345ee5bc0/extensions/cursor-agent-exec
/home/dlian/.cursor-server/bin/linux-x64/c4730f7d93d787d9ab120af715999f0345ee5bc0/extensions/cursor-agent-host
/home/dlian/.cursor-server/bin/linux-x64/cd6d2a1f2e56e9841f0ed9c7c24542087b4e69b0/extensions/cursor-agent-worker
/home/dlian/.cursor-server/bin/linux-x64/cd6d2a1f2e56e9841f0ed9c7c24542087b4e69b0/extensions/cursor-agent-exec
/home/dlian/.cursor-server/bin/linux-x64/cd6d2a1f2e56e9841f0ed9c7c24542087b4e69b0/extensions/cursor-agent-host
/home/dlian/.cursor-server/bin/linux-x64/37076c6c3f9e253c0fa2305197e45befd13a2260/extensions/cursor-agent-exec
/home/dlian/.cursor-server/bin/linux-x64/37076c6c3f9e253c0fa2305197e45befd13a2260/extensions/cursor-agent-worker
/home/dlian/.cursor-server/bin/linux-x64/37076c6c3f9e253c0fa2305197e45befd13a2260/extensions/cursor-agent-host
/home/dlian/.cursor-server/bin/linux-x64/2dac2428994fe34f12658d9ecad1541b98db2c00/extensions/cursor-agent-exec
/home/dlian/.cursor-server/bin/linux-x64/2dac2428994fe34f12658d9ecad1541b98db2c00/extensions/cursor-agent-worker
/home/dlian/.cursor-server/bin/linux-x64/2dac2428994fe34f12658d9ecad1541b98db2c00/extensions/cursor-agent-host
/home/dlian/.cursor-server/bin/linux-x64/8ae78e8eee1e63479c7e0504b664bc0a80c68000/extensions/cursor-agent-worker
/home/dlian/.cursor-server/bin/linux-x64/8ae78e8eee1e63479c7e0504b664bc0a80c68000/extensions/cursor-agent-exec
/home/dlian/.cursor-server/bin/linux-x64/8ae78e8eee1e63479c7e0504b664bc0a80c68000/extensions/cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261007T145056/exthost1/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261007T145056/exthost1/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261007T145056/exthost5/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261007T145056/exthost5/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost7/anysphere.cursor-agent-worker
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost7/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost7/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost6/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost6/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost3/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost2/anysphere.cursor-agent-worker
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost2/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261008T162419/exthost2/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261005T144937/exthost1/anysphere.cursor-agent-worker
/home/dlian/.cursor-server/data/logs/20261005T144937/exthost1/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261006T233619/exthost2/anysphere.cursor-agent-worker
/home/dlian/.cursor-server/data/logs/20261006T233619/exthost2/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261006T233619/exthost2/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261008T135700/exthost2/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261008T135700/exthost2/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/logs/20261007T141231/exthost3/anysphere.cursor-agent-host
/home/dlian/.cursor-server/data/logs/20261007T141231/exthost3/anysphere.cursor-agent-exec
/home/dlian/.cursor-server/data/User/globalStorage/anysphere.cursor-agent-worker
/home/dlian/.cursor-server/data/User/globalStorage/anysphere.cursor-agent-host

One important detail is that ~/.cursor-server is a symbolic link to scratch storage because my HPC home directory has a limited quota. Before I run the clean reinstall, should I rename the target directory and recreate the symbolic link, rather than running mv ~/.cursor-server ~/.cursor-server.old directly? I am concerned that renaming only the symbolic link would cause Cursor to reinstall the server directly into my home directory.