The Cursor Agent consistently times out with deadline_exceeded on my remote SSH machine. File editing, terminal, and code navigation all work perfectly — only the Agent fails. The Agent is working fine on the local. I tried reinstalling cursor, tried removing .cursor-server and .cursor directory on the remote but none of this is working.
Error:
{"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]
Hey, thanks for the detailed report with the request ID and environment details. That really helps.
This is a known issue. Cursor Agent uses a sandbox preflight check that doesn’t work well on NFS-mounted directories, like Amazon FSx in your case. The check times out, the handler doesn’t get registered, and you end up seeing deadline_exceeded.
Workaround: try opening the project from a local path on the remote machine, not from your NFS-mounted home. For example:
Copy the project to /tmp/myproject or another directory on the SageMaker instance’s local disk
Open that path via Remote SSH in Cursor
This avoids the issue because the sandbox preflight works fine on a local filesystem.
The team is aware of this NFS scenario, and your report helps with prioritization. There’s no timeline yet, but we’re tracking it.
Thanks for the response, The workaround does work, but it’s not sustainable for a shared multi-instance workflow. I don’t think this is purely an NFS limitation. I’d like to point out few things -
Two reasons:
It was working perfectly for me 2 days ago on the exact same setup — same instance, same FSx-mounted home directory, same project path.
My colleagues are actively using Cursor Agent right now on the same machine, with their home directories also mounted on the same FSx filesystem.
This suggests the issue is specific to my user session or account, not a blanket NFS incompatibility. Something changed on your backend side in the last 2 days that broke it for me specifically.
Could you investigate what changed for my account around that time? The Request IDs from my original post should help narrow it down:
Good point. If your teammates are working on the same FSx mount right now, and it was working for you 2 days ago, then NFS alone is probably not the cause. Sorry for the quick conclusion.
A few things that can help narrow it down:
Check the cursor-server version on the remote machine:
~/.cursor-server/bin/*/cursor-server --version
Ask your teammates to run the same command. It’d be useful to see if the commit hashes match.
Check if there are any stuck processes from previous sessions:
ps aux | grep cursor-server
If you see old ones, kill them before reconnecting.
If the first two don’t help, remove cursor-server and reconnect:
rm -rf ~/.cursor-server
Did Cursor update on your local machine in the last 2 days? When the client updates, it downloads a new cursor-server version to the remote. If your teammates are on an older client version, they might have a different server, which would explain the difference.
Also, for NFS environments, increasing the connection timeout can help:
"remote.SSH.connectTimeout": 120
I told the team this doesn’t look like a general NFS issue, and is more likely a regression or a session-specific bug. Let me know what you find. It’ll help narrow down the cause.
Hi, the workaround of moving the project folder to an instance-specific directory isn’t working either now. I need a prompt solution since I’m already using the Pro version. If this issue continues, I won’t be able to keep using Cursor.
The Cursor tool has become completely unusable despite my active membership. I’m currently unable to use it at all. Please assist in resolving this issue as soon as possible.
Hey, I can see the situation got worse. That’s frustrating that even the workaround with a local path stopped helping. To keep digging, I really need the diagnostics I asked for in my previous message. Without them it’s hard to find the root cause, especially since other users on the same server are working fine.
Can you run these commands on the remote machine and share the output?
Cursor server version (and ask one of your coworkers to run the same command so we can compare):
~/.cursor-server/bin/*/cursor-server --version
Stuck processes:
ps aux | grep cursor-server
Extension host logs:
ls -lt ~/.cursor-server/data/logs/ | head -20
If there are any stuck processes, kill them with kill -9 <PID>, then delete cursor-server completely and reconnect:
rm -rf ~/.cursor-server
Also, what version of Cursor is installed on your coworker’s local machine? If their client is on an older version, that could explain why it works for them but not for you, since the client installs its own cursor-server version on the remote machine when it connects.
Let me know what you get from the diagnostics and we’ll sort it out.
