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

For a while I 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 I kept re-pinning and moving on. That was the mistake. The pin wasn’t the bug. The pin was the symptom of a dead shortcut, and the dead shortcut was the symptom of a self-updater that couldn’t finish its job.

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

The first thing I looked at was the install location, not the taskbar

When a pinned shortcut stops working, the taskbar is the last place to look, not the first. A pinned item is a .lnk shortcut pointing at a target exe. If the launch does nothing, the target is the suspect. So instead of re-pinning again, I went and found where Cursor thought it lived.

It was installed to a custom path on my second drive, <drive>:\Programs\cursor\. I 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. I confirmed the dead target on disk; the pin-pruning step is the consistent explanation for the rest, not something I instrumented. Either way, Windows wasn’t being flaky. It was reacting to a shortcut that pointed at nothing.

Where the binary actually went

The app wasn’t 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 my 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

I can tell you what the staged-but-not-swapped state looks like because I went and looked at it. The exact mechanics of why the swap aborted I am less certain about, so I’ll label that as informed guessing rather than state it as fact.

The pattern fits a self-updater that can’t complete an atomic move into its install directory. The likely contributors here: 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 doing it outside the default install location, on a drive that isn’t the fast one, is exactly the kind of environment where the swap step quietly 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 I am sure of: the binary was complete and current in _, and the top-level exe the shortcut needed was missing. That is enough to explain every symptom without blaming Windows for any of it.

The fix

I uninstalled the broken copy cleanly, both the folder and the registry entries, so nothing kept pointing at a half-updated tree. Then I 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 itself, so this is not a destructive move. You’re replacing the program, not your config.

One honest caveat, and I’m marking it as a guess because I 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 I’d call guaranteed immune is the default C: install, because that’s the one the updater is built and tested for. I moved to a faster drive because I wanted my big apps off C:, accepting that I may have to watch for this again. If you just want it to never recur, install to the default location and let the updater do the thing it knows how to do.

The part I couldn’t verify, and said so

I 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 I could not do was pop the GUI window from the shell I was working in. The process opens and exits without drawing anything when launched non-interactively, so there was no window to screenshot.

That means two steps stayed manual and unverified: actually opening the window, and re-pinning it to the taskbar. I’m flagging that explicitly rather than calling the whole thing “fixed,” because I only watched the binary check pass, not the pin survive a reboot. “Reinstalled and the version check passes” is true. “The pin will stick now” is the thing I’d want to confirm after the next restart before I’d call it done.

The takeaway

“My pinned app disappears after reboot” is almost always a dead-target shortcut. Windows prunes pinned shortcuts whose target exe no longer exists, and it’s right to.

The usual culprit underneath is a per-user auto-updater that couldn’t complete an in-place swap, especially when the app is installed outside the default path or on a slower drive. Before you blame the OS, blame the OS last. Go look at the install directory. If the top-level exe is missing and there’s an orphan staging folder sitting next to it, usually named something forgettable like _, with the real binary and DLLs inside, you’ve found it. The app didn’t vanish. It got downloaded into the wrong level and never made it home.