`codegraph sync .` silently no-ops when worktree is ahead of index (0.9.4)

[mojo-repository]

Version: 0.9.4 (via npm — /usr/bin/codegraph)
Platform: Ubuntu 22.04 LTS, Node v20.x

Observed behavior

Running codegraph sync . returns Already up to date even when the git worktree has dozens or hundreds of new commits since the last codegraph index . run. The on-disk .codegraph/codegraph.db is not modified; MAX(indexed_at) from the files table stays frozen at the timestamp of the last index run.

This happens specifically in the CLI / cron use case: no MCP server running, no in-process file watcher — just codegraph sync . invoked from a script after git pull pulled new commits into the working tree.

Steps to reproduce

1. codegraph index . against a repo. Note the baseline:

   sqlite3 .codegraph/codegraph.db 'SELECT MAX(indexed_at) FROM files;'

2. From outside the index's awareness (e.g. git pull, or commits made while no codegraph serve --mcp was running), bring fresh commits into the worktree.
3. Run codegraph sync . — exits 0, prints Already up to date.
4. Re-check MAX(indexed_at) — unchanged. The new commits' files are not re-parsed; queries against them return stale results.
5. codegraph index . --force correctly re-examines everything and the index advances.

Expected behavior

codegraph sync . should either:

• detect the diff (via content-hash / (size, mtime) reconciliation, the same one the docs describe for "Connect-time catch-up" when an MCP server (re)attaches) and re-index changed files, or
• exit non-zero / emit a warning when it can't reconcile,

so cron-based pipelines that run sync on a schedule don't silently fall behind. Right now there is no signal at all — the exit code, stdout, and stderr all look like a successful sync.

Workaround

Schedule codegraph index . --quiet instead of codegraph sync . — index correctly picks up new commits.

Real-world impact

A production cron that ran codegraph sync . every 4h for ~26 days left two indexes 26 days stale despite journalctl showing the cron firing every cycle on schedule:

• LoadBalancer repo: 511 files, 69+ commits ahead at the time of detection
• AppServer repo: 4,005 files, 255+ commits ahead at the time of detection

No error signal anywhere — the cron logs, the codegraph stdout, and the exit code all looked healthy. The staleness was only noticed when downstream queries started returning symbols that had been renamed weeks earlier.

Related but not duplicate

• watcher treats zero-result sync as success and clears pending files #449 (closed) covers a related but distinct failure mode: the file-watcher path treating a zero-result sync as success when lock contention causes CodeGraph.sync() to return an all-zero result. The case here is the bare-CLI codegraph sync . path with no watcher, no lock contention, and a worktree that's simply ahead of the index from out-of-band commits.
• Will newly created files be missing from query results if sync is not manually run? #438 (closed) is a question about agent-created files and auto-sync, not about the CLI sync no-op.

Happy to provide more detail (db dump, exact commit ranges, full cron unit) if useful.