Duplicate workspaces and duplicate repo groups for the same remote folder

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When opening the same remote folder /home/unitree/autonomy_stack_go2 over SSH, Cursor creates two separate workspace identities. In the Agent window, grouping chat history by Repo shows two entries both named autonomy_stack_go2.

The root cause is that Remote SSH uses two different string encodings for the same SSH host. They resolve to the same connection at runtime, but are stored as different folder URIs, producing different workspace IDs.

The two authority formats (same SSH host, different stored URI)

Format Authority in folder URI Workspace ID
JSON ssh-remote+{"hostName":"unitree"} (URL-encoded as ssh-remote+7b22686f73744e616d65223a22756e6974726565227d) 600f96f95f0f87b54b6b8bc25132badc
Alias ssh-remote+unitree 4b35f9a3611fe20318f41af9a8b5820f

Both point to the same remote path: /home/unitree/autonomy_stack_go2

Workspace IDs are MD5 hashes of the full folder URI string. Because the URI strings differ, Cursor permanently maintains two independent workspaces (state.vscdb, Agent history, etc.).

Key evidence: normalized at connect time, not at persist time

Remote - SSH logs show both formats resolve to the same authority unitree when connecting:

# JSON format
Resolving ssh remote authority 'unitree'
(Unparsed 'ssh-remote+7b22686f73744e616d65223a22756e6974726565227d')

# Alias format
Resolving ssh remote authority 'unitree'
(Unparsed 'ssh-remote+unitree')

Both ultimately use Host unitree from ~/.ssh/config and connect to the same machine. However, persistence uses the unparsed authority string in workspace.json and workspaceStorage, without canonicalization.

Additional evidence:

  • storage.json → profileAssociations only registers the JSON-format URI for this folder
  • The JSON-format workspace (600f96f9...) is actively used; the alias-format workspace (4b35f9a3...) appears only once in logs (2026-07-10 09:27)
  • The same duplication exists for other folders on the same host (fast_lio_ws, go2_art_ws)

Steps to Reproduce

I’m not sure how this came about—maybe it has something to do with using both the IDE and Agent Windows at the same time? I started with the Agent Window, then later opened the same folder in IDE mode, and it seems like that’s when this issue appeared.

Expected Behavior

  • ssh-remote+unitree and ssh-remote+{"hostName":"unitree"} should be canonicalized to one authority before workspace ID assignment
  • Same remote host + same remote path → one workspace
  • Agent repo grouping should not split history because of authority string differences

Operating System

Windows 10/11

Version Information

Version: 3.11.13 (user setup)
VS Code Extension API: 1.125.0
Commit: 3f21b08f0b436a07be29fbfe00b304fa15553350
Date: 2026-07-10T01:45:28.254Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

For AI issues: add Request ID with privacy disabled

Provide two IDs, corresponding respectively to the two different identities mentioned above.

dbd4137a-43a2-48fc-98fa-2f1a54f47cbc
1ecc84a1-23e4-4ef9-a934-2f2f1817613e

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed write-up. Your root-cause analysis is correct. This is a bug on our side: the workspace ID is computed as an MD5 of the full folder URI, and the remote authority isn’t canonicalized before hashing. So the alias form (ssh-remote+unitree) and the JSON form (ssh-remote+{"hostName":"unitree"}) produce two different IDs for the same host and path, and the Agents Window shows them as two repo groups.

Good news, no data is lost. The second workspace (4b35f9a3…) is still on disk under its own hash along with its chat history, nothing got overwritten. If you open the folder the same way every time (consistently pick the friendly alias unitree, and don’t mix the Agents Window connect flow with the classic Editor flow when they produce different authority encodings), everything will stay under one identity.

This is a known issue and it’s being tracked, both for the workspace ID and the duplicates in Agents Window. I can’t share a timeline for a fix yet. Once there’s an update, I’ll reply in the thread.