Skip to main content
Vaelor

Tool reference

impact_analysis: blast radius of changing a function

Updated 2026-10-07 · Engine v1.72.8

impact_analysis answers one question before you refactor: what might break if I change this function? It walks the call graph backwards from the symbol and classifies what it finds.

Parameters

Parameter Required Meaning
repo yes GitHub slug (owner/repo), a full GitHub URL, or an absolute local path
symbol yes Function or method name
depth no How far to follow transitive callers. Default 5, maximum 10
focus no A subdirectory (internal/auth) or space-separated keywords to limit scope
language no Limit to files of one language
max_bytes no Response budget. Default 8192; larger results are condensed and a note says how

If the symbol is not found, the tool suggests semantically similar ones.

What it returns

  • Direct callers and transitive callers, each with file, package, distance and confidence.
  • Hidden callers: string references to the name that the call graph does not treat as calls, reported at lower confidence. Only when the optional ox-codes sidecar is running.
  • Affected packages, a risk class (low, medium, high) with a score, and the tests that cover the symbol (only with the graph database, DATABASE_URL).
  • Hotspot callers: callers reordered by recent churn, so the files that change most come first.

Reading the result

Split the callers into tests and production code before judging size. On ParseFile in the Vaelor repository, 94 of the first 100 direct callers are tests, and the production surface is six functions plus 30 transitive ones. The full walkthrough, with the grep comparison and a check against gopls (249 of 249 symbols, same distances), is in Who calls ParseFile?.

Limits

  • The list is capped: it can print 100 of 104 direct callers. The response names the callers it leaves out and counts them in the total.
  • The tier field says how the answer was computed. enhanced is type-aware; basic matches calls by name from the syntax tree and can miss callers. On a new Go checkout the first call can come back basic while the type-aware pass warms (12 to 18 s on the measured example, the complete answer about 30 to 40 s after the call began); repeat the call.
  • A large result is condensed in the response (down to counts). Start the server with OUTPUT_DIR set to keep the full result as a file.
  • Static analysis only. Type-aware resolution applies to Go (go/types) and, through SCIP indexers, to TypeScript, JavaScript, Python, Java and Rust. The indexers ship in the Docker image; a from-source build without them, and every other language, uses tree-sitter call edges.
  • The first call on a repository builds the index and is slower than later calls (6 s on a checkout seen before, 12 to 18 s on a new one, against 0.6 s).

See Connect Claude Code to run it.

See it in use