Follow-up to #1092. Do this once that PR lands in v1.16.2.
Background
v1.16.1 gave each editor its own SSH host prefix, so Cursor workspaces moved from coder-vscode. to coder-cursor.. That prefix is part of the remote authority, and editors key workspaceStorage off a hash of the folder URI, so the move gave every existing workspace a new identity and its per-workspace state, including Cursor's agent chats, was left behind under the old one.
#1092 stops the renaming: legacy authorities stay supported, and opening a workspace reuses the host it was last opened on. Anyone who already moved recovers by reopening the workspace from File > Open Recent and picking the pre-1.16.1 entry.
Proposal
Make that recovery self-serve with a palette command, Coder: Reopen on Previous Host. It does deliberately, once, what the removed migrateLegacyAuthority did automatically, with the prefix swap inverted: take this window's folder or saved workspace URI, swap coder-<editor>. back to coder-vscode., and reopen it with vscode.openFolder.
- Needs one function next to
retargetRemoteAuthority: toLegacyAuthority(authority).
- Gate it behind a context key set when the window is connected on a
current authority in an editor whose id is not vscode, so it never appears in VS Code proper, where both prefixes are the same string.
- It moves no data. The state already exists under the old address; the command just opens the workspace there.
Once the user runs it, the legacy entry becomes the most recent, so the Coder panel keeps taking them there afterwards. Their choice sticks without a permanent rule that favours the older identity, which is why #1092 keeps recency as the tiebreak when a folder has entries on both hosts.
Not doing
Preferring the legacy entry automatically when both exist. It is right for the users affected today, whose 1.16.1 era window is at most a few days old, but it is a permanent rule that ages badly: recents persist for a long time, so it would eventually strand people who moved to the new host months ago.
Caveats
- Reopens the window, as the migration did.
- An untitled multi-root workspace cannot be reopened losslessly, so it needs the same refusal path the removed code had.
Follow-up to #1092. Do this once that PR lands in v1.16.2.
Background
v1.16.1 gave each editor its own SSH host prefix, so Cursor workspaces moved from
coder-vscode.tocoder-cursor.. That prefix is part of the remote authority, and editors keyworkspaceStorageoff a hash of the folder URI, so the move gave every existing workspace a new identity and its per-workspace state, including Cursor's agent chats, was left behind under the old one.#1092 stops the renaming: legacy authorities stay supported, and opening a workspace reuses the host it was last opened on. Anyone who already moved recovers by reopening the workspace from File > Open Recent and picking the pre-1.16.1 entry.
Proposal
Make that recovery self-serve with a palette command, Coder: Reopen on Previous Host. It does deliberately, once, what the removed
migrateLegacyAuthoritydid automatically, with the prefix swap inverted: take this window's folder or saved workspace URI, swapcoder-<editor>.back tocoder-vscode., and reopen it withvscode.openFolder.retargetRemoteAuthority:toLegacyAuthority(authority).currentauthority in an editor whose id is notvscode, so it never appears in VS Code proper, where both prefixes are the same string.Once the user runs it, the legacy entry becomes the most recent, so the Coder panel keeps taking them there afterwards. Their choice sticks without a permanent rule that favours the older identity, which is why #1092 keeps recency as the tiebreak when a folder has entries on both hosts.
Not doing
Preferring the legacy entry automatically when both exist. It is right for the users affected today, whose 1.16.1 era window is at most a few days old, but it is a permanent rule that ages badly: recents persist for a long time, so it would eventually strand people who moved to the new host months ago.
Caveats