Can't upgrade codebase-memory-mcp on windows platform. Can't uninstall. #1168

Activity

1. spam0115

   added

   bugSomething isn't workingSomething isn't working

   on Jul 18, 2026
2. github-actions

   added

   windowsWindows-specific issuesWindows-specific issues

   on Jul 18, 2026
3. DeusData

   added

   ux/behaviorDisplay bugs, docs, adoption UXDisplay bugs, docs, adoption UX

   priority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.Needs near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.

   on Jul 19, 2026
4. DeusData

   added this to the 0.9.1-rc milestone on Jul 19, 2026
5. DeusData

   added a parent issue on Jul 19, 2026

   • task: Windows platform issues (8 bugs) #394
6. DeusData commented on Jul 19, 2026

   

   DeusData

   on Jul 19, 2026

   Last edited by DeusData

   Owner

   More actions

   Thanks for the precise upgrade reproduction. I have placed this in 0.9.1-rc at high priority. Review needs to cover Windows replacement of a running executable, the .exe.old fallback, and which binary PATH resolves after the upgrade reports success.
7. DeusData commented on Aug 14, 2026

   

   DeusData

   on Aug 14, 2026

   Owner

   More actions

   @spam0115 — the directory listing is what makes this unambiguous: codebase-memory-mcp.exe and .exe.old at identical sizes and timestamps after an upgrade that reported success. An upgrade that downloads, claims to have worked, and quietly leaves you on the old binary is worse than one that fails loudly.

   Having to delete the executable by hand and re-run install.ps1 is not something anyone should have to discover for themselves, and I am sorry that was the only way through.

   Still open and not fixed yet; the pieces to settle are replacing a running executable on Windows, the .exe.old fallback, and which copy PATH resolves afterwards (#1180 shows how easily two copies coexist). Tonight's v0.10.5 is being cut for the issues that make cbm impossible to operate, and "cannot upgrade, cannot uninstall" is exactly that. Thank you for the precise reproduction.
8. DeusData commented on Sep 20, 2026

   

   DeusData

   on Sep 20, 2026

   Owner

   More actions

   Closing this as fixed — with an apology that it sat open for two months after the fix shipped. That is a triage miss on our side, and it surfaced because a contributor's Windows troubleshooting page (#2262) listed this issue as still current.

   What was wrong. Up to v0.9.x, update on Windows tried to replace its own running executable in-process. Windows keeps a running image locked, so the download could succeed while the old binary stayed exactly where it was — which is what you saw: the upgrade "completes", and --version still reports the old version.

   What changed — a54ea95, shipped in v0.10.0. In-process self-replacement on Windows is gone. codebase-memory-mcp update now only prints the install.ps1 command to run and exits. install.ps1 does the replacement from outside the process: it stops the daemon, renames the locked executable out of the way (.retired-*), fails loudly if it cannot, installs the new binary and then verifies --version on the installed file. tests/windows/test_windows_update_handoff.py guards the contract on the Windows CI leg — the executable's bytes are unchanged by update, no sibling file appears, and the active MCP/daemon session is left alone.

   If you are still on v0.9.x or earlier: run the install.ps1 one-liner from the README once. That gets you onto a version where updating works as described above.

   One honest gap: the "can't uninstall" half of the title never got a reproduction in this thread, so I cannot claim it is covered by this fix. If uninstalling still fails for you on v0.11.0, please open a fresh issue with the exact command and its output — it will be looked at on its own rather than buried under this one.

   Thank you for the report, and for your patience.
9. DeusData

   closed this as completedon Sep 20, 2026
10. DeusData

    added a commit that references this issue on Oct 27, 2026

    docs(troubleshooting): refresh Windows entries for v0.12.x

    ...

    a36b2ee