Hmm…
Your log points to one narrow failure: Cursor successfully starts SSH, then its remote bootstrap script never reaches the “ready” state before a 30s watchdog fires.
That watchdog fires even though ~/.cursor-server exists, because Cursor is waiting for a very specific handshake from its installer. If the installer gets stuck on locks, dangling processes, slow cleanup, or stdin/pipe weirdness, you get exactly:
Started installation script. Waiting for it to finish…Waiting for server to install. Timeout: 30000msFailed to install server within the timeout
This is a common Cursor Remote-SSH failure mode. (Cursor - Community Forum)
Below is the fix path I would use for your HF Space case, in the order that tends to actually work.
0) Background: what Cursor is doing on HF Dev Mode
HF Dev Mode
HF Dev Mode exposes an SSH endpoint to your Space container and recommends using an SSH IDE (VS Code Remote-SSH in their docs). (Hugging Face)
Cursor’s Remote-SSH install model
Cursor (Anysphere Remote-SSH) installs a Cursor server under ~/.cursor-server on the remote and uses lock files in /tmp or /run/user/... to coordinate install state. Several Cursor staff posts say these lock issues are a primary cause of 30s install timeouts. (Cursor - Community Forum)
Key detail: Cursor uses a time-based lock and writes to the lock file every second from a background bash loop. If that bash process is left behind, future installs look “locked” and then time out. (Cursor - Community Forum)
1) First thing: force a clean remote state (this is the #1 real fix)
SSH into the Space using your terminal (the direct SSH that works). Then run the cleanup Cursor staff repeatedly recommend:
# Kill dangling bash subshells that keep the install lock alive
killall bash || true
# Kill the Cursor server if it's still running
pkill -f .cursor-server || true
# Remove the server install + lock files + leftover tarballs
rm -rf ~/.cursor-server /tmp/cursor-remote-lock.* /tmp/cursor-server-*.tar.gz
Why this specific set:
- Cursor staff explicitly say old
cursor-server processes can survive upgrades and block installs. (Cursor - Community Forum)
- Cursor staff explicitly say
killall bash fixes cases where the lock-writer bash loop is left behind. (Cursor - Community Forum)
- Cursor staff explicitly recommend deleting
~/.cursor-server and /tmp/cursor-remote-lock.* for stuck installs/timeouts. (Cursor - Community Forum)
Then reconnect in Cursor.
If you only do one thing, do this.
2) Make Cursor actually use a longer timeout (your log suggests it is not)
You said you increased timeout, but the log still shows 30000ms.
Cursor staff commonly recommend increasing:
"remote.SSH.connectTimeout": 120
…after clearing locks. (Cursor - Community Forum)
Two practical pitfalls:
Pitfall A: you edited the wrong settings.json
On macOS, Cursor user settings are typically here:
~/Library/Application Support/Cursor/User/settings.json (Qiita)
If you have profiles, Cursor tends to follow VS Code’s layout (profile-specific settings live under a profiles/<id> directory in the same tree). The VS Code settings doc explains that structure. (Visual Studio Code)
What to do
- Edit Cursor’s actual user settings JSON.
- Fully quit Cursor (Cmd-Q) and reopen.
- Reconnect and confirm the log prints a timeout > 30000ms.
Pitfall B: connectTimeout may not control the “install watchdog” in some builds
There are Cursor forum threads where users set remote.SSH.connectTimeout and still see “Failed to install server within the timeout”. (Cursor - Community Forum)
So: treat timeout increases as helpful, but not sufficient. The lock/process cleanup is the main lever.
3) Use “Reinstall Server” inside Cursor if cleanup alone does not stick
Cursor users report that clicking “Reinstall Server” reliably restores functionality when the lock/install state is wedged. (Cursor - Community Forum)
This is basically “Step 1” but done through Cursor UI, and it can also refresh mismatched server binaries.
4) Check for the HF-specific failure mode: piped stdin over SSH produces no output
Your log shows Cursor running a classic Remote-SSH bootstrap style:
- local script piped into SSH
- remote command is a shell that reads stdin
There is an upstream VS Code Remote-SSH issue for HF Dev Mode where:
Even though that report is on Windows, it is the same mechanism Cursor uses (script piped to ssh -T). If HF’s endpoint or your shell init causes stdin to behave oddly, Cursor will sit waiting for markers and hit 30 seconds.
Quick test from your local terminal (macOS)
Run this exact pattern:
printf 'echo __PIPE_OK__\n' | ssh -T <SPACE_NAME>@ssh.hf.space bash --login -c bash
Expected output:
If you get no output or it hangs, you have a “piped stdin” problem similar to the HF Dev Mode Remote-SSH issue. (GitHub)
If you do get __PIPE_OK__, piping works and your issue is much more likely locks, stale processes, or slow install/cleanup.
5) Reduce shell startup “noise” in non-interactive sessions
Cursor uses ssh -T (no TTY) and runs login bash (bash --login ...). If your login files print anything or do interactive-only actions, Remote-SSH handshakes can break.
This is not the top suspect for HF Spaces (usually clean), but it is a known real cause of “install script started, never completes.”
What to check on the Space:
~/.bashrc, ~/.profile, ~/.bash_profile/etc/profile, /etc/motd (less likely in containers)
If you have custom dotfiles, guard interactive-only logic.
6) Confirm your Space meets HF Dev Mode container expectations (Docker Spaces)
HF says Docker Spaces need:
bash for SSHcurl, wget, procps for the VS Code server process- and notes Dev Mode rules for Docker Spaces. (Hugging Face)
If your base image is extremely minimal, Cursor’s server installer can hit unexpected missing-tool paths (VS Code may succeed due to slightly different behavior).
7) Practical “do this now” checklist
In your position, I would do this exact sequence:
-
Remote cleanup (most likely fix):
killall bash; pkill -f .cursor-server; rm -rf ~/.cursor-server /tmp/cursor-remote-lock.* /tmp/cursor-server-*.tar.gz (Cursor - Community Forum)
-
In Cursor settings JSON (macOS user settings path), set:
"remote.SSH.connectTimeout": 180 (Cursor - Community Forum)
-
Reconnect. If it fails, run “Reinstall Server” in Cursor. (Cursor - Community Forum)
-
If it still fails, run the __PIPE_OK__ piped-stdin test. If that fails, you are in the HF Dev Mode “piped script produces no output” class of bug. (GitHub)
High-quality references to keep open while debugging
- Cursor staff fix: locks + broken install cleanup + connectTimeout (Cursor - Community Forum)
- Cursor staff fix: upgrade leaves old cursor-server running, blocks install; pkill + cleanup (Cursor - Community Forum)
- Cursor staff explanation of the lock-writer bash loop and why
killall bash helps (Cursor - Community Forum)
- HF Dev Mode doc: SSH connection, Docker Space requirements (Hugging Face)
- VS Code Remote-SSH issue on HF Dev Mode: piped-script command produces no output (GitHub)
- Cursor settings.json location on macOS (Qiita)
Links:
Summary
- Your failure is “Cursor server install/handshake timed out,” not “SSH auth failed.” (Cursor - Community Forum)
- The most effective fix is remote cleanup of dangling bash + locks +
~/.cursor-server. (Cursor - Community Forum)
- Make sure Cursor is reading your
remote.SSH.connectTimeout from the real macOS Cursor settings.json. (Qiita)
- If cleanup does not work, test whether “piped stdin into ssh -T” is broken for your Space, as seen in HF Dev Mode Remote-SSH reports. (GitHub)