AI / CodeGraph Interview questions

CodeGraph is an open-source tool that builds a pre-indexed, local knowledge graph of your codebase and hands it to AI coding agents through an MCP server. The graph stores symbols (functions, classes, methods) and the relationships between them: calls, imports, extends and implements.

Instead of letting an agent grep, glob and read files one by one, the agent asks CodeGraph a question and gets the relevant source and call paths back in a few calls. It targets agents such as Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity IDE and Kiro.

Everything runs on your machine. The index sits in a SQLite database, and no API keys or external services are needed.

Note: this pack covers the colbymchenry/codegraph project (npm package @colbymchenry/codegraph). Other unrelated projects share the CodeGraph name.

It removes the discovery tax. When an agent such as Claude Code explores a repository, it spawns Explore agents that scan with grep, glob and Read, and every one of those tool calls burns tokens before the agent even reaches the right code.

CodeGraph replaces that scan with graph queries over symbol relationships, call graphs and code structure that were indexed ahead of time. The agent can often answer "how does X work?" from the index with zero file reads.

In the project's own benchmark (v0.9.4, seven open-source repos), the average result was 35% cheaper, 57% fewer tokens, 46% faster and 71% fewer tool calls. Treat those as vendor-reported numbers: they depend on the repo and the question.

There are three routes, and all of them end in an interactive installer that configures your agents.

1. Shell installer (no Node.js needed, it bundles its own runtime): curl the install.sh script on macOS/Linux, or irm the install.ps1 script in PowerShell on Windows.
2. npx: npx @colbymchenry/codegraph downloads and runs the installer in one go.
3. npm global: npm i -g @colbymchenry/codegraph.

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh
# or
npx @colbymchenry/codegraph

After installing, restart your agent so it loads the MCP server, then run codegraph init -i inside each project you want indexed.

The installer auto-detects and configures eight agents: Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity IDE and Kiro. For each one it registers the MCP server and writes an instructions file that teaches the agent when to use CodeGraph.

You can pick agents explicitly with --target=cursor,claude instead of auto-detection. The supported list may grow, so check the README for your version.

Run codegraph init -i from the project root. It creates the local .codegraph/ directory and, because of -i (--index), builds the full graph in the same step.

cd your-project
codegraph init -i

It also wires up any project-local agent surfaces, such as Cursor's rules file, so one global codegraph install keeps working in every project you open.

Once .codegraph/ exists, agents use the CodeGraph tools automatically. Without it, the project simply isn't indexed.

If you aren't standing in the project root, codegraph init [path] accepts a path. To start over later, codegraph uninit removes the index and you can initialise again.

In a local SQLite database at .codegraph/codegraph.db inside each project. Symbols, edges and files live in tables, and FTS5 provides full-text search over names.

Current builds ship their own Node runtime and use Node's built-in node:sqlite in WAL mode, so concurrent readers don't block on a writer.

Removing the index is per project: codegraph uninit deletes it (use --force to skip the prompt). codegraph uninstall deliberately leaves .codegraph/ alone.

Because the index is a plain file inside the project, there's no server process to manage. If it ever drifts out of step, codegraph index --force rebuilds it. You'll usually want to keep .codegraph/ out of version control (that part is my suggestion, not a README rule).

It's the bridge between the index and your agent. Your agent launches codegraph serve --mcp over stdio, and the server answers tool calls such as search, context, callers and impact from the SQLite graph.

The same process also watches your project for file changes and keeps the index in sync, so answers don't go stale while the agent edits code.

{
  "mcpServers": {
    "codegraph": {
      "type": "stdio",
      "command": "codegraph",
      "args": ["serve", "--mcp"]
    }
  }
}

The installer writes this into ~/.claude.json for Claude Code, so you rarely edit it by hand.

The agent launches the server over stdio, so it starts and stops with the agent session. That is exactly why the connect-time catch-up exists: it reconciles anything that changed while no server was running.

CodeGraph exposes ten tools to the agent:

In practice an agent rarely uses all ten. The common pattern is context, then explore, with trace for path questions, impact before an edit and status when something looks stale.

codegraph_context maps a task or feature area in a single call. It composes search, node lookup, callers and callees, then returns entry points, related symbols and code snippets.

The agent instructions tell it to call this first, before anything else, when it needs to understand an area. The same capability is available on the command line as codegraph context <task> with --format and --max-nodes, and in code as buildContext().

codegraph context "fix login bug" --max-nodes 20

Think of it as the cheap first move. Instead of guessing filenames and grepping, one call returns the likely entry points and the symbols around them, and the agent can then zoom in with explore or node.

codegraph_trace answers "how does X reach Y?". Give it two symbols and it returns the call path between them in one call, with each hop's source body inline.

Its useful trick is following hops that text search can't: dynamic dispatch such as callbacks, React re-renders and interface-to-implementation jumps. With grep you'd find the name at each end and guess the middle.

Use it for questions like "how does a request reach the database?" where the interesting part is the chain, not either endpoint.

codegraph_impact shows what is affected if you change a symbol. It walks callers outward from that symbol to build its impact radius, so the agent can see the blast radius before it edits anything.

On the CLI, codegraph impact <symbol> takes --depth to control how many hops to follow and --json for machine-readable output. In the library, the equivalent is getImpactRadius(nodeId, depth).

codegraph impact parseConfig --depth 3

A typical use: before changing the signature of a widely used helper, the agent calls impact, sees which callers fan out, and plans the edit and tests accordingly. Pair it with codegraph affected to find the test files that cover the touched modules.

codegraph_explore returns the source of several related symbols, grouped by file, plus a relationship map, all in one budget-capped call.

Agents typically call codegraph_context to find the right area, then one codegraph_explore to read the relevant code, and stop. The returned source is treated as already read, so the agent shouldn't re-open those files.

The budget cap keeps one call from flooding the context window with source.

Compared with calling codegraph_node for one symbol at a time, explore saves round trips when the answer spans several functions, say a handler, its service and the repository it calls. Use codegraph_node when you only need one signature.

About 22 languages. Full support covers TypeScript, JavaScript, Python, Go, Rust, Java, C#, PHP, Ruby, C, C++, Swift, Kotlin, Scala, Dart, Svelte, Vue, Liquid, Pascal/Delphi, Lua and Luau.

Objective-C is partial: classes, protocols, methods, @property, #import and message sends work, but .mm (Objective-C++) files may parse incompletely.

There's nothing to configure per language. The parser is chosen automatically from the file extension.

Svelte and Vue single-file components get script extraction (Svelte 5 runes, SvelteKit routes, Nuxt page, API and middleware routes), and Luau adds type aliases and Roblox instance-path require. Mixed-language repos are fine because one graph spans every supported language in the project.

tree-sitter is the parser behind extraction. CodeGraph runs it on every supported source file to produce an abstract syntax tree, then applies language-specific queries to pull out nodes (functions, classes, methods) and edges (calls, imports, extends, implements).

Because tree-sitter is fast and error-tolerant, files that are mid-edit or slightly broken can still yield useful symbols. It only sees syntax, though, so linking a call to the right definition is a separate resolution step that runs afterwards.

Because the extraction queries are written per language, support is reported per language in the README, with Objective-C marked partial.

Nodes are code entities: functions, classes, methods and files, plus specialised ones like framework route nodes and React Native component and property nodes.

Edges are relationships between them: calls, imports, extends, implements and references. A route node, for example, is linked by a references edge to its handler.

Queries are just walks over this graph. A callers query follows incoming calls edges, and an impact query follows them outward for several hops.

Synthetic nodes exist too. For Expo Modules, the DSL literals produce synthetic method nodes that then resolve through ordinary name matching, so the graph includes entities created from framework conventions as well as what the parser sees directly.

It finds the test files affected by a set of changed source files by tracing import dependencies transitively.

codegraph affected src/utils.ts src/api.ts
git diff --name-only | codegraph affected --stdin

Use it to shrink a test run. Given a change to a utility module, it walks importers outward up to the depth limit and returns only the test files that transitively depend on it. It works on import dependencies, so treat it as a fast filter rather than a guarantee for code reached through runtime lookups.

codegraph status prints statistics and health for a project's index. The MCP equivalent is codegraph_status, which agents use to check whether the index is trustworthy.

If edits are still waiting to be synced, you'll see a Pending sync section naming the files and how long ago they were edited. It also reports a Journal: line; anything other than wal means WAL mode couldn't be enabled on that filesystem.

A good habit is to run it once after the first index to confirm the counts look sane, and again whenever an agent claims a symbol doesn't exist.

These are the commands you'll use day to day, grouped by whether they set things up, build the index, or query it.

Run codegraph uninstall. It reverses the installer by stripping CodeGraph's MCP server config, instruction blocks and permissions from every agent it configured.

Use --target to limit removal to specific agents and --yes to run without prompts. Your project indexes in .codegraph/ are not touched, so remove those per project with codegraph uninit.

A clean removal is therefore two steps: codegraph uninstall for the agent configs, then codegraph uninit in each project whose index you want gone. --target is handy if you only want to detach one agent, say Cursor, while keeping Claude Code wired up.

It's zero-config, so the defaults do the filtering. CodeGraph skips three groups of files:

• Dependency, build and cache directories such as node_modules, vendor, dist, build, target, .venv, Pods and .next, even with no .gitignore.
• Anything in your .gitignore, via git in repos and by reading the file directly in non-git projects (root and nested).
• Files larger than 1 MB, which catches generated bundles, minified JS and vendored blobs.

The goal is a graph of your code rather than third-party noise.

CodeGraph recognises web-framework routing files and emits route nodes linked by references edges to the handler class or function. As a result, asking for the callers of a view or controller also surfaces the URL pattern that binds to it.

The README lists 14 frameworks in total, including NestJS, Laravel, Drupal, ASP.NET, Vapor and React Router.

Import the default export, initialise or open a project, index it, then query. The library mirrors what the CLI and MCP tools do.

import CodeGraph from '@colbymchenry/codegraph';

const cg = await CodeGraph.init('/path/to/project'); // or CodeGraph.open(...)
await cg.indexAll({ onProgress: p => console.log(p.phase, p.current, p.total) });

const results = cg.searchNodes('UserService');
const callers = cg.getCallers(results[0].node.id);
const ctx = await cg.buildContext('fix login bug', { maxNodes: 20, includeCode: true, format: 'markdown' });
const impact = cg.getImpactRadius(results[0].node.id, 2);

cg.watch();   // auto-sync on file changes
cg.unwatch(); // stop watching
cg.close();

Remember to call close() when you finish.

CodeGraph.init sets up a new project index, while CodeGraph.open attaches to an existing one. indexAll takes an onProgress callback reporting phase, current and total, which is handy for a progress bar in your own tooling.

searchNodes finds symbols by name, getCallers walks incoming call edges, buildContext assembles task context (maxNodes, includeCode, format), and getImpactRadius takes a node id plus a depth. watch() turns on the same auto-sync the MCP server uses.

Reach for the library when you're building your own tooling on top of the graph rather than going through MCP.

It adds a short CodeGraph section that tells Claude how to behave. If .codegraph/ exists, Claude should answer directly with CodeGraph tools instead of delegating exploration to a file-reading sub-agent or a grep/read loop, and usually finish with zero file reads.

It also includes a tool-by-intent table: context to map an area, trace for "how does X reach Y", explore for several symbols at once, search for names, callers/callees for one hop, impact before editing and node for one symbol.

If .codegraph/ doesn't exist, Claude is told to ask at the start of a session whether to run codegraph init -i.

No data leaves your machine. The graph is a SQLite file in the project, extraction runs through tree-sitter locally, and there are no API keys or external services involved.

The installer also ships a bundled runtime, so nothing needs compiling or downloading at query time. The agent still talks to its own model provider as usual; CodeGraph just means your index and the structural queries stay on disk.

That makes adoption easy in restricted environments: no accounts and nothing to audit beyond a local file you can delete any time with codegraph uninit. Whether the agent's own model calls leave the machine depends on the agent, not on CodeGraph.

The installer runs interactively by default, and flags let you script it for CI or dotfiles.

codegraph install --yes
codegraph install --target=cursor,claude --yes
codegraph install --print-config codex

A common setup is --location=global once on a workstation so every project gets the MCP server, then codegraph init -i per repo. For a dotfiles repo or CI image, combine --yes with an explicit --target so the result doesn't depend on which agents happen to be installed. Use --print-config when you only want the snippet to paste into a managed config.

Through three layers that work together while the MCP server is running, so an agent never gets a silent wrong answer between an edit and the next sync.

1. File watcher with debounced sync. A native OS watcher (FSEvents, inotify or ReadDirectoryChangesW) captures source-file creates, modifies and deletes, then re-indexes after a quiet window. The default is 2000 ms.
2. Per-file staleness banner. If a tool response touches a file that's still pending, it carries a warning telling the agent to read that file directly.
3. Connect-time catch-up. When the server (re)connects, it reconciles the index with the working tree before answering the first query.

flowchart LR
  A["Agent edits Widget.ts"] --> B["Native watcher fires"]
  B --> C["2s debounce window"]
  C --> D["Incremental sync"]
  D --> E["Next query sees Widget.ts"]

CodeGraph prepends a warning banner to the tool response that names the still-pending file and tells the agent to Read it directly for live content. This covers the short debounce window between an edit and the re-index.

Pending files that the response doesn't reference show up as a small footer instead of a banner.

The README says it has been validated with Claude Code, where the agent literally announces that it is reading the file directly before opening it. The trade-off is one extra read for that file, in exchange for never trusting stale graph data.

Practically, a freshly edited file may cost the agent one extra read, but the graph never silently serves stale structure for it. Once the debounce window passes and the sync completes, the banner disappears and queries return the new symbols.

When the MCP server (re)connects, CodeGraph runs a fast reconciliation of the index against the working tree before answering the first query. It compares (size, mtime) and a content hash to spot files that changed.

This absorbs edits the watcher never saw: a git pull from the terminal, changes from another editor, or a previous agent session that exited. The first tool call of the next session therefore starts from a correct graph.

Because it runs before the first query is answered, that first call may take slightly longer on a big tree; later calls aren't affected. It complements the watcher rather than replacing it: the watcher handles live edits, and catch-up handles everything that happened while nothing was watching.

Indexing is a four-stage pipeline, and each stage hands a cleaner artifact to the next.

1. Extraction. tree-sitter parses each file into an AST. Language-specific queries emit nodes (functions, classes, methods) and edges (calls, imports, extends, implements).
2. Storage. Everything goes into .codegraph/codegraph.db, a SQLite database with FTS5 full-text search.
3. Resolution. References are resolved: function calls to definitions, imports to source files, class inheritance, plus framework-specific patterns such as routes.
4. Auto-sync. The MCP server watches the project, debounces for two seconds, filters to source files and syncs incrementally.

flowchart LR
  S["Source files"] --> T["tree-sitter AST"]
  T --> X["Nodes and edges"]
  X --> D[(SQLite + FTS5)]
  D --> R["Resolve calls, imports, inheritance"]
  W["File watcher"] --> D

Extraction only knows syntax, which is why resolution is a separate pass: a bare save() call has to be matched to the right definition.

SQLite gives CodeGraph a single-file, zero-service store: one .codegraph/codegraph.db per project, no server to run and nothing leaving the machine. That fits the "100% local, no config" promise.

FTS5 supplies the name search behind codegraph_search, so finding a symbol across a large repo doesn't mean scanning files.

WAL mode matters too. On the bundled runtime's node:sqlite, concurrent reads never block on a writer, which is what lets an agent query the graph while the watcher is mid-sync. On network shares or WSL2 /mnt, WAL may be unavailable and you can hit lock contention.

The trade-off is that SQLite is an embedded engine rather than a dedicated graph database, so callers and impact are queries over symbol and edge tables. For a local, read-mostly index, that simplicity is the point.

Because the structure is already computed. Without it, an agent spends most of its budget on discovery: find, ls and grep to locate the right files, then Read to open them, often through sub-agents that repeat the same work.

With the index, the agent calls codegraph_context to map the area, then one codegraph_explore for the relevant source, and stops, usually with zero file reads.

These are medians from the project's benchmark, so treat them as indicative rather than guaranteed.

There's a second effect: fewer calls mean fewer tokens re-sent as context, which is why the README reports a 57% average token drop next to the 71% drop in tool calls. The effect also grows with repo size: on VS Code (~10k files) tool calls fell by 85%.

The README describes a controlled A/B run against seven open-source repositories (re-validated on v0.9.4 on 2026-05-24).

1. Each arm runs claude -p headlessly with Claude Opus 4.7 and --strict-mcp-config.
2. WITH enables CodeGraph's MCP server; WITHOUT uses an empty MCP config. Built-in Read, Grep and Bash stay available to both.
3. Each repo gets one architecture question, run 4 times per arm, and the median is reported.
4. Cost is the run's total_cost_usd; tokens include cached input plus output; tool calls include those inside spawned sub-agents.
5. Repos are cloned with --depth 1 and indexed by the same CodeGraph build that serves them.

The headline average was 35% cheaper, 57% fewer tokens, 46% faster and 71% fewer tool calls. It's a vendor benchmark with one question per repo, so your mileage will vary.

The gap comes from how hard the agent without CodeGraph has to work on each repo. On Tokio it fanned out to 53 tool calls and a $2.41 median run, versus $0.42 with CodeGraph: 82% cheaper. On OkHttp it needed only 11 calls and the cost was essentially identical ($0.47 vs $0.47), so only 2% cheaper.

The README's explanation is that gains scale with codebase size and that on small repos native search is already cheap. Note OkHttp isn't small, which shows per-repo numbers also move run to run with how much the without-arm thrashes.

codegraph index does a full index of the project; codegraph sync does an incremental update of only what changed.

codegraph init -i performs the first index for you. In normal agent use you rarely run either by hand because the MCP server syncs automatically.

A sensible rule is to let the watcher or sync do the routine work and use index --force only when you suspect the database is out of step with the tree and a plain sync didn't fix it.

Only in a few cases, because auto-sync normally keeps the index current.

• The watcher is disabled, for example in a sandboxed environment or when CODEGRAPH_NO_DAEMON=1 is set.
• You're scripting against the index outside an agent session and want a pre-flight sync at the start of the script.
• You suspect a symbol is missing and want to rule out a stale index before digging further.

codegraph sync
codegraph status   # confirm nothing is pending

If the MCP server is running with the watcher on, a manual sync is redundant.

Manual runs are cheap because sync is incremental, so there's no penalty for running one defensively before a scripted query. Finish with codegraph status to confirm the Pending sync section is empty.

codegraph_trace returns the whole path between two symbols in one call. Chaining codegraph_callers or codegraph_callees walks the flow one hop per call, so the agent has to decide which branch to follow each time.

Use trace when you know both ends. Use callers and callees when you're still exploring around a single function.

codegraph_context is the map; codegraph_explore is the reading. Context composes search, node, callers and callees to show where a task lives and which symbols matter. Explore then returns the actual source for several related symbols, grouped by file, with a relationship map.

In practice you rarely need both for a small question. For "where is X defined and who calls it?", context alone may be enough. For "how does the request flow work?", follow context with one explore (or a trace) so the agent actually sees the code on the path.

Because CodeGraph only pays off when it's queried directly. If the main agent hands exploration to a file-reading sub-agent, that sub-agent reads files regardless, and CodeGraph becomes overhead instead of a saving.

The injected instructions therefore say: answer "how does X work?", architecture and trace questions in a handful of CodeGraph calls, treat the returned source as already read, and reach for raw Read or Grep only to confirm a detail the graph didn't cover.

This is a prompting rule, not a technical block. It exists because the benchmarks showed that the savings come from skipping the grep-and-read loop entirely.

Tree-sitter stops at each language boundary, so CodeGraph adds synthetic edges using the @objc auto-bridging rules. That lets trace, callers, callees and impact run end to end across Swift and Objective-C.

• Swift to ObjC: a Swift call obj.foo(bar:) is matched to the selector -fooWithBar:, including init, property and protocol forms and Cocoa preposition prefixes (With, For, By, In, On, At).
• ObjC to Swift: [obj fooWithBar:] is matched to @objc func foo(bar:) using reverse-bridge name candidates, and CodeGraph verifies the @objc exposure in source.

Edges created this way carry provenance: 'heuristic' and synthesizedBy: 'swift-objc-bridge'.

It parses the native-side declarations to build a map from JS names to native methods, then adds cross-language edges so queries connect end to end.

Events are linked through a synthesised channel keyed by the literal event name. Fabric and Paper view components are handled by matching the JSX tag to a spec and a native class by naming convention.

It marks an edge as inferred by a bridge rule rather than read directly from syntax. Cross-language bridges (Swift/ObjC, React Native, Expo, Fabric) emit edges tagged provenance: 'heuristic'.

Each of these also carries metadata.synthesizedBy with a stable channel name, such as swift-objc-bridge, rn-event-channel, fabric-native-impl or expo-module-extract.

The point is transparency: an agent looking at a trace can tell at a glance how each hop got into the graph and weigh it accordingly, rather than trusting every edge equally.

Contrast this with edges read straight from the AST, such as an ordinary call resolved by name. Those are structural facts; heuristic edges are informed matches built from conventions like selector naming or literal event names, and the README says each bridge was validated on small, medium and large real codebases.

Two environment variables control it. CODEGRAPH_WATCH_DEBOUNCE_MS sets the quiet window before a sync; the default is 2000 ms and the value is clamped to 100 ms to 60 s. CODEGRAPH_NO_DAEMON=1 turns the watcher off.

# faster sync after edits
export CODEGRAPH_WATCH_DEBOUNCE_MS=500

# sandboxed environment, watcher disabled
export CODEGRAPH_NO_DAEMON=1
codegraph sync

A shorter debounce makes the graph catch up sooner but may trigger more frequent syncs during bursts of edits. With the watcher disabled you must run codegraph sync yourself.

Raise the debounce if your editor or formatter rewrites many files on save; lower it if you want the agent to see edits almost immediately. The staleness banner still protects the agent during the window, so a longer debounce costs freshness, not correctness.

Pipe the changed files into codegraph affected --stdin --quiet to get just the test file paths, then run only those tests.

#!/usr/bin/env bash
AFFECTED=$(git diff --name-only HEAD | codegraph affected --stdin --quiet)
if [ -n "$AFFECTED" ]; then
  npx vitest run $AFFECTED
fi

--quiet outputs paths only, which is what a shell loop wants. Use --filter to point at a custom test pattern such as "e2e/*", and --depth to limit how far import chains are followed (default 5).

The check needs an initialised index in the CI workspace.

Build or restore the index as part of the job, since a cold checkout has no .codegraph/. When nothing is affected, the empty-string check skips the test run entirely, which is where the CI time is saved. Because the result is import-based, keep a full test run on your main branch to catch gaps.

Current builds shouldn't produce them, so start by finding out why yours does.

1. Check your version. Pre-0.9 installs lack the bundled runtime. Reinstall with the install script or npm i -g @colbymchenry/codegraph@latest.
2. Run codegraph status and read the Journal: line. If it isn't wal, WAL couldn't be enabled on that filesystem.
3. Move the project to a local disk. Network shares and WSL2 /mnt are the usual culprits, because there reads can block on writes.

Current builds use Node's built-in node:sqlite in WAL mode, where concurrent reads never block on a writer.

If you're still stuck after those three steps, note whether the error appears only when several agents or terminals touch the same project at once, and include your codegraph status output when you report it.

Work from the cheapest check to the most specific.

1. Wait a couple of seconds. The MCP server auto-syncs on save after the debounce window.
2. Run codegraph sync and then codegraph status to confirm nothing is pending.
3. Check the language. Is the file extension supported (and Objective-C .mm only partially)?
4. Check exclusions. Is the file under node_modules, dist or another default-excluded folder, matched by .gitignore, or larger than 1 MB?

If a file is excluded by default but you do need it, add a .gitignore negation such as !vendor/ to bring it back.

One last diagnostic: run codegraph query <name> from the terminal. If the CLI finds the symbol but your agent doesn't, the problem is on the agent or MCP side rather than in the index.

Check from the bottom up: the project, the config, then the process.

1. Confirm the project is initialised and indexed. The error "CodeGraph not initialized" means you need codegraph init first.
2. Verify the path in your MCP config points at a codegraph binary that is on the PATH.
3. Run codegraph serve --mcp by hand in a terminal. If it fails there, the agent won't fare better.
4. Compare configs. codegraph install --print-config <id> prints the expected snippet without writing files.
5. Restart the agent so it reloads the MCP server list.

If the server runs fine by hand but the agent still can't see it, check whether you chose a global or project-local install (--location) and that you're editing the config your agent actually reads.

Most of the speed comes from indexing less noise and syncing incrementally.

• Make sure big directories are excluded. node_modules, dist, build and similar are skipped by default, and your .gitignore adds to that.
• Ignore generated code. Anything larger than 1 MB is skipped automatically; add other generated paths to .gitignore.
• Use --quiet on codegraph index to reduce output overhead.
• Prefer sync over a full re-index. Reserve codegraph index --force for a clean rebuild, since the watcher and sync only touch changed files.

The troubleshooting guide's first suggestion for slow indexing is exactly this: check that node_modules and other large directories are excluded.

Add a negation to your .gitignore: !vendor/. That's the explicit opt-in.

# .gitignore
!vendor/

The defaults apply uniformly, so simply committing a dependency or build directory doesn't force it into the graph. You have to say so. Then run codegraph sync (or wait for auto-sync) and the folder's symbols appear.

Be aware that vendored code can be large and noisy, so only do this when you genuinely need to trace into the dependency.

Afterwards, confirm with codegraph query on a symbol you know lives in that folder. Remember that the 1 MB per-file limit still applies to vendored files.

For a very small repo the margin narrows, but CodeGraph still comes out ahead on call count in the project's numbers. On Gin (~110 files) CodeGraph was 21% cheaper and used 40% fewer tool calls, versus 82% cheaper on Tokio.

The README's own explanation: on a small repo native search is already cheap, so there is less discovery cost to remove. You also pay a setup cost (install, codegraph init -i) and carry a .codegraph/ index.

Rule of thumb: skip it for a handful of files you already know, adopt it as repos grow, or when agents keep fanning out into dozens of grep and read calls. These figures come from the project's benchmark, so measure on your own code.

The CodeGraph tools have nothing to query, so the agent falls back on grep, glob and Read. The installed instructions anticipate this: at the start of a session, Claude is told to ask whether you'd like to initialize CodeGraph.

The suggested prompt is along the lines of "I notice this project doesn't have CodeGraph initialized. Would you like me to run codegraph init -i to build a code knowledge graph?"

If a tool is called anyway, you'll see "CodeGraph not initialized", and the fix is to run codegraph init in the project directory. The global install and MCP registration don't create any per-project index.