Our company uses a monorepo accessed from multiple machines via SSH remote connections. Each SSH connection string (e.g. hostname vs FQDN, or different jump hosts) creates a separate Cursor workspace, and chat history is siloed per-workspace in workspaceStorage//state.vscdb.
This means:
Developers lose access to prior conversations when connecting from a different machine or via a different SSH config entry
The same repo gets 3-4 separate chat histories that can’t see each other
There’s no way to search or reference a past conversation that happened in a different workspace session
Enterprise teams can’t build institutional knowledge from past AI interactions
Current workaround:
We reverse-engineered the storage format and wrote a script to merge composer.composerData across workspace databases plus symlink agent-transcripts on the remote host. This is fragile and breaks on Cursor updates.
Proposed solution:
Sync chat history by repo identity (e.g. git remote URL), not by workspace connection string
Allow enterprise accounts to opt into shared/synced chat history across machines and workspaces
At minimum, expose a setting to link workspaces that point to the same repo so they share a single chat history
Who this helps:
Any team using Cursor over SSH remote, multi-machine setups, or enterprise accounts where developers access the same codebase from different environments.
This was written by cursor, really we just want a better way to sync chats/move them around. We’re developers, we want control. Chats shouldn’t live on my windows machine while transcripts live on my Linux server IMO. otherwise I love cursor, keep up the good work
This can be very helpful! My scenario involves machine learning workflows that use SLURM to manage the cluster, and despite the codebase being stored on the NFS that gets mounted across different nodes inside the cluster, the chat history is out of sync…
I used Cursor to explain this issue ; here is what it said.
You’re right, and now I can explain exactly why. There are two separate storage systems at play:
1. Agent transcripts (~/.cursor/projects/) — shared across nodes
The directory ~/.cursor/projects/home-haok-source-DualPipe/agent-transcripts/ is keyed purely by filesystem path (slashes replaced with dashes). Since /home is NFS-mounted, these .jsonl files are physically accessible from any node. This is the server-side log that the agent uses for citation purposes — but it is not what drives the chat history UI.
2. Cursor client state — NOT shared, and hostname-dependent
The actual chat history you see in the Cursor sidebar is stored on the client side (your local machine running the Cursor desktop app). The Cursor client identifies each remote workspace by its full URI, which includes the hostname:
The Cursor client treats these as two entirely different workspaces. Each gets its own conversation list in the sidebar.
Additionally, on the server side, ~/.cursor-server/data/User/workspaceStorage/ also uses hash-based folder names (you currently have 10 of them) that are derived from the workspace URI. Each node connection generates a new hash, a new workspace storage folder, and a new set of associations.
The bottom line
The chat history is lost on node switch because the hostname is baked into the workspace identity at both the client and server levels. The agent transcripts on NFS survive, but the Cursor UI doesn’t surface them for a “different” workspace. There’s no built-in way to merge or alias workspaces across hostnames — this is a VS Code architectural inheritance that Cursor hasn’t changed.
If you regularly switch nodes, the practical workaround would be to always SSH to the same hostname (e.g., via a stable alias or jump host that always routes to the same logical name), so the workspace URI stays consistent.
It’s trying to come up with a mechanism to do the migration between nodes when the chat history is stored in a NFS-mounted device… It can even decode the vscode-remote encoding mechanism. Let’s see what happens next.
