`update` deletes every index and then performs no update (it prints 'run install.sh yourself'); with -y this is unattended data loss

[Nicolas0315]

Version

0.9.0 (the deleting side) → 0.10.8 (the message quoted below)

Platform

macOS (arm64)

Summary

codebase-memory-mcp update deletes every index in the cache and then performs no update — it prints instructions telling you to run install.sh yourself. With -y this is unattended, guaranteed data loss with zero upgrade delivered.

What I ran

$ ~/.local/share/mcp-runners/codebase-memory-mcp/0.9.0/payload/codebase-memory-mcp update -y

What happened

It enumerated the 11 project databases in ~/.cache/codebase-memory-mcp/, then:

Delete these indexes and continue with update? (y/n): y (auto)
Removed 11 index(es).

After that:

• the invoked binary was still 0.9.0, with its original mtime — byte-identical, not replaced
• no new binary appeared anywhere under ~/.local/share or ~/.cache (find -newermt '-10 minutes' → empty)
• ~/.cache/codebase-memory-mcp/ was left holding orphaned .db-shm / .db-wal files for all 11 deleted databases, with no .db beside them
• the install directory was writable (touch in payload/ succeeds), so this was not a permissions failure

Net effect: 11 indexes destroyed, nothing upgraded.

Why: update is not an updater

Running the same subcommand on the current version makes the design explicit:

$ codebase-memory-mcp update -n
codebase-memory-mcp update (current: 0.10.8)

The update runs from install.sh, not from this process. Run

  bash ".../0.10.8/payload/install.sh"

It downloads the latest release, verifies its checksum, and replaces
this binary in place. ...

So the command's entire function is to print that message. The index-deletion prompt fires before it, on the outdated path only — the destructive step runs first and the non-destructive step is a printf.

Expected

Either of:

1. update actually performs the install (download → verify checksum → replace → then migrate/drop indexes), or
2. update deletes nothing. If the schema is incompatible, drop the indexes when the new binary first runs, or make the prompt say plainly that no upgrade will be performed and the indexes are being deleted anyway.

At minimum, -y should not be able to consent to a destructive step on behalf of an upgrade that the command never attempts. Cleaning up the orphaned -shm/-wal files alongside the .db would also help.

Aggravating factor on 0.9.0

0.9.0's indexing worker crashes on every repository on this machine, including a 25-line single-file Rust crate:

{"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file. ..."}

(consistent with #1267 / #333 / #391). So after update -y removed the indexes, 0.9.0 could not rebuild a single one — the pre-existing databases were the only working artifacts, and the command destroyed them. Recovery required manually downloading 0.10.8 and re-pointing the MCP config at it. 0.10.8 re-indexed all 9 projects without incident.