Bug Report: Remote SSH extension v1.0.51 breaks Connect to Host

[eerixx (Eric)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After anysphere.remote-ssh auto-updated to version 1.0.51 (released May 22, 2026), the Remote SSH extension becomes completely non-functional. Clicking on any host in the “Connect to Host” list does nothing — no connection attempt, no error message, no feedback whatsoever.

Inspecting the logs reveals the root cause: the extension is passing a hex-encoded JSON string as the SSH hostname instead of the actual IP address:

ssh: Could not resolve hostname 7b22686f73744e616d65223a22726f6f744038392e3131302e38362e313535227d: -65540

Decoded, this is: {"hostName":"root@<ip>"} — the extension is serializing the host object to JSON and hex-encoding it instead of extracting the hostname string. SSH naturally cannot resolve this.

Rolling back to version 1.0.50 fixes the issue immediately.

Steps to Reproduce

1. Allow anysphere.remote-ssh to auto-update to v1.0.51
2. Open Command Palette → Remote-SSH: Connect to Host
3. Select any configured host or type user@host manually
4. Press Enter or click the host
5. Nothing happens

Expected Behavior

Cursor should initiate an SSH connection to the selected host as it did in v1.0.50 and earlier.
Log excerpt from Remote SSH output panel:

[info] Launching SSH server via shell with command: ... ssh -T -D 51058 7b22686f73744e616d65223a22726f6f744038392e3131302e38362e313535227d bash --login -c bash
[error] ssh: Could not resolve hostname 7b22686f73744e616d65223a22726f6f744038392e3131302e38362e313535227d: -65540
[error] SSH process exited (code 255) before connection was established

Operating System

MacOS

Version Information

Cursor IDE — latest stable as of May 22, 2026
anysphere.remote-ssh 1.0.51 (broken) / 1.0.50 (working)

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

This is not an isolated issue — multiple users reported the same problem on the same day the update dropped.

Workaround (for anyone hitting this):

# Remove broken version
rm -rf ~/.cursor/extensions/anysphere.remote-ssh-1.0.51

# Download and install v1.0.50
curl -L "https://downloads.cursor.com/production/extensions/73a45d83-83c7-4b22-bebf-c9130b0ab3f3/1.0.50/Microsoft.VisualStudio.Services.VSIXPackage" \
  -o /tmp/remote-ssh-1.0.50.vsix
mkdir -p /tmp/remote-ssh-unpacked
unzip -o /tmp/remote-ssh-1.0.50.vsix -d /tmp/remote-ssh-unpacked
cp -r /tmp/remote-ssh-unpacked/extension/. ~/.cursor/extensions/anysphere.remote-ssh-1.0.50/

Then disable Auto Update on the extension to prevent it from reverting.

Does this stop you from using Cursor

Yes - Cursor is unusable

[Nathan_Rensing]

I am also cut off from working because of this bug currently.

[Colin]

We’re releasing 1.0.52. Please give it a try and let us know if the issue is resolved!

[eerixx (Eric)]

Thanks for the quick turnaround on 1.0.52! Unfortunately the issue isn’t fully resolved yet.

The good news: the “Connect to Host” button is responsive again and the host selection works. However, the SSH connection still drops during the server installation phase:

[error] Error installing server: Failed to connect to the remote SSH host. Please check the logs for more details.
[error] Error resolving SSH authority Failed to connect to the remote SSH host. Please check the logs for more details.

So the UI regression from 1.0.51 is fixed, but the underlying connection issue persists in 1.0.52.

For reference, 1.0.50 still works perfectly on the same machine with the same hosts — so the regression is definitely somewhere between 1.0.50 and 1.0.52.

[eerixx (Eric)]

One more thing worth mentioning as additional context:

I found that SSH connection works fine when using an SSH config file (i.e. defining a named host in ~/.ssh/config and connecting through that). So it’s not a general SSH connectivity issue — it’s specifically the standard “Connect to Host” flow using direct user@host format that’s broken in 1.0.52.

The reason this matters beyond just convenience: all of my AI chat history in Cursor is tied to the workspace created via the direct user@host connection. If I switch to SSH config-based connections, a new workspace gets created and I lose access to all my previous AI conversations and context built up over time.

So the ask is really about stability of the direct Connect to Host method — not just getting SSH to work at all, but preserving the workspace and chat continuity that’s already there. Would be great to get this properly fixed rather than having to work around it with SSH configs and lose that history.

[eerixx (Eric)]

You can delete version 1.0.51 or 1.0.52, disable auto-update before doing so, install the old version 1.0.50, and use it stably. My text includes all the bash commands to make this easy

[Nathan_Rensing]

Thanks for the help. Hopefully this gets solved soon. I have been using 1.0.50 in the meantime.

[_weihongliang (魏弘量 weihongliang)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Remote-SSH 1.0.51/1.0.52 treats encoded ssh-remote authority as raw hostname

Describe the Bug

Cursor Remote-SSH sometimes stores remote authorities as hex-encoded JSON, for example:

7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d

This decodes to:

{"hostName":"root@devmachine"}

But anysphere.remote-ssh does not decode it before connecting. It directly runs:

ssh -T -D <port> 7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d bash --login -c bash

So OpenSSH fails with:

ssh: Could not resolve hostname 7b22686f...: nodename nor servname provided, or not known

Expected Behavior

Remote-SSH should decode the authority:

ssh-remote+7b22686f... -> {"hostName":"root@devmachine"} -> root@devmachine

and then invoke SSH with the decoded host:

ssh root@devmachine

The window title should also show:

[SSH: root@devmachine]

not:

[SSH: 7b22686f...]

Actual Behavior

Remote-SSH passes the encoded hex string directly to ssh, causing connection failure.

If I add a workaround alias in ~/.ssh/config, the connection works, but Cursor still displays the ugly hex string in the title bar:

autoshow_omni [SSH: 7b22686f...]

Repro Cases

I reproduced this with several previously opened remote workspaces:

7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d
=> {"hostName":"root@devmachine"}

7b22686f73744e616d65223a22726f6f7440746563682d7265706f72742d6368696e61227d
=> {"hostName":"root@tech-report-china"}

7b22686f73744e616d65223a22726f6f744064656d6f686f7374227d
=> {"hostName":"root@demohost"}

In all cases, Cursor tries to run SSH against the encoded string itself.

Logs

Example:

[info] Resolving ssh remote authority '7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d'
(Unparsed 'ssh-remote+7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d')

[info] Launching SSH server via shell with command:
cat ".../cursor_remote_install_....sh" | ssh -T -D 56246 7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d bash --login -c bash

[error] ssh: Could not resolve hostname 7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d

Another example with anysphere.remote-ssh-1.0.52:

[info] Resolving ssh remote authority '7b22686f73744e616d65223a22726f6f7440746563682d7265706f72742d6368696e61227d'
(Unparsed 'ssh-remote+7b22686f73744e616d65223a22726f6f7440746563682d7265706f72742d6368696e61227d')

[info] Launching SSH server via shell with command:
cat ".../cursor_remote_install_....sh" | ssh -T -D 55829 7b22686f73744e616d65223a22726f6f7440746563682d7265706f72742d6368696e61227d bash --login -c bash

[error] ssh: Could not resolve hostname 7b22686f73744e616d65223a22726f6f7440746563682d7265706f72742d6368696e61227d

Environment

• OS: macOS Darwin 24.6.0
• Cursor Remote-SSH: reproduced with anysphere.remote-ssh-1.0.51 and anysphere.remote-ssh-1.0.52
• SSH config aliases such as devmachine, demohost, and tech-report-china work correctly from the terminal

Workaround

Adding a fake SSH alias for the encoded authority makes the connection work:

Host 7b22686f73744e616d65223a22726f6f74406465766d616368696e65227d
  HostName ip
  IdentityFile 

But this is only a workaround and causes the title bar to display the encoded hex hostname.

Steps to Reproduce

.

Operating System

MacOS

Version Information

Remote-SSH 1.0.51/1.0.52

Does this stop you from using Cursor

No - Cursor works, but with this issue

[SeBsZ]

I also confirm I have this same issue with 1.0.52 still. Going back to 1.0.50 instantly fixes the project.

[Colin]

Hey all.

We’ve shipped 1.0.53. Can you give it one more try?

[Peter_Kleemann]

Hi Colin,

today I experienced the same issue as the users above.

The extension 1.0.53 installed yesterday and became active today with a reload of Cursor. Then my SSH connection broke and I cannot access my server with exact the same messages (“'Could not resolve hostname 7b22686f73744e61…”) - I found this bug report via the error message from the SSH log.

So, 1.0.53 was not a solution - at least for me.

I use Windows 11 in an enterprise environment.

With the 1.0.50 version I can do my job

CU, Peter

[Colin]

Hi all,

Sorry for the late reply!

We made a change in Remote-SSH 1.0.51 to validate SSH connection targets more strictly before passing them to ssh. That was intended to harden the extension against malformed/unsafe remote authority values.

It looks like that may have caused a compatibility issue with some previously saved SSH workspace entries!

When you encounter the Could not resolve hostname 7b2268... error, how are you opening the SSH workspace? For example:

• Clicking a recent workspace?
• Restoring a previous window/session?

If you start from a local Cursor window and run Cmd + Shift + P > Remote-SSH: Connect to Host... from the command palette, then enter or select the same SSH target, does that unblock you on 1.0.53?