Repository navigation
pstack skills disappear in other repos/worktrees until reinstall (cache sha churn + per-window prune race) #789
Description
Symptom
pstack skills (/poteto-mode, /how, /bro, …) often don't show up in Cursor windows opened on other repos or git worktrees. Uninstalling and reinstalling pstack brings them back, until the next time. Other plugins from this monorepo (cursor-team-kit, gmail, google-calendar, google-drive, x) share the same cache key, so they are probably affected too. pstack is the one I notice because I use its slash commands all day.
Environment
- Cursor 3.27.12 (also seen on 3.26.x), macOS, Apple silicon, Glass layout
- pstack 0.15.30 from the
cursor-publicmarketplace - Usually 2 or 3 windows open at once, each on a different repo or worktree
What the logs and local state show
- The cache key changes almost daily. Plugins from this repo are cached at
~/.cursor/plugins/cache/cursor-public/<plugin>/<monorepo commit sha>/. Over the last 6 days my windows picked up six different shas (d457567,ddf824a,111cf6a,190d287,d1453c1,9b93e81), because any commit to the monorepo moves the pin, even one that only touches a third-party plugin. - Every window installs at the same moment. When a new sha arrives, each open window logs
loadFromMarketplaceSource: Plugin missing from cache, installing: pstackwithin the same second and clones into the same directory. On 2026-10-22 16:02:11 and 2026-10-23 18:42:08/12 this happened in 2 to 3 windows at once. - Each load deletes the other versions. In
cursor-agent-exec, after a plugin loads,pruneOldVersions({…, keepVersions:[e.version]})removes every other sha directory. A window that loaded the previous sha keeps paths into a directory another window just deleted. - A failed load leaves a plugin with no skills. On a load error,
loadFromMarketplaceSourcerecords the plugin withloadErrorandskills: []. It still counts as installed but shows no skills until the window reloads. I saw concurrent-install collisions on other marketplace plugins, logged asCursor plugin load error:gmail@4bf3e08…: EEXIST: file already exists, mkdir …/.cursor-plugin,gmail@4bf3e08…: ENOENT … open …/.cache-complete, andagentmail@aebd765…: ENOENT … unlink …/.mcp.jsonin two windows in the same millisecond. - The installed-plugin cache is stored per workspace.
globalStorage/state.vscdbhas onecursor.plugins.installedIds.<teamId>|<workspace uri>key per folder (54 for me), and every git worktree counts as a new workspace. The lists differ a lot: my main checkout has 17 plugin ids, while worktrees and repos I opened before installing have 4 to 8. The renderer hydrates this on window open (_hydrateInstalledPluginIdsFromStorage). - Backend misses.
marketplace listEnabledPlugins failed … treating source as unavailableappears 114 times in my logs over about 2 weeks. A window that opens during one loads no marketplace plugins at all until it reloads.
Likely cause
A per-window cache of a shared on-disk directory, a pin that moves daily, and prune-on-load, with no lock between windows. Whichever window installs or prunes first can leave the other windows with a deleted path or a half-written directory. Items 5 and 6 explain why it shows up in "some other repo" and not everywhere at once. I haven't caught the slash menu missing pstack in the same window as a logged error, so the exact trigger is inferred from logs and code, not observed.
Workaround
Developer: Reload Window (or a full quit) in the affected window usually brings the skills back without reinstalling.
Asks
- Pin the cache per plugin (version or tree hash of
pstack/) instead of the monorepo commit, so an unrelated commit doesn't force a reinstall. - Lock or atomically rename (
tmp dir→ final path) when installing into the cache, and don't prune a version another window still has loaded. - When a plugin load fails, retry or surface the error instead of silently keeping the plugin with
skills: [].
Related: #136 (install, enable and cache lifecycle docs), #527 (disable-model-invocation and the / palette), and the forum thread on skills not showing until restart or a new repo.
Activity
deanrie commentedon Oct 23, 2026
Hey @darkhan-nace, thorough write-up, thanks. I checked the first point against this repo's history: all six shas you list are merge commits on
main, and five of them (9b93e81#778,d1453c1#766,190d287#740,111cf6a#739,ddf824a#725) touch onlythird_party/<one plugin>/,.cursor-plugin/marketplace.jsonand the README.pstack/is byte-identical across them, so each of those reinstalls of pstack was triggered by a change to an unrelated connector. Onlyd457567(#724) actually changed pstack. My own cache shows the same layout, one<monorepo sha>directory per plugin, all on9b93e81after pruning.The install, prune and
installedIdslogic lives in the app, not in this repo, so the fix for points 2 to 6 is on the Cursor side rather than something a plugin author can patch here. Two things that would sharpen it for whoever picks it up: the exactcursor-agent-execlog lines around onepruneOldVersionscall (with the sha it kept and the shas it removed), and whether the window that lost its skills had logged aCursor plugin load errorfor pstack specifically, or only for the other plugins you saw collide. You mention you have not caught the two together yet; if it happens, that pair of timestamps is the missing link.