Remote workspace (`--folder-uri` vscode-remote) does nothing + script hangs when Cursor already open

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When Cursor is already running and we launch it again with --folder-uri "vscode-remote://ssh-remote+HOST/path" and --profile, nothing happens in Cursor (no window opens, edited : focus does change ) and the launching script hangs at “Press Enter to continue”. When Cursor is closed, the same launch works correctly.

Steps to Reproduce

  1. Open Cursor with profile and workspace in error and ensre remote-ssh is connected.
  2. Run a script that launches Cursor with: --profile same profile --folder-uri "vscode-remote://ssh-remote+server/opt/folder" (or any SSH remote URI).
  3. Observe: nothing other than a focus change happens in Cursor (no new window, no workspace switch), script shows “Launching…” and “Press Enter to continue” then appears to hang (or requires switching back to terminal).
  4. Close Cursor completely, run the same launch again → works correctly (remote workspace opens).

Expected Behavior

  • When Cursor is already running, it should reuse the existing window and open the requested remote workspace in it (or open a new window if appropriate).
  • The launching script should not hang; it should return to its menu after launching.

Operating System

Windows 10/11

Version Information

Version: 2.5.25 (user setup)
VSCode Version: 1.105.1
Commit: 7150844152b426ed50d2b68dd6b33b5c5beb73c0
Date: 2026-02-24T07:17:49.417Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Composer 1.5

Additional Information

  • Nothing visible happens in Cursor when instance is already open.
  • Launching script hangs at Read-Host / “Press Enter to continue” (or focus is stolen so user can’t easily continue).
  • --new-window flag was tested; no change in behavior.

Workaround Attempts

  • Direct Start-Process -FilePath Cursor.exe -ArgumentList ... (no cmd) works when Cursor is closed, but would lose detached launch behavior (Cursor closes when terminal closes) – trade-off not acceptable.
  • Using cmd start achieves detached launch but causes the above failures when Cursor is already open.

Question for Cursor Team

Is there a documented/recommended way to launch Cursor with --folder-uri for SSH remotes from a script such that:

  1. Cursor survives when the terminal closes (detached), and
  2. It correctly opens the workspace when Cursor is already running?

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the report. This is a known pain point. --folder-uri with a vscode-remote:// URI isn’t handled correctly via the CLI when Cursor is already running.

A similar bug happened with dev containers in 1.6.26 and was fixed in 1.6.27, but the CLI has changed a lot since then. Now cursor opens the CLI agent by default instead of the IDE.

A couple questions so I can pass this to the team more accurately:

  1. Are you running cursor --folder-uri ... or Cursor.exe --folder-uri ...?
  2. When Cursor is closed and the launch works, does it open the IDE directly, or do you briefly see the CLI agent first?

The team is aware of issues handling vscode-remote:// URIs. There’s no timeline yet, but your report helps with prioritization.

Let me know the answers to the questions above and I’ll pass them along.

5

Hi @deanrie ,

Thanx for the quick response.

  1. Cursor.exe – via Start-Process cmd.exe -ArgumentList “/c”, “start \”\" \“C:\…\Cursor.exe\” --profile … --folder-uri …"

  2. IDE opens directly – no CLI agent first when Cursor is closed when the command is issued, at least that I can see.

6

Thanks for the answers, that’s exactly what I needed to know.

We’re aware of the issue with handling vscode-remote:// URIs, and the team is on it.

For now, as a temporary workaround, you can try killing the Cursor process before launching it via a script, if that fits your workflow. It’s not ideal, but it should work until there’s a fix.