Repository navigation
bug: CLI database commands conflict with a running LadybugDB gateway #1683
Description
Bug description
With the CGC Gateway running against the embedded LadybugDB backend, direct CLI commands that open the same database fail because the gateway already owns Ladybug's exclusive read-write database lock.
This makes cgc update incompatible with a persistent local gateway even though update is documented as a normal, hook-friendly refresh command. The same conflict affects other direct CLI commands such as cgc list and cgc stats.
Ladybug's lock is expected safety behavior. The integration problem is that the CLI opens a second database object instead of delegating to the gateway that already owns the database, and the resulting error suggests cgc doctor rather than identifying the active gateway.
Steps to reproduce
-
Configure CGC to use an on-disk LadybugDB database.
-
Start the gateway:
cgc api start --host 127.0.0.1 --port 8765
-
In another terminal, run:
cgc update /absolute/path/to/an/indexed/repository
Actual behavior
Updating repository index...
Resolving context...
Initializing services and database connection...
Database Connection Error: IO exception: Could not set lock on file :
~/.codegraphcontext/global/db/ladybugdb
(Error: Resource temporarily unavailable)
Please ensure your database is configured correctly or run 'cgc doctor'.
The gateway remains healthy and can access the database through MCP/HTTP because it owns the existing Ladybug Database object.
Expected behavior
Preferably, database-backed CLI operations should detect and delegate to the active local gateway so all operations share its Ladybug database object.
If transparent delegation is intentionally out of scope, the CLI should at least detect this lock conflict and return an actionable error explaining that another CGC process owns the embedded database, rather than suggesting database misconfiguration or cgc doctor.
The Git hook workflow also needs a compatible path: cgc update --quiet cannot refresh a LadybugDB index while a persistent gateway owns the database.
Root cause in current source
src/codegraphcontext/cli/main.py:update()callsupdate_helper().src/codegraphcontext/cli/cli_helpers.py:update_helper()aliasesreindex_helper().reindex_helper()calls_initialize_services(), which creates and opens a new database manager/driver.- Ladybug permits one read-write
Databaseobject per on-disk database. The gateway already owns it.
Ladybug documents this restriction and recommends routing concurrent clients through one API-server-owned database object:
https://docs.ladybugdb.com/concurrency/
Environment
- CodeGraphContext:
0.6.8 - Ladybug:
0.19.1 - macOS:
26.4 - Backend: on-disk
ladybugdb - Gateway command:
cgc api start --host 127.0.0.1 --port 8765
Scope notes
This is not a stale lock: lsof identifies the live gateway process as the lock owner, and gateway MCP requests continue to succeed. Stopping the gateway releases the lock and allows the CLI command to open the database.
Activity
github-actions commentedon Aug 31, 2026
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
donovan-yohan commentedon Aug 31, 2026
Opened #1684 with the small, diagnostic-only fix: lock conflicts now explain that another CGC process owns the embedded database and direct users to the Gateway MCP/HTTP interface or stopping the owner. Automatic CLI-to-Gateway delegation remains out of scope for this PR.
Shashankss1205 commentedon Sep 2, 2026
Status: the guidance half landed in #1684 — the CLI now explains the lock conflict truthfully instead of pointing at
cgc doctor. Keeping this open for the deeper ask (CLI→Gateway delegation), which needs a Gateway discovery mechanism first.docs: add TROUBLESHOOTING.md — real reported issues mapped to fixes (#…
Shashankss1205 commentedon Sep 24, 2026
Status update — half of this shipped, half is still open, and I want to be explicit about which is which so the issue doesn't look more resolved than it is.
Shipped: the actionable error
cli_helpers.pynow detects the lock signature and says what's actually wrong instead of blaming your configuration:That replaces the misleading
run 'cgc doctor'suggestion you quoted, which sent you looking for a misconfiguration that didn't exist. Your report is what made that fix specific rather than generic — thank you for including the exact string and thelsofconfirmation that it was a live owner rather than a stale lock. That ruled out an entire wrong diagnosis before anyone started.Still open: transparent delegation
The real fix — CLI commands detecting a running gateway and routing through it rather than opening a second
Databaseobject — is not done. Keeping this issue open for it, since the error message makes the failure legible but doesn't make the workflow work.Your
cgc update --quietgit-hook case is the one that motivates it most, and it's the one the error message helps least: a hook can't usefully be told to go stop the gateway.Design notes for whoever takes it
Recording these so the next person doesn't re-derive them:
cgc api startis the obvious route. Probing a hardcoded port is not, since--host/--portare user-supplied.cgc listandcgc statsare reads and map cleanly onto the gateway's existing HTTP surface.cgc updateis a write that drives the whole indexing pipeline, and there may be no gateway endpoint that expresses it today. It's fine for the first PR to delegate reads only and keep the clear error for writes — that's a real improvement and a much smaller review.SIGKILLleaves the file behind; the CLI must verify the process is alive and answering before trusting it, or this fix introduces a new failure mode worse than the one it removes.Good, precise report — the root-cause trace through
update()→update_helper()→reindex_helper()→_initialize_services()meant no one had to find that path themselves.Shashankss1205 commentedon Oct 15, 2026
Maintenance review — 15 October 2026
Keep this open for gateway-aware CLI routing or an explicit single-owner database policy. Native availability fixes and better lock diagnostics do not make two processes safe writers to one embedded database.