Version 3.5.38 Stranded Itself in a Staging Directory

We pin Cursor to the taskbar and reboot, and it’s gone. It isn’t minimized or hiding behind another window. The pin is still there, but clicking it does nothing, and after the next restart even the pin is missing.

For a while we filed this under “Windows being Windows.” Taskbar pins do break sometimes, the shell rebuilds its icon cache at the worst moments, and re-pinning takes five seconds, so we kept re-pinning and moving on. That was the wrong call. The pin was a symptom of a dead shortcut, and the dead shortcut was a symptom of a self-updater that couldn’t finish its job.

Here is what was going on, and why “a pinned app disappears after reboot” is almost never the OS.

We looked at the install location before the taskbar

A pinned item is a .lnk shortcut pointing at a target exe. If the launch does nothing, the target is the suspect, so the taskbar is the last place worth looking. Instead of re-pinning again, we went and found where Cursor thought it lived.

It was installed to a custom path on a second drive, <drive>:\Programs\cursor\. We keep big apps off C: on purpose. The registry said the app lived there, the Start Menu shortcut pointed there, the taskbar pin pointed there. And <drive>:\Programs\cursor\Cursor.exe did not exist.

That is the whole “it vanished” story in one line. The top-level Cursor.exe the shortcut targets is gone, so the shortcut is dead, and clicking does nothing. The pin disappearing across reboots fits Windows pruning pinned shortcuts whose target no longer resolves. We confirmed the dead target on disk. The pin-pruning step is the consistent explanation for the rest, and we did not instrument it. Either way, Windows wasn’t being flaky. It was reacting to a shortcut that pointed at nothing.

Where the binary actually went

The app was not deleted. It had moved down a level.

The entire working application, Cursor.exe plus all its DLLs, was sitting one folder down in <drive>:\Programs\cursor\_\. The Cursor.exe in there alone was about 211 MB. That _ folder is an update-staging directory. Cursor’s self-updater downloads the new version into _, then on the next restart it swaps the staged copy up into the main folder, replacing the old top-level exe.

On our machine the swap never completed. The new files landed in _ and stayed there. The top-level Cursor.exe was never replaced, so the launch path went empty while a perfectly good, fully-updated copy of the app sat orphaned one directory deeper. The updater had downloaded an upgrade and stranded it.

So the chain is:

1. Auto-updater downloads the new version into the _ staging folder.
2. On restart it tries to swap _ up into the main folder.
3. The in-place swap fails and the files stay stranded in _.
4. The top-level Cursor.exe is never replaced, so the target path is now empty.
5. The taskbar pin and Start Menu shortcut point at a binary that no longer exists.
6. Windows prunes the dead pinned shortcut on the next reboot.

Every “it disappeared again” was one more update cycle re-stranding the binary.

Why the swap kept failing

We can describe the staged-but-not-swapped state because we went and looked at it. Why the swap aborted we are less sure about, so treat what follows as informed guessing.

The pattern fits a self-updater that can’t complete an atomic move into its install directory. The likely contributors here are a custom install path the updater doesn’t expect and a slower second drive. A per-user updater doing a download-then-swap is fragile by nature, and running it outside the default install location, on a drive that isn’t the fast one, is the kind of environment where the swap step loses a race or hits a lock and leaves the staged copy parked. The default C: install is the path the updater is actually tested against. The further you get from it, the more of these you collect.

What we are sure of: the binary was complete and current in _, and the top-level exe the shortcut needed was missing. That explains every symptom without blaming Windows for any of it.

The fix

We uninstalled the broken copy cleanly, both the folder and the registry entries, so nothing kept pointing at a half-updated tree. Then we did a fresh install onto a faster drive. The user-setup installer accepts a /DIR= flag, so you can still steer where it lands.

Your settings and extensions survive a reinstall. Cursor keeps those in %APPDATA%\Cursor and in .cursor\, both untouched by removing and reinstalling the application, so this is a safe move. You’re replacing the program, not your config.

One caveat, marked as a guess because we haven’t proven it across multiple update cycles: a custom path might still hit the same in-place-swap quirk down the line. The only location we’d call guaranteed immune is the default C: install, because that’s the one the updater is built and tested for. We moved to a faster drive because we wanted our big apps off C:, accepting that we may have to watch for this again. If you want it to never recur, install to the default location and let the updater do the thing it knows how to do.

What we could not verify

We confirmed the new install by running the version check, which reported 3.6.31 (up from the 3.5.38 that had been stranding itself). What we could not do was pop the GUI window from the shell we were working in. The process opens and exits without drawing anything when launched non-interactively, so there was no window to screenshot.

That leaves two steps manual and unverified: actually opening the window, and re-pinning it to the taskbar. We only watched the binary check pass. We did not watch the pin survive a reboot. “Reinstalled and the version check passes” is true. “The pin will stick now” is the claim we want to confirm after the next restart before calling this done.

What to check first

If a pinned app keeps disappearing, look at its install directory. If the top-level exe is missing and an orphan staging folder (here named _) holds the real binary and DLLs, you’ve found it. Installing to the default location is the safest way to keep it from recurring.

dxdev LESSON - paste into your AI coding agent
LESSON: Dead-target shortcut, not OS flakiness: check the install directory before blaming Windows
SOURCE: dxdev.com/blog/pinned-app-vanishes-after-reboot-self-updater-staging-folder
WHAT HAPPENED: A taskbar-pinned app stopped launching and the pin itself disappeared after every reboot. We initially blamed Windows flakiness and just kept re-pinning. Investigating the install path instead showed the top-level exe the shortcut pointed at no longer existed, while a complete, newer copy of the app sat one folder down in an update-staging directory. The self-updater had downloaded the new version into staging but never completed the swap into the main install folder, leaving the shortcut's target permanently empty. A custom install path on a secondary, slower drive is the likely (not confirmed) contributor to the swap failing.
THE RULE: When a pinned launcher or shortcut silently stops working, check whether its target file still exists on disk before blaming the OS; a self-updater's incomplete download-then-swap can leave the target empty while a working copy sits staged nearby.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any self-updater/installer flow that downloads a new version into a staging subfolder and swaps it into the main install directory on next launch, without verifying the swap completed or logging when it didn't.
  2. Any app with an auto-updater that supports installing to a custom or non-default path (secondary drive, non-C: location) without documenting or testing the updater against that path.
  3. Any troubleshooting runbook or habit that re-creates a UI artifact (re-pinning a shortcut, re-launching, restarting a service) repeatedly without first checking whether the underlying target path still resolves.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.