Repository navigation
codegraph index tells you to run codegraph daemon stop, which the CLI rejects #2770
Description
When codegraph index can't stop the project's daemon, it says:
✗ Failed to index: Could not verify that the active CodeGraph daemon has stopped. Run `codegraph daemon stop` to stop it, then retry `codegraph index`.
That command doesn't exist. codegraph daemon takes no arguments, so following the advice fails:
$ codegraph daemon stop
error: too many arguments for 'daemon'. Expected 0 arguments but got 1.
codegraph daemon is an arrow-key picker (codegraph.ts#L1960-L1969). Without a TTY it only lists the daemons. The message is at codegraph.ts#L909, and the writer-lock message gives the same advice (writer-lock.ts#L241: "codegraph daemon stop if a shared daemon").
Seen on a 1.6.2 build of main at efff745 plus a few fixes that don't touch the daemon command or these messages (both are unchanged at 0abae11), Linux / WSL2, Node 22.23.2.
How I hit it. The daemon holding the index was an older build's, left running after the session that started it had ended (its parent was init). index reported unverified/still-running from stopDaemonAt, and the only way out was finding the pid with ps and sending SIGTERM. I didn't check whether the picker would have listed that daemon. Related: #2335 (a daemon outliving an upgrade) and #2311 (stopDaemonAt outcomes).
Possible fixes:
- Make the messages say
codegraph daemon, and mention that it's interactive. - Or add a non-interactive
codegraph daemon stop [path](default: the current project), which both messages could point to and scripts could call.
Activity
danusha2345 commentedon Oct 22, 2026
#2373 (open since 2026-10-06) is the first of your two options: both messages —
index's "Could not verify that the active CodeGraph daemon has stopped" and the writer-lock's — namecodegraph daemonand say to pick the daemon there instead of thedaemon stopthat the CLI rejects. It changes the two strings and nothing else, so it is independent of a non-interactivecodegraph daemon stop [path], which would be a sensible follow-up for scripts (and for the case you hit, a daemon whose session is gone). The PR is rebased on currentmainand mergeable.inth3shadows commentedon Oct 22, 2026
Thanks, @danusha2345. I missed #2373 when filing. I checked its diff at 6a4e200: both messages now say
codegraph daemonand no longer saydaemon stop, and the tests assert that. That covers the first option.I'll leave this issue open for the second option, a non-interactive
codegraph daemon stop [path], for scripts and hooks that can't drive a picker. I still haven't checked whether the picker lists a daemon whose session has ended, which is the case I hit.fix(cli): index no longer blocks on a daemon lock naming a process th…
fix(cli): index no longer blocks on a daemon lock naming a process th…
colbymchenry commentedon Oct 22, 2026
Thanks for the report, @inth3shadows.
#2819 is merged to
main. When the project's daemon lock names a process that isn't CodeGraph, such as a reused pid or a leftover lock,codegraph indexnow clears the stale lock and rebuilds, andcodegraph unlockclears it too. When the lock is held by a CodeGraph process that doesn't answer, like the older daemon you hit, the message now names its pid and the command that stops it, instead ofcodegraph daemon stop.A non-interactive
codegraph daemon stop [path]is left for a separate change, and @danusha2345's #2373 guided the wording. It ships in the next release.