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

Support Bug Reports
,
1

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

5

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

6

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

8

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.

9

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.

10

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

11

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

12

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

15

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

18

Hey all.

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

19

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.

Screenshot 2026-06-02 102226

With the 1.0.50 version I can do my job :slight_smile:

CU, Peter

20

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?

22

Hi Colin,

I’m still seeing this on Remote - SSH 1.1.3

How I open the workspace:
From the Cursor editor window → Recent projects → select my saved remote .code-workspace (SSH).
I am not using a fresh Remote-SSH: Connect to Host… flow for that session — I’m restoring the saved workspace entry.

What happens:
Output → Remote - SSH shows the hex authority passed straight to OpenSSH:

Resolving ssh remote authority ‘7b22686f73744e…’ (Unparsed ‘ssh-remote+7b22686f73744e616…’)

ssh -T … 7b22686f73744e616… bash …

ssh: Could not resolve hostname 7b22686f73744e616…: No such host is known.

Fails in ~100–150 ms with no password prompt.

What worked before:
1.0.49 decoded the same saved workspace and ran ssh ... root@<host> bash successfully.

Workaround that restores connectivity:
Re-install and pin 1.0.49.

So for saved workspace / Recent projects reconnect, the issue appears unfixed through 1.1.3.

Regards,
Ananya

23

Hey @Ananya_U!

Thanks for following up.

We don’t plan to go back and restore compatibility with previously saved workspace entries, but by reconnecting and resaving them, they’ll work going forwards.

24

I opened this thread on May 22. It’s been almost a month, there have been five-plus releases claiming fixes, and the issue is still not resolved for saved workspaces. I’m still pinned to 1.0.50 because everything from 1.0.51 onward breaks Connect to Host for my existing setups.

I want to push back on the current resolution. Telling users to “reconnect and resave” isn’t a fix — it shifts the cost onto us. Resaving a workspace loses the context tied to it, including the chat history inside each remote. So the guidance is essentially: lose your work to keep using the tool. That isn’t acceptable for anyone running a lot of servers.

And I say this as someone firmly in your corner. My company chose Cursor on purpose over Claude Code and the rest, I’ve spent a serious amount on this product, and I’ve personally brought a lot of people over to it and keep advocating for it. That’s why I keep showing up in this thread instead of quietly leaving.

I tested the latest version again today. One minute of the same hostname-resolution errors in the terminal, and I rolled back to 1.0.50.

Please either restore compatibility for previously-saved SSH workspaces, or ship a real migration path that keeps chat/context intact. Don’t close this out by asking your most loyal users to absorb the loss.

I’m raising this as one of your most active and loyal users. Please hear us out on this one.

Thanks.