Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Issue observed with Cursor IDE — Extension: Remote - SSH (anysphere.remote-ssh)
Remote SSH 1.0.51 and 1.0.52 pass the raw hex-encoded remoteAuthority string to OpenSSH as the SSH hostname, instead of decoding it to the real connection target (e.g. user@host). This is a regression from 1.0.49.
Saved workspaces use remoteAuthority like ssh-remote+, where is hex-encoded JSON (e.g. {“hostname”:“user@host”}). Extension 1.0.49 correctly resolved this and ran: ssh … user@host bash. Versions 1.0.51+ often run: ssh … bash, which fails immediately with:
ssh: Could not resolve hostname : No such host is known.
Logs show both resolved and unparsed authority as the same hex string (labeled “Unparsed”). Failure occurs in ~150ms with no password prompt. A normal Host entry in ~/.ssh/config does not help, because SSH is not given that host name.
Pinning/installing remote-ssh 1.0.49 restores correct behavior. 1.0.52 changelog does not document this authority-handling change.
Steps to Reproduce
-
Use an existing .code-workspace (or remote folder) that Cursor saved earlier with:
- “remoteAuthority”: “ssh-remote+<HEX_AUTHORITY>”
- folder URI: vscode-remote://ssh-remote+<HEX_AUTHORITY>/
where <HEX_AUTHORITY> encodes {“hostname”:“user@internal-host”}.
-
Connect with remote-ssh 1.0.49 — connection succeeds; logs show:
Resolving ssh remote authority ‘user@internal-host’ (Unparsed ‘ssh-remote+<HEX_AUTHORITY>’)
ssh … user@internal-host bash -
Update remote-ssh to 1.0.51 or 1.0.52 via Cursor Install Updates / extension gallery (auto-update, not pinned).
-
Reload the window or reconnect after the SSH tunnel drops.
-
Attempt to open the same workspace again.
-
Observe Remote - SSH log: Resolving authority ‘<HEX_AUTHORITY>’ (Unparsed ‘ssh-remote+<HEX_AUTHORITY>’), then ssh … <HEX_AUTHORITY> bash, then hostname resolution error and exit 255 in ~150ms.
Optional control: downgrade/pin to 1.0.49 — same workspace connects again with decoded host in the ssh command.
Expected Behavior
-
Remote SSH should parse hex-encoded remoteAuthority JSON and extract the hostname field before invoking OpenSSH.
-
The ssh command should use the decoded target (e.g. user@internal-host or a matching SSH config Host alias), not the literal hex string.
-
Logs should show the decoded target for SSH (as in 1.0.49), e.g.:
Resolving ssh remote authority ‘user@internal-host’ (Unparsed ‘ssh-remote+<HEX_AUTHORITY>’)
ssh -T … user@internal-host bash --login -c bash -
Connection should work with standard ~/.ssh/config Host entries for the real host, without requiring a Host block whose name equals the full hex authority string.
-
Reload Window / reconnect after tunnel loss should not change decoded behavior.
Operating System
Linux
Version Information
Version: 3.5.33 (system setup)
VSCode Version: 1.105.1
Commit: aac81804b986d739acab348ed96b8bea6e83cc50
Date: 2026-05-22T06:47:48.039Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631
Additional Information
1.0.51 / 1.0.52 pass <HEX_AUTHORITY> directly to ssh.
Connection fails with “Could not resolve hostname <HEX_AUTHORITY>”.
Host entries for the real internal host do not apply.
Workaround: add Host <HEX_AUTHORITY> with HostName pointing to the real host in ssh config, or pin extension to 1.0.49.
Does this stop you from using Cursor
No - Cursor works, but with this issue