Where does the bug appear (feature/product)?
Somewhere else…
Describe the Bug
Desktop can’t mount Project agent store (“Couldn’t sync project content”): self-hosted worker CLI writes index schema 5
Severity: High for us. A Project’s Context panel is unusable in the desktop app, and the only workaround means running an older self-hosted worker build by hand.
Summary
The self-hosted agent worker CLI on macOS auto-updated to a newer build than the desktop app. It rewrote the local agent store sync index to schema version 5. Desktop 3.22.12 can only read up to schema 4, so every mount of the Project store fails. The Agents window then shows “Couldn’t sync project content” for the Project.
Restarting Cursor doesn’t help.
The updater offers nothing newer than 3.22.12.
The Early Access update channel can’t be selected in Settings.
We found no team-admin control for it.
Error
The desktop logs show this on every mount attempt after the update:
mount failed: Unsupported agent store index schema version: 5
The same error appears for the user store. The file involved is each store’s .sync/index.sqlite, which records schema_version = 5.
Evidence the worker and desktop disagree on the index format
Of about 130 local stores, those on schema 4 or older mount fine. Only the schema 5 stores fail.
The stores whose sync lock the worker holds are all on schema 5. The ones whose lock the desktop holds are all on schema 4.
Conclusion: worker CLI 2026.09.28-64d2043 writes index schema 5, and desktop 3.22.12 can’t read it.
Earlier related errors (before the schema failure)
On 2026-09-28, sync repeatedly failed to remove a remote pycache folder, with Directory is not empty. marker=agent_store_dir_not_empty. It happened 17 times and was marked non-retryable. A compiled .pyc file had been deleted locally, but the remote folder still held content the local machine couldn’t see.
What we tried (2026-09-29)
Restarted Cursor twice. It didn’t help.
Moved about 100 binary and data files out of the store to rule out size or file-type issues. There was no change.
Reset test: we reset both .sync indexes, the desktop rebuilt them at schema 4, and we kept the worker off. The Context panel worked again.
Re-enable test: we re-enabled the worker without writing anything to the store. Within about 6 minutes, both indexes were back on schema 5. The worker upgrades the index when it connects, not only when content changes.
Update, 2026-09-30
It kept recurring. We reset the indexes three times in total over about 21 hours. Each time the worker was re-enabled, both stores went back to schema 5 within minutes, and the Context panel broke again.
The extension overrides any pin. The built-in “Cursor Agent Worker” extension recreates the agent-cli/.local/bin/cursor-agent link to the newest build at every Cursor start and every 10 minutes, then launches the worker. The only way we found to stop it is making .local/bin read-only.
Workaround that holds: with .local/bin read-only, we start the previous build by hand from a terminal: versions/2026.09.26-dd393fe/cursor-agent worker start. After it ran, both stores stayed on schema 4, and the Context panel and the worker work together. So the schema 5 upgrade arrived with build 2026.09.28-64d2043.
A new worker ID on every restart. Each manual start registers under the machine’s current hostname. When the hostname changes, for example on a different network, it gets a new worker ID that needs re-approval. A Project’s existing agents stay bound to the old ID and can’t be resumed on the new one.
Worker drops: the worker went offline three times in 24 hours, from machine sleep, a closed terminal and a network change. Each time, in-flight agents failed with “Cursor lost connection to the worker during tool execution.”
The Project’s Context panel, with its notes and documents, is unusable in the desktop app.
Agents, chat, the mobile app and the cloud copy still work.
Keeping Context working means stopping the self-hosted worker, or running an older build by hand. Our self-hosted agents are the ones with access to internal systems, so that has real cost.
Steps to Reproduce
Run a self-hosted agent worker on macOS whose auto-updated CLI (2026.09.28-64d2043) is newer than the desktop app (3.22.12).
Let the worker mount and sync a Project store and the user store.
Open the Project in the desktop Agents window. The Context panel shows “Couldn’t sync project content”, and the logs show Unsupported agent store index schema version: 5.
Expected Behavior
The desktop and the worker agree on the index format. Either the worker doesn’t upgrade a shared store past what the installed desktop can read, or the desktop can read or migrate the newer schema. Failing that, it degrades gracefully by rebuilding its own index.
Operating System
MacOS
Version Information
OS: macOS, on the same machine that hosts our self-hosted worker.
Cursor desktop: 3.22.12, shown in About for both the IDE and the Agents window. It updated from 3.22.7 on a restart on 2026-09-29.
Self-hosted agent worker CLI:
Binary: ~/Library/Application Support/Cursor/User/globalStorage/anysphere.cursor-agent-worker/agent-cli/.local/bin/cursor-agent.
That’s a symlink to …/versions/2026.09.28-64d2043/cursor-agent.
The symlink was retargeted automatically on 2026-09-29, and nothing pins the version.
Affected stores: one Project store and the user store, under ~/Library/Application Support/Cursor/AgentStores/cursor_agent_stores/
Does this stop you from using Cursor
No - Cursor works, but with this issue