Skip to content

v0.170.1

Choose a tag to compare

@github-actions github-actions released this 16 Oct 16:14
· 84 commits to main since this release

Upgrading: nothing to do unless a project's .code-graph is a symlink, a
regular file or a FIFO
(INDEX_VERSION is unchanged). The commands that read
such a project now refuse it (exit 1; grep falls back to plain grep).
Through a symlink they used to answer from, and edit, the index in the
directory the link points at. To pin the binary back: npm i -g @sdsrs/code-graph@0.170.0 (or, from source, cargo install --locked --git https://github.com/sdsrss/code-graph-mcp --tag v0.170.0 --features embed-model; without the feature, search is FTS5-only), then delete
~/.cache/code-graph/bin/code-graph-mcp, the auto-update copy, which is used
ahead of an older binary, and set CODE_GRAPH_NO_AUTO_UPDATE=1 in the
environment Claude Code runs in, so the plugin does not fetch it again. That
pins the binary only: the plugin's statusline and doctor come with the plugin,
and keep refusing the link.

Every CLI command that reads .code-graph refuses a symlinked one

0.127.0 made a symlinked .code-graph an error (exit 1), but only the commands
that create or replace the index checked for one. With .code-graph -> ../outside holding an index, the query commands answered from that index, and
their freshness pass dropped from it the files this project does not have.
incremental-index re-indexed it as this project, and before reaching the
index it removed a stale indexing-status.json there. stats reported the
logs it found there.

The query commands, health-check, incremental-index and stats now exit 1
with refusing to use a symlinked <path> — remove it and re-run, and leave the
directory as they found it. A .code-graph that is a regular file or a FIFO
is refused the same way, with <path> exists and is not a directory; the
query commands and health-check used to say No index found for it, and
stats that it had no usage data. health-check --format json (and --json)
prints a report with "reason": "refused" and the message in issue, then
exits 1. grep still prints its plain-grep results, and says why they carry no
AST context.

The plugin follows suit. doctor shows the message on its Index line, says
what to remove, and exits 1 until .code-graph is fixed; it removes nothing,
since the link may be yours. 0.170.0's doctor reported a linked index as
healthy, with the counts of the index the link points at, and called the other
shapes not indexed yet. When the link points at an index, the statusline shows
code-graph: ✗ .code-graph refused (see health-check) instead of that index's
progress and counts. For the other shapes it stays empty, as for any project
with no index.

If you linked .code-graph elsewhere on purpose, move the directory back into
the project; the MCP server, rebuild-index and reindex have refused the link
since 0.127.0. In a linked worktree with no index of its own, the query
commands already read the main checkout's index without a link.

Not covered

A symlinked index.db inside a real .code-graph directory is still opened,
and written, through the link. The hooks still read source-roots.json,
recommendations.jsonl and indexing-status.json through a symlinked
.code-graph. In a linked worktree whose .code-graph is a dangling link or a
regular file, the query commands, health-check, doctor and the statusline
read the main checkout's index and report it as healthy, while stats,
incremental-index, reindex and rebuild-index refuse it.