Repository navigation
The update runs from install.sh, not from this process running update #1544
Description
Version
codebase-memory-mcp 0.10.1
Platform
macOS (Apple Silicon)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
ui
What happened, and what did you expect?
Running update fails:
codebase-memory-mcp update --ui
codebase-memory-mcp update (current: 0.10.1)
The update runs from install.sh, not from this process. Run
bash "/Users/ehendrix/.local/bin/install.sh"
It downloads the latest release, verifies its checksum, and replaces
this binary in place. install.sh is idempotent, so re-running it IS
the update; pass --ui for the UI build.
Note, I was on 0.10.0 before with same issue. Did not have it before so this was introduced with 0.10.0
Reproduction
Run update
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.
Activity
DeusData commentedon Aug 11, 2026
Thanks @ehendrix23 — and this caught something worse than what you reported.
The immediate regression: v0.10.2 (released a few hours ago) removed the obsolete
--ui/--standardflags along with the variant chooser they drove, so the command you ran now fails witherror: unknown update option: --uiinstead of printing the handoff. That's on us: a flag people have in scripts and muscle memory should be accepted and ignored with a deprecation notice, not turned into an error. Fixing that in the next patch release —update --uiwill work again (and quietly tell you the flag is meaningless now, since every build ships with the UI).On the handoff itself: that is deliberate, not a bug. A running executable cannot replace its own image on Windows, and rather than keep a second resident helper binary just for that — which reliably tripped antivirus heuristics — the update step moved into
install.sh/install.ps1, which run while cbm is not running. Re-running the installer is the update, and it is idempotent. Whether the message should be friendlier (orupdateshould offer to exec the script for you) is a fair design question and worth its own issue if you'd like to make the case.Marked priority/high and queued for the next batch.
fix(cli): stop breaking commands people already type (#1544, #1550)
fix(cli): stop breaking commands people already type (#1544, #1550)
DeusData commentedon Aug 12, 2026
@ehendrix23 — following up: the regression you hit is fixed and shipping in v0.10.3 (releasing now), commit
a154d18a.update --uiand--standardare accepted again. They do nothing — every build has included the graph UI since v0.10.0 — and they now say so once instead of failing. A genuinely unknown flag is still rejected, since the goal is compatibility, not silence.Your other point, that
updateshould update rather than hand off toinstall.sh, remains a fair design question and is untouched by this. If you would like to make the case for it, a separate issue is the right place and we will treat it as a direction question rather than a bug.ehendrix23 commentedon Aug 13, 2026
In the past I was able to just run
codebase-memory-mcp updateand it would do the update. Now it returns the prompt. I am fine in it then for example starting the install script or so but this is definitely a change in behavior for upgrade.Ability to use
codebase-memory-mcp updatein my opinion also ends up being more user-friendly and more similar like other tools etc..DeusData commentedon Aug 13, 2026
v0.10.3 is published — https://github.com/DeusData/codebase-memory-mcp/releases/tag/v0.10.3 (GitHub archives, npm, and PyPI are all serving it).
This fix is in it. Please give it a try when you get a chance: if it behaves in your setup, feel free to close this out, and if anything still looks off, say so and we'll pick it straight back up. Thank you again for the report.
DeusData commentedon Aug 13, 2026
Closing the v0.10.0 compatibility regression as fixed in v0.10.3:
update --uiandupdate --standardare accepted again as compatibility no-ops now that every build includes the graph UI.The broader proposal for
updateto replace the binary directly instead of handing off to the installer remains a separate direction question, as discussed above, and should be tracked separately if you want to pursue it. Thank you again @ehendrix23 for catching the behavior change.test(cli): pin that `update -y` never deletes project indexes (DeusDa…