codegraph - Moses Yebei

Abstract

Pre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, CoPilot, and Hermes Agent — fewer tokens, fewer tool calls, 100% local

The Problem

Coding agents waste context window and tool calls re-reading files they have already seen. Every file open, grep, and directory listing costs tokens, and agents often re-explore the same code paths multiple times in one session. A pre-indexed code graph that updates on file changes gives agents surgical access to code structure without re-scanning the tree.

What This Does

CodeGraph builds a semantic code graph from a repository and exposes it to agent tools through an MCP server. The codegraph-kernel/ directory contains the Rust-powered indexing engine, while src/ holds the TypeScript orchestration layer. The __tests__/ tree (399 files) covers language resolution, graph querying, and daemon behavior, with fixtures for TypeScript, Go, and a kernel-parity/ set spanning C, C++, Rust, Swift, Scala, Dart, PHP, Lua, and more.

The tool indexes symbols, call edges, and framework-aware routes, then serves them locally to multiple agents: Claude Code, Cursor, Codex, OpenCode, Hermes, Gemini, Antigravity, Kiro, and GitHub Copilot. A ui/ directory (97 files, Svelte-based) provides a browser view of the graph, and scripts/ (72 files) handles install, upgrade, and daemon lifecycle.

How It Is Wired

The traced entry points are all test fixtures — __tests__/fixtures/*/src/index.ts and payroll-go/cmd/payrolld/main.go — meaning the internal call graph has not been mapped for the production code paths in this repository yet. The README documents a CLI (codegraph upgrade, codegraph commands) and an MCP tool surface, but the specific function-level flow from CLI invocation through indexing to agent tool responses is not present in the analysis blocks.

What the structure does make clear: the daemon is central. Test names like daemon-manager.test.ts, daemon-registry.test.ts, daemon-socket-fallback.test.ts, and daemon-client-liveness.test.ts indicate a long-running process that agents connect to over a socket, with fallback behavior and liveness checks. The kernel in codegraph-kernel/ is the indexing core, and explore-* tests (allocation, blast radius, ranking, dedup, path pinning) show that query responses are budgeted and ranked, not raw dumps.

How To Use It

The README states installation requires no Node.js — the runtime is bundled. The fork URL is:

git clone https://github.com/moses-y/codegraph

The README documents codegraph upgrade for existing installs and a CLI reference section. Since this is a fork of colbymchenry/codegraph, the upstream npm package (@colbymchenry/codegraph) is the likely distribution channel, but this fork's package name and publish state are not confirmed in the structure. No package.json exists at the repo root in the listing — only inside test fixtures — so the build command for the TypeScript layer cannot be verified from the structure alone.

Real-World Use

An agent working on a large TypeScript codebase starts a session. Instead of grepping for a function and reading three files to trace a call path, it asks CodeGraph for the callers and callees of the target symbol. The graph returns the relevant edges in a few hundred tokens. When the developer edits a file, the daemon re-indexes the change, so the next query reflects current code without a full rebuild.

Code Health & Issues

Deep static analysis has not run for this repository yet. The structure supports these observations:

Low — Root-level build configuration is absent from the listing; only fixture package.json files appear, so the production build path is unverified.
Low — 403 test files is a strong signal, but coverage is concentrated on language resolution and explore/ranking behavior; CLI and daemon integration paths have fewer visible tests.

The Bottom Line

CodeGraph targets a real problem: agent context efficiency through pre-indexed code graphs. The fork inherits a substantial upstream codebase with broad language support and a serious test suite. The main open question is fork maintenance — with 0 stars and no topics, this is an unproven distribution of someone else's work, so pin to the upstream release unless you need this specific fork's changes.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,089 files

TypeScript612
Markdown92
Svelte55
Shell37
Rust27
JSON26

ReactSvelteExpressSpringSpark

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["__tests__ 270 modules"] g1["src 240 modules"] g2["scripts 38 modules"] g3["ui 36 modules"] g4["telemetry-dashboard 9 modules"] g5["telemetry-worker 3 modules"] g6["site 3 modules"] g0 -->|579| g1 g0 -->|40| g3

Module dependencies

The 10 most depended-upon modules of 600, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_src_index["index"] n1_src_types["types"] n2_src_extraction_grammars["grammars"] n3_src_resolution_types["types"] n4_src_mcp_tools["tools"] n5_traction_tree_sitter_helpers["tree-sitter-helpers"] n6_src_extraction_index["index"] n7_extraction_tree_sitter_types["tree-sitter-types"] n8_rc_resolution_strip_comments["strip-comments"] n9_src_search_query_utils["query-utils"] n2_src_extraction_grammars --> n1_src_types n6_src_extraction_index --> n1_src_types n6_src_extraction_index --> n2_src_extraction_grammars n6_src_extraction_index --> n3_src_resolution_types n5_traction_tree_sitter_helpers --> n1_src_types n7_extraction_tree_sitter_types --> n1_src_types n0_src_index --> n1_src_types n0_src_index --> n6_src_extraction_index n0_src_index --> n9_src_search_query_utils n4_src_mcp_tools --> n0_src_index n4_src_mcp_tools --> n1_src_types n4_src_mcp_tools --> n9_src_search_query_utils n3_src_resolution_types --> n1_src_types n9_src_search_query_utils --> n1_src_types classDef cyc stroke:#ef4444,stroke-width:2px; class n0_src_index,n4_src_mcp_tools cyc;

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium4

low2

Pin third-party GitHub Actions to a commit SHAhigh

.github/workflows

withastro/action@v3

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Stop discarding the exit code of steps whose failure mattershigh

.github/workflows/release.yml

lines 230 discard failure

The job reports green while the artifact it was supposed to produce was never produced, so a crash becomes a successful run built on stale data.

Fix: Let the step fail, or test the specific expected condition instead of discarding all exit codes.

Enable Dependabot or Renovatemedium

6 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Move large binaries to Git LFS or out of the repositorymedium6 occurrences

codegraph-kernel/grammars/scala/parser.c

6 blobs over 5MB: parser.c 33.4MB, parser.c 22.6MB, tree-sitter-cobol.wasm 15.6MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Set persist-credentials: false on checkoutmedium

.github/workflows/release.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow2 occurrences

.github/workflows/deploy-site.yml

2 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.