How to SSH into HF Space Using Cursor?

Spaces
1

I’m trying to SSH into my HuggingFace Space using the Remote - SSH extension from Anysphere but the process is hanging (dies after 30 seconds). It works on VSCode, but I understand there are some differences between VS Code’s Remote - SSH extension and the one from Anysphere.

What I’ve tried:

  • Changing the prefix from “vscode” to “cursor” in the connect link (this step is necessary).

    • e.g. “cursor://vscode-remote/ssh-remote+<SPACE_NAME>@ssh.hf.space/home/user/app” instead of “vscode://vscode-remote/ssh-remote+<SPACE_NAME>@ssh.hf.space/home/user/app”

  • Increasing the timeout time (up to 5 minutes), still times out.

  • Playing around with additional Remote - SSH configurations in the settings.json (taken from VSCode extension settings)

    • all settings besides “connectTimeout” and “path” are greyed out with an “Unknown Configuration setting” message when hovered over. Are they even used in the Anysphere version?

    • "remote.SSH.connectTimeout": 30,
"remote.SSH.useLocalServer": false,
"remote.SSH.enableExecServer": true,
"remote.SSH.useFlock": true,
"remote.SSH.path": "ssh",

  • Confirming the Cursor server is being installed properly and is running on the HF Space

    • I SSH’d into the HF Space and confirmed that the processes were running with “ps aux | grep cursor” and that ~/.cursor-server was installed.

Still, I get this error (log level set to “Trace”):

2025-12-31 14:50:11.347 [info] Resolving ssh remote authority ‘<SPACE_NAME>@ssh.hf.space’ (Unparsed ‘ssh-remote+<SPACE_NAME>@ssh.hf.space’) (attempt #1)

2025-12-31 14:50:11.352 [info] SSH askpass server listening on /var/folders/ls/lk2x63852z1b7qh25yx5f3h40000gn/T/cursor-ssh-56t9dv/socket.sock

2025-12-31 14:50:11.352 [debug] hostname: ssh.hf.space, remote platform map: {“ssh.hf.space”:“linux”,“<SPACE_NAME>@localhost”:“linux”}

2025-12-31 14:50:11.353 [info] Using configured platform linux for remote host ssh.hf.space

2025-12-31 14:50:11.353 [debug] hostname: ssh.hf.space, remote server install map: {}

2025-12-31 14:50:11.353 [debug] hostname: ssh.hf.space, server port range map: {}

2025-12-31 14:50:11.353 [info] Using askpass script: /Users/landon/.cursor/extensions/anysphere.remote-ssh-1.0.36/dist/scripts/launchSSHAskpass.sh with javascript file /Users/landon/.cursor/extensions/anysphere.remote-ssh-1.0.36/dist/scripts/sshAskClient.js. Askpass handle: /var/folders/ls/lk2x63852z1b7qh25yx5f3h40000gn/T/cursor-ssh-56t9dv/socket.sock

2025-12-31 14:50:11.356 [info] Launching SSH server via shell with command: cat “/var/folders/ls/lk2x63852z1b7qh25yx5f3h40000gn/T/cursor_remote_install_bb27cc31-b979-4aa8-99c8-cd1ced44e4c5.sh” | ssh -T -D 50253 <SPACE_NAME>@ssh.hf.space bash --login -c bash

2025-12-31 14:50:11.356 [info] Establishing SSH connection: cat “/var/folders/ls/lk2x63852z1b7qh25yx5f3h40000gn/T/cursor_remote_install_bb27cc31-b979-4aa8-99c8-cd1ced44e4c5.sh” | ssh -T -D 50253 <SPACE_NAME>@ssh.hf.space bash --login -c bash

2025-12-31 14:50:11.357 [info] Started installation script. Waiting for it to finish…

2025-12-31 14:50:11.357 [info] Waiting for server to install. Timeout: 30000ms

2025-12-31 14:50:41.360 [error] Error installing server: Failed to install server within the timeout

2025-12-31 14:50:41.360 [info] Deleting local script /var/folders/ls/lk2x63852z1b7qh25yx5f3h40000gn/T/cursor_remote_install_bb27cc31-b979-4aa8-99c8-cd1ced44e4c5.sh

2025-12-31 14:50:41.362 [error] Error resolving SSH authority Failed to install server within the timeout

Has anybody ran into this issue and found a solution for it? It seems that at one point in time all you had to do was change the prefix to ‘cursor’ in the connect link, but now updates have made it more complicated.

I’d really like to use my Cursor IDE instead of VS Code if possible!

1 Like
2

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: 30000ms
  • Failed 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:

  • __PIPE_OK__

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 SSH
  • curl, 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:

  1. 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)

  2. In Cursor settings JSON (macOS user settings path), set:
    "remote.SSH.connectTimeout": 180 (Cursor - Community Forum)

  3. Reconnect. If it fails, run “Reinstall Server” in Cursor. (Cursor - Community Forum)

  4. 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)
3

I believe my issue is that the piped stdin over SSH is producing no output.

Things I’ve tried:

  1. killing all the Cursor processes
  2. removing all the Cursor server files
  3. reinstalling the server
  4. increasing timeout.

And the following command (ran from my Mac) just hangs:

printf ‘echo _PIPE_OK_\n’ | ssh -T <SPACE_NAME>@ssh.hf.space bash --login -c bash

Is this a separate issue that should be opened elsewhere?

1 Like
4

Hmm, I see. Dev mode is a relatively new feature and still prone to bugs, so you might want to contact HF. If you can’t get in touch, try emailing: [email protected]

If printf 'echo __PIPE_OK__\n' | ssh -T <SPACE>@ssh.hf.space … hangs, and the same hang happens with multiple remote programs that should read stdin, then you are outside “Cursor Remote-SSH quirks.” You are in “stdin over non-PTY SSH session is not reaching the remote process, or EOF never arrives.” That is exactly the failure mode reported for HF Spaces Dev Mode in upstream VS Code Remote-SSH too. (GitHub)

Hugging Face Dev Mode explicitly runs an SSH server in the Space container and expects IDEs to connect via SSH. (Hugging Face)
Cursor then relies on the same technique VS Code uses: it pipes an installer script into ssh -T … sh or similar. When stdin piping breaks, install “hangs then times out.”

1) First isolate what is actually broken: “stdin pipe” vs “login bash”

Your test uses Cursor’s exact remote command pattern: bash --login -c bash. That adds a second variable: login shell startup. In Cursor’s own forum, staff have identified .bashrc / interactive-only commands (like bind) as a cause of install hangs and timeouts. (Cursor - Community Forum)

Run this matrix from your Mac. Use straight quotes ' (not curly quotes) to avoid accidental shell nonsense.

A. Does plain remote exec work (no pipe)?

ssh -T <SPACE_NAME>@ssh.hf.space 'echo __EXEC_OK__'

Expected: prints __EXEC_OK__.
If this fails, it is not a stdin issue. It is basic remote exec, auth, or forced-command behavior.

B. Does stdin piping work with the simplest stdin consumer?

printf 'HELLO\n' | ssh -T <SPACE_NAME>@ssh.hf.space 'cat'

Expected: prints HELLO then exits.
If this hangs, you have the “stdin pipe doesn’t reach remote cat or EOF never arrives” problem.

C. Does piping work if the remote program is explicitly “read stdin as a script”?

printf 'echo __PIPE_OK__\n' | ssh -T <SPACE_NAME>@ssh.hf.space 'sh -s'

Expected: prints __PIPE_OK__ then exits.
This is the closest analog to how Remote-SSH bootstraps run.

D. Is it specifically login bash that hangs?

ssh -T <SPACE_NAME>@ssh.hf.space 'bash --login -lc "echo __BASH_LOGIN_OK__"'

Expected: prints __BASH_LOGIN_OK__.
If this hangs but A works, your .profile / .bash_profile / /etc/profile path is doing something that blocks in non-interactive mode.

E. Is it specifically Cursor’s “bash --login -c bash” shape?

printf 'echo __PIPE_OK__\n' | ssh -T <SPACE_NAME>@ssh.hf.space 'bash --login -c bash'

If C works but E hangs, then stdin is fine and the nested bash/login init path is your culprit.

2) Interpret results and apply the right fix

Case 1: A works, but B and C hang

This is the “stdin pipe over ssh -T is broken” class.

That is a known HF Dev Mode Remote-SSH problem in the VS Code tracker: normal SSH commands work, but type script | ssh -T … sh produces no output, and even echo "AAA" | ssh -T … "cat /dev/stdin" fails. (GitHub)

What to try next (to confirm it’s PTY-related):

printf 'echo __PIPE_OK__\n' | ssh -tt <SPACE_NAME>@ssh.hf.space 'sh -s'
  • If -tt works but -T fails, then the HF endpoint or its wrapper likely only behaves correctly when a PTY is allocated.
  • Cursor Remote-SSH uses -T for its bootstrap, so Cursor cannot work reliably until HF fixes non-PTY stdin, or Cursor adds an option to allow PTY allocation.

Where to report

  • This is best reported as a Hugging Face Spaces Dev Mode SSH endpoint bug, because you reproduced it with plain ssh outside Cursor.
  • Also comment on the existing VS Code Remote-SSH issue for HF Dev Mode, because it documents the same failure signature and gives maintainers a cross-reference. (GitHub)

Case 2: C works, but E hangs (and/or D hangs)

This is not “stdin piping is broken.” It is “login bash startup is blocking” or “nested bash is not exiting.”

Cursor staff have already diagnosed similar “install hangs at 30s” cases as .bashrc / interactive config emitting warnings or doing interactive-only work during non-interactive sessions. (Cursor - Community Forum)

Fix on the Space
Edit the shell init files used by non-interactive login:

  • ~/.bashrc
  • ~/.bash_profile or ~/.profile
  • possibly /etc/profile (less likely in HF containers)

Add an early return for non-interactive shells in ~/.bashrc:

# If not interactive, do nothing
case $- in
  *i*) ;;
  *) return ;;
esac

Then remove or guard anything like:

  • bind …
  • stty …
  • read …
  • prompt tooling that assumes a TTY

This aligns with the Cursor forum diagnosis that bind warnings can break non-interactive installs. (Cursor - Community Forum)

Case 3: Only fails when -D <port> is present

Cursor uses dynamic forwarding (-D) during bootstrap. If your “pipe works” tests omitted -D, add a control:

printf 'echo __PIPE_OK__\n' | ssh -T -D 50253 <SPACE_NAME>@ssh.hf.space 'sh -s'

If adding -D changes behavior, report that explicitly. It is high-signal.

3) “Should I open an issue elsewhere?” Yes, if you can show a minimal reproduction

If plain OpenSSH reproduces “piped stdin hangs” against ssh.hf.space, that is not a Cursor-only issue.

Best place(s) to file

  1. Hugging Face Forums (Spaces / Dev Mode)
    HF staff actively monitor these threads for infra issues, and Dev Mode is an HF feature. Your repro is specific to ssh.hf.space which is HF infrastructure. (Hugging Face)

  2. Comment on VS Code Remote-SSH issue #11296
    It already documents the same exact HF Dev Mode “piped script produces no output” behavior and includes a stdin pipe test (echo "AAA" | ssh -T … cat /dev/stdin). Add that you can reproduce it on macOS too, and include your command outputs. (GitHub)

  3. Cursor issue only if the root cause is “Cursor uses bash --login -c bash”
    If your matrix shows sh -s works but Cursor’s bash --login -c bash fails, that is a Cursor choice and may deserve a Cursor bug: “use sh -s like VS Code” or “avoid nested login bash” or “option to allocate PTY.”

4) What to include in a high-quality bug report (this is what maintainers need)

Include a paste of:

  • Your Space type (Docker vs Gradio vs Static) and whether Dev Mode is enabled (and whether persistent storage is enabled)

  • Your local ssh -V

  • Output of the matrix tests A–E (exact commands and whether they print or hang)

  • If possible, one ssh -vvv log for a failing command and one for a working command:

    • ssh -vvv -T <SPACE>@ssh.hf.space 'echo OK'
    • printf 'echo OK\n' | ssh -vvv -T <SPACE>@ssh.hf.space 'sh -s'

  • Whether -tt changes anything

  • Whether adding -D changes anything

That combination cleanly distinguishes:

  • “stdin channel is broken”
  • “non-PTY sessions behave differently”
  • “login bash init scripts block”
  • “dynamic forwarding triggers a policy/bug”

5) Practical workaround if you need Cursor today

If the endpoint truly cannot handle non-PTY stdin, Cursor Remote-SSH will remain unreliable because its bootstrap depends on stdin piping.

Workarounds:

  • Use VS Code Remote-SSH (it may have different knobs or a different bootstrap path).
  • Use SSHFS to mount the Space filesystem locally and open it in Cursor (editing locally, running remotely).

Summary

  • Reproduce with a command matrix to separate “stdin pipe broken” from “login bash blocks.” (Cursor - Community Forum)
  • If echo | ssh -T … cat hangs, it matches the HF Dev Mode Remote-SSH stdin/pipe bug reported upstream. (GitHub)
  • Report to Hugging Face (Spaces Dev Mode) and comment on the existing VS Code issue. (Hugging Face)
  • If only bash --login -c bash hangs while sh -s works, fix dotfiles or file a Cursor-specific issue about their remote command choice.