Graft gives agents a local symbol graph they can query
Graft parses a repository into linked local files and a per-symbol wiring graph. An agent can ask for likely code, list a file's public surface, trace callers, search every indexed symbol, map directories, or estimate the blast radius of a diff. The structural path uses tree-sitter and needs no model account. This is useful when an agent repeatedly opens the same entry points and import chains at the start of each task.
Our checkout contained 255 files, about 38,337 source lines, and 43.7 MB before dependencies. That is a moderate tool codebase rather than a thin wrapper around an API. Graft supports 22 languages at two parsing levels, with richer cross-file resolution for TypeScript, JavaScript, Python, Go, Java, and R. Files in unlisted languages are skipped, so mixed-language teams should measure how much of their repository the graph can see.
The structural graph works without sending source to a model
Plain graft build, freshness checks, queries, maps, and call traversal run locally through deterministic parsers. The generated graph is a cache under the repository and is added to .gitignore. Each query checks the working tree first, so staged and unstaged edits can affect the result. A team can use that layer without supplying a model key, and it can inspect the markdown and JSON artifacts directly.
The optional deep pass has a different trust boundary. It sends file material through the provider chosen with GRAFT_PROVIDER, GRAFT_API_KEY, and GRAFT_MODEL. OpenAI-compatible endpoints can use a custom base URL, while Anthropic has a native path. Our 301 MB installed footprint does not include provider usage or model charges. Teams with sensitive source should decide which layer is allowed before running graft build --deep.
What happened when we ran it
Our run at commit 65a76e5 installed 50 npm packages in 16 seconds. The dependency tree occupied 301 MB in an unprivileged Node 22 Debian container with 3 CPUs and 8 GB of RAM. The TypeScript and viewer build completed successfully in 7 seconds. No provider key or external service was present, so these results cover repository mechanics rather than deep graph quality.
The test command succeeded after 69 seconds. Node's test runner reported 836 passed and 0 failed out of 836. Our scan found a tests directory and 6 CI workflow files, which matches the amount of exercised behavior better than a project with only a compile check. Npm audit still reported 1 known high-severity vulnerability, with 0 critical, 0 moderate, and 0 low findings.
Agent setup can touch repository and machine-wide files
graft init detects supported agents and offers to add their native instruction files. Claude Code receives a skill, project MCP registration, statusline, and hooks. Codex can receive an AGENTS.md section, an MCP server entry in ~/.codex/config.toml, and a post-edit hook under ~/.codex/. The README labels those Codex writes as machine-wide because they affect every repository opened by that user.
Those changes are controllable, but they should be reviewed. --dry-run prints the targets, while --agents, --no-global, --no-mcp, and --no-hooks narrow the installation. With 50 installed packages and no daemon required for the default graph, runtime maintenance is modest. Configuration scope is the sharper concern: a local context helper should not gain global hooks merely because a user accepted defaults without reading the file list.
Six MCP tools cover search, maps, calls, and freshness
The MCP server exposes 6 tools for ranked code lookup, file signatures, call tracing, exhaustive pattern search, a repository map, and graph freshness. These are sensible primitives for agents because each returns a bounded view instead of pasting an entire repository into context. Claude Code has deeper hook integration, while Codex and other MCP clients can call the same server through their own configuration.
Deep integration also changes how prompts are prepared after edits. Graft can refresh structural data, surface dependents, and insert matching nodes into later work. That may save exploration, but generated context can still omit a relevant edge or overstate a model-written summary. The 836 passing project tests establish that its own tested functions worked in our sandbox. They do not establish accuracy for every language, framework convention, or repository layout.
Graft's benchmark is useful evidence that still needs local replication
The README reports a 50-instance SWE-bench Verified comparison using Claude Sonnet 5: its Graft arm resolved 33 instances and the cold arm resolved 27. It also reports fewer tokens, tool calls, API requests, and wall-clock time for the resolved cases. The project describes the images, grader, model, and arm difference, which makes the claim more inspectable than an unexplained speed multiplier.
Those benchmark results belong to Graft's maintainers, while our lab measured install, build, tests, and audit only. A team's own task mix may have shorter discovery paths, unsupported languages, or repository conventions that change the result. Trial it on repeated bug-localization and cross-file tasks, record answer accuracy as well as cost, and keep a cold control. Our 7-second build makes such an evaluation cheap to start.
Current activity is high, with two maintenance warnings
GitHub redirected the requested NanoNets path to the current trailhq/Graft repository. It recorded a push on August 25, 2026, 4,896 stars, and 79 combined issues and pull requests. GitHub returned no latest release, although the checked-out package manifest says 0.12.0. The push date and open discussion show current activity; the combined count does not distinguish defects from proposed changes.
Open issue 234 identifies a concrete support mismatch: Graft declares Node 20 or newer, while direct dependency Commander 15 declares Node 22.12 or newer. That matters for teams following the manifest or CI matrix literally. Alongside the 1 high-severity audit finding, it keeps maturity below the test count alone. Graft is worth testing for agent-heavy work, provided the team pins a revision, reviews init's writes, and clears its dependency policy first.