update -y in a non-interactive terminal deletes all project indexes, then fails at variant selection — failed update leaves every index destroyed with no rollback

[im47cn-bot]

Environment

• macOS 15 (Darwin 25.6.0), arm64
• v0.9.0 → attempting v0.10.8
• Invoked from a non-TTY context (Claude Code Bash tool / CI-style shell)

Reproduction

$ codebase-memory-mcp --version
codebase-memory-mcp 0.9.0

$ codebase-memory-mcp update -y
error: variant selection requires a terminal. Use --standard or --ui flag.
codebase-memory-mcp update (current: 0.9.0)

Update available: 0.9.0 -> v0.10.8
Found 19 existing index(es) that must be rebuilt after update:
  /Users/dreambt/.cache/codebase-memory-mcp/<19 dbs>.db
  ...
Delete these indexes and continue with update? (y/n): y (auto)
Removed 19 index(es).

Exit status 1. Every project index is now gone; the new binary was never downloaded. A second run deleted the two indexes that the running MCP server had recreated, then failed the same way. update -y --standard eventually succeeded.

Two distinct problems

1. Destructive ordering. Indexes are deleted before the update pipeline reaches the step that can fail (variant selection / download / staging). Any failure after the prompt leaves the user with zero indexes and no rollback. Expected ordering: fully stage and verify the new binary first, then remove stale indexes (or keep them until first re-index replaces them, like the install staging transaction).
2. -y cannot bypass variant selection. In non-interactive contexts the update can never succeed without knowing about --standard/--ui. Since -y already accepts "delete all my indexes", it is odd that it stops at the comparatively safe variant question. Suggested: -y implies --standard (or reads an env var, e.g. CODEBASE_MEMORY_VARIANT=standard), and the variant choice happens before any destructive prompt.

Related: #607 documents the analogous dark pattern on the install path.

Workaround (for anyone hitting this)

codebase-memory-mcp update -y --standard — but it still deletes all indexes first, so back up ~/.cache/codebase-memory-mcp if re-indexing 20+ projects is expensive.

[AmirF194]

At current main (339b3f40, built on top of 9ecabe0a "refactor(cli): move self-update out of the product on every platform", 2026-07-29), update no longer runs any in-process download, extract, or index-deletion flow at all.

Verified by building the production target (make -f Makefile.cbm cbm, no test seams defined) and running update -y against a home directory holding three existing .db index files:

codebase-memory-mcp update (current: dev)
The update runs from install.sh, not from this process. Run
  bash "<dir>/install.sh"
...
exit=0

All three index files were still present afterward, untouched.

That also closes the second half of the report: the --ui/--standard variant chooser this transcript hit was removed entirely on 2026-08-11, so a current update never asks a variant question in the first place.

Both problems only exist in binaries built before 9ecabe0a. The v0.9.0 binary in the report predates it, and an old binary's own update still carries the old code regardless of what main does now. For anyone on such a binary today, the only way off it is getting a current release once via the README's install instructions, not via that binary's own update.

One thing I read but did not execute: cbm_install_prepare_existing_indexes (src/cli/cli.c) is supposed to preserve existing indexes by default on a fresh install.sh run since #607. Worth an independent check before pointing anyone at that as the safe path.