After the cursor_agent_host rollout, Agent over Remote SSH became unusable/extremely slow on my HPC compute node. Same SSH config + same Ceph project used to be fast. Local (non-SSH) Agent still works.
Symptoms over Remote SSH:
Stuck on “Planning next moves”
Connection Error
agent_host_bridge_unavailable: “Timed out waiting for the agent host bridge to register”
When it works, TTFT often 30–60+ seconds, then degrades after a few messages
Editor/terminal/files still work. Only Agent is broken/slow.
Remote SSH successes with very high TTFT (~59s, ~67s) in same environment
Remote: Debian 5.10, node g105 via ProxyJump, /home on Ceph.
Sandbox preflight fails (no Landlock V3 / no bwrap).
curl https://api2.cursor.sh from remote returns HTTP/2 200.
Please disable cursor_agent_host for my account or restore the previous local-client Agent path for Remote SSH on Ceph/HPC.
Steps to Reproduce
On Mac Cursor 3.23.23, connect Remote-SSH to HPC compute node (ProxyJump login node).
Open a project under Ceph home (e.g. ~/projects).
Wait until Running Extensions finishes (remote agent extensions may take 15–20s or hang on Activating).
Open Agent and send a short prompt (“hi”).
Observe: stuck on Planning next moves / Connection Error / agent_host_bridge_unavailable, OR reply only after 30–60+ seconds.
Send a few more messages: sometimes works briefly, then becomes stuck/slow again.
Compare: same Agent prompt in a local (non-SSH) window works quickly.
Expected Behavior
Agent over Remote SSH should work like before the cursor_agent_host change: fast and reliable, with AI traffic via the local Cursor client, even when the remote home is on Ceph and the kernel lacks Landlock V3/bwrap. Editor-only Remote SSH already works; Agent should not hang or take ~1 minute for first token.
Version: 3.23.23
VSCode Version: 1.128.0
Commit: 2dac2428994fe34f12658d9ecad1541b98db2c00
Date: 2026-10-05T01:43:43.807Z
Electron: (see Help → About if needed)
OS: Darwin arm64 25.6.0 (macOS)
CLI: n/a (issue is Desktop IDE Remote-SSH Agent)
For AI issues: which model did you use?
Default / Auto (reproduced across models; not model-specific). Local Agent works; Remote SSH Agent fails/slows.
Hey, thanks for the detailed report and the request ID. I can see both screenshots with the errors agent_host_bridge_unavailable and high TTFT.
What changed is that on newer versions, Agent runs inside Cursor server on the remote machine, not in the local app. From your logs, the model responds in a couple of seconds, but each request waits a long time on the remote side before it gets sent. Both errors in the screenshots point to the agent component on the remote side not starting within the allowed time. This is not something wrong with your setup, and it matches well with home being on a network file system like Ceph, since both Cursor server and its data live in ~/.cursor-server.
There are 2 options here, you can try either one or both.
Check the Ceph hypothesis by running Cursor server from node-local disk:
Close the Remote SSH window in Cursor.
SSH into g105 from a normal terminal and run: pkill -u "$USER" -f .cursor-server
Run: mv ~/.cursor-server ~/.cursor-server.bak
Pick a directory on the node-local disk, not Ceph, for example /tmp/$USER or the cluster’s local scratch, then run: mkdir -p /tmp/$USER/cursor-server && ln -s /tmp/$USER/cursor-server ~/.cursor-server
Reconnect to g105 over Remote SSH and wait for the remote extensions to finish loading.
Open a new Agent chat and send hi.
Does the reply come back quickly? This only works while you connect to the same node. To roll it back, run: rm ~/.cursor-server && mv ~/.cursor-server.bak ~/.cursor-server.
Go back to the previous agent setup:
I can switch your account back to the older local-client path for Remote SSH. After that, fully quit Cursor with Cmd+Q and open it again so the change applies, then reopen the SSH window. Let me know if you want me to do that.
In either case, these diagnostics would help a lot:
The output of df -T ~ /tmp and uptime on g105
A screenshot of Command Palette > Developer: Show Running Extensions in the SSH window, so we can see how many remote extensions are activating
I already tried option 1 (symlink ~/.cursor-server → /tmp/… on local ext4). It helped a bit with extension activation, but Agent is still slow/intermittent (high TTFT, sometimes Planning forever / bridge timeout).
Please switch my account back to the older local-client path for Remote SSH (option 2).
Diagnostics:
df -T ~ /tmp
Filesystem Type 1K-blocks Used Available Use% Mounted on
…:/home ceph … 84% /home
/dev/mapper/g105–vg-root ext4 … 62% /
Thanks for digging into this. It helped narrow things down:
Node g105 is basically idle with a load average of 0.44, so this doesn’t look like a load issue on that machine.
Even after moving ~/.cursor-server to local ext4, the remote extensions still take 6 to 11 seconds to activate (cursor-agent-host ~6.8s, Emmet ~11s, retrieval ~10.5s). So the symlink only helped partly. Ceph makes it worse, but it isn’t the only factor.
This doesn’t look like something wrong in your setup. I’ve passed it to the team along with your timing data and the request to restore the previous local-client path for Remote SSH. I’ll update you here once I hear back.
