Skip to content

Workspace state lost after v1.16.1 moved workspaces onto per-editor SSH hosts #1094

Description

@EhabY

Symptom

After upgrading to v1.16.1, Cursor users find their agent chats gone from workspaces they had been using. Window layout and other per-workspace extension state go with them. Reported by a customer.

Cause

#1061 gave each editor its own SSH host prefix, so Cursor's hosts changed from coder-vscode. to coder-cursor.. That host name is part of the remote authority, the authority is part of every folder URI, and editors key workspaceStorage off a hash of that URI. A changed prefix therefore reads as a workspace the editor has never seen, and Cursor's chats are workspace-scoped.

setup() reopened the window on the new authority automatically (remote.ts:165), so it happened silently to every workspace opened before the upgrade, and picking the old entry from File > Open Recent bounced straight back onto the new one.

Nothing is deleted. The state is still on disk under the old address.

Scope

Forks only: Cursor, Windsurf, VSCodium, and others. VS Code proper is unaffected, since its prefix is coder-vscode either way.

Fix

#1092, targeting v1.16.2:

  • Drops the automatic migration, so a coder-vscode authority stays supported and keeps the identity it already had.
  • Reuses the host a workspace was last opened on when opening from the Coder panel, so only workspaces with no history get this editor's prefix.
  • Serves the legacy prefix from a single generated SSH config file. Two files declaring the same host pattern left glob order deciding which editor's CLI and credentials a connection used, which is a live bug in v1.16.1.

Recovery

Once v1.16.2 ships, a workspace that already moved comes back by reopening it from File > Open Recent and picking the entry from before v1.16.1. No data needs restoring.

Known limitation

Two editors connecting to the same deployment over the legacy host share one generated file, last writer wins, and setup() runs on the onResolveRemoteAuthority activation event, so a reconnect does not rewrite it. This is the pre-1.16.1 behaviour and is tracked in #1092.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions