Version: codedb 0.2.5824, macOS (Darwin 25.5.0)
Summary
When no cli-daemon is alive for the target project, codedb <root> <command> resolves the project snapshot from the current working directory and silently ignores the explicit <root> argument. The command then answers from whatever project CWD belongs to — with a normal-looking success output. The warm-daemon path honors <root> correctly, so the bug only bites on first-touch / after a daemon dies, which makes it intermittent and very hard to attribute.
Repro
Two indexed repos: ~/bench/flask (a pallets/flask clone) and ~/engram.
pkill -f 'bench/flask cli-daemon' # ensure no daemon for flask
cd ~/engram # CWD = a DIFFERENT indexed repo
codedb /Users/blackfloofie/bench/flask search url_for
Observed:
✓ loaded snapshot 226 files ⚡ 1.3ms <- engram's snapshot (flask is ~1.3k files)
✗ no results for "url_for" <- url_for obviously exists in flask
A search for a term that exists in BOTH repos makes it unambiguous — the hits come from the wrong repo:
codedb /Users/blackfloofie/bench/flask search session
✓ 2 results for "session"
README.md:84 engram remember "fix auth session timeout" src/auth.zig:Session ...
Same command with cd ~/bench/flask first: correct (47 results for url_for). Same command with a warm flask daemon: correct from any CWD.
Impact
Anything that shells out to codedb with an explicit root from a different working directory (agents, MCP-launched processes, benchmark harnesses) silently gets wrong-repo results on cold start. In engram's git-history benchmark this turned 20 comparable queries into 0 — with no error anywhere. We work around it by cd <root> inside the spawned shell.
Likely the same root-resolution lineage as the (closed, MCP-side) #346, but on the CLI cold path.
Related observation (cold snapshot scope)
Even with the cd workaround, a cold CLI answers from the saved snapshot, whose file scope can lag the warm daemon's live index (measured on flask: config/docs files missing cold — a retrieval benchmark scored 18 comparable queries cold vs 22 warm). If intended, a one-line "snapshot may be stale, daemon warming" notice on the cold path would make this debuggable.
🤖 Generated with Claude Code
Version: codedb 0.2.5824, macOS (Darwin 25.5.0)
Summary
When no cli-daemon is alive for the target project,
codedb <root> <command>resolves the project snapshot from the current working directory and silently ignores the explicit<root>argument. The command then answers from whatever project CWD belongs to — with a normal-looking success output. The warm-daemon path honors<root>correctly, so the bug only bites on first-touch / after a daemon dies, which makes it intermittent and very hard to attribute.Repro
Two indexed repos:
~/bench/flask(a pallets/flask clone) and~/engram.Observed:
A search for a term that exists in BOTH repos makes it unambiguous — the hits come from the wrong repo:
Same command with
cd ~/bench/flaskfirst: correct (47 results forurl_for). Same command with a warm flask daemon: correct from any CWD.Impact
Anything that shells out to codedb with an explicit root from a different working directory (agents, MCP-launched processes, benchmark harnesses) silently gets wrong-repo results on cold start. In engram's git-history benchmark this turned 20 comparable queries into 0 — with no error anywhere. We work around it by
cd <root>inside the spawned shell.Likely the same root-resolution lineage as the (closed, MCP-side) #346, but on the CLI cold path.
Related observation (cold snapshot scope)
Even with the cd workaround, a cold CLI answers from the saved snapshot, whose file scope can lag the warm daemon's live index (measured on flask: config/docs files missing cold — a retrieval benchmark scored 18 comparable queries cold vs 22 warm). If intended, a one-line "snapshot may be stale, daemon warming" notice on the cold path would make this debuggable.
🤖 Generated with Claude Code