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

[spam0115]

Version

codebase-memory-mcp 0.8.1

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

after running codebase-memory-mcp upgrade, the upgrade goes through the motions and even downloads something. However, running "codebase-memory-mcp --version" afterwards shows that the version was stuck at 0.8.1.

Directory of C:\Users...\AppData\Local\Programs\codebase-memory-mcp

06/30/2026 20:16

.
07/16/2026 21:44 ..
06/12/2026 06:13 269,067,776 codebase-memory-mcp.exe
06/12/2026 06:13 269,067,776 codebase-memory-mcp.exe.old

I had to delete the executable manually and then run "Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1" to finally upgrade it.

Reproduction

1. run "codebase-memory-mcp upgrade" on a windows machine.

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

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.

[DeusData]

@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.

[DeusData]

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.