install/update not compatible with non-standard installations

[SC-CTS]

Version

codebase-memory-mcp 0.10.2

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

I'm using mise to install cbm (but I would assume the Homebrew path has the same issue) and the install/update commands will try to re-install the binary to a new place and modify path:

Would install binary -> /Users/user/.local/bin/codebase-memory-mcp
Added /Users/user/.local/bin to PATH in /Users/user/.zshrc

I don't want that to happen, I just want cbm to update the agent installations.

Reproduction

1. Install cbm through mise "github:DeusData/codebase-memory-mcp" = { version = "latest", matching = "codebase-memory-mcp-ui" }
2. Run codebase-memory-mcp install --dry-run

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]

Thank you @SC-CTS — this is a legitimate gap and you've described it precisely.

You're right that the Homebrew path has the same problem: when the binary is managed by mise, Homebrew, nix or anything similar, install/update should have no business relocating it into ~/.local/bin or editing your .zshrc. Those steps exist for the curl-installer case, where nobody else owns the binary — but cbm currently applies them unconditionally, and touching a shell rc file that a package manager did not ask for is the part that deserves the strongest objection.

What you want — refresh the agent configurations, leave the binary and PATH alone — is a mode we do not have and should. Queued for the next batch (v0.10.4), alongside #1558 which asks for related control over installer scope.

Two things that would help shape it, if you have a moment:

1. Would a flag on the existing command be enough (install --configure-only / update --configure-only), or do you want it inferred automatically when the running binary lives outside the managed install directory? Inference is friendlier but guesses; a flag is explicit but has to be discovered.
2. When cbm is managed by mise, should update refuse outright with a pointer to mise upgrade, or stay silent about the binary and just reconcile configs?

Marked for the next batch either way — a workaround in the meantime is to run the agent-configuration commands directly rather than the full installer, though I'd rather you not have to.

[SC-CTS]

I think install should probably go away as a command as "installing" cbm has already happened at that point through whatever means the user decided. It should be replaced with a setup or similar command that would only setup the agent configurations (including the mentioned scope change flag from #1558 ) with the current cbm installation path without putting the binary in another place or updating other shell settings.

update should refuse in every case except if it detects it was installed through the curl path.

[DeusData]

@SC-CTS — the behaviour you reported is fixed on the way to the next release (PR #1585), and your follow-up raises a design question I want to answer honestly rather than quietly decide.

What ships: the installer now detects a binary owned by mise/Homebrew/nix/asdf/cargo and leaves it — and your PATH — alone, configuring the agents only. --skip-binary forces that, --force-binary overrides it, and update refuses on a foreign binary naming the command that will actually work (mise upgrade, brew upgrade) instead of reporting success while changing nothing. PATH is now only touched when we placed the binary, which was wrong regardless of the rest.

One implementation note, because it shaped the result: my first cut inferred "externally managed" as anything outside our install dir. The test suite killed it immediately — a plain install --dir=/opt/cbm also lives outside the default, so update would have refused to update installations we own. Detection now requires positive evidence: we must be able to name the manager. That means an unrecognised manager still gets today's behaviour, which --skip-binary covers explicitly. If you know of managers worth adding to that list, say so and they go in.

On your larger proposal — retiring install in favour of a setup that only configures agents, and having update refuse unless it detects a curl-path install: I think you are pointing at something real. The command bundles two jobs, and for most users today only one of them is wanted. But renaming a documented command is a one-way door for every script and doc that references it, so that is the maintainer's call rather than mine to make in a bug fix. I have put it in front of him with your reasoning attached.

What I would note in favour of it: the flag-based fix I just shipped still leaves the default doing the surprising thing for anyone whose manager we do not recognise. Your version removes the ambiguity entirely instead of narrowing it.

Thank you for pushing past the initial report — the follow-up is what turned this from a flag into a design discussion.

[DeusData]

Merged to main — commit bd11088f (PR #1585), shipping in the next release.

With a mise/Homebrew/nix-managed binary, install now leaves the binary and your PATH alone and configures the agents only; update refuses and names the command that actually works. --skip-binary forces that behaviour, --force-binary overrides it.

Your larger proposal got a decision: the maintainer chose to keep install and add a --clients=claude,codex selector rather than split it into a setup command — additive, no breakage for scripts and docs, and it does not foreclose the rename later. Your argument that "installing has already happened" is recorded as a deliberate future decision rather than dismissed.

The selector will also be self-documenting: --clients will list every supported client with the exact token to type, since there are ~15 of them and nobody should have to guess whether it is claude, claude-code or Claude Code.

Thank you for pressing past the first report — the follow-up is what turned a flag into a considered decision.