30 sec5 min coredeep dive optional
ripwire is a zero-dependency C++23 CLI from Red Hat’s emerging-tech group that gives coding agents ranked call-graph context before they read a repo, and a blast-radius check on what they write.
- One self-contained binary, offline, installed in one line that also teaches your agent when to use it.
- The CLI is deliberately the main interface, with MCP integration optional, because standing tool definitions tax agent context in every session.
- Its quality checks are grounded in fifty years of replicated software-engineering research, with a public lineage table.
- Apache 2.0, from redhat-et, and the install works across Claude Code, Codex, Cursor, and other shell-capable agents.
Coding agents burn most of their context budget discovering what a human architect already knows: which files matter, what a change breaks, which tests to run. ripwire attacks exactly that step. Built by Red Hat’s emerging technology group, it hands your agent a ranked, deterministic call graph of the repo before it reads anything, then checks the edit afterward for blast radius and regressions.
- 2,335 stars
- 151 forks
- C++
- Apache 2.0
A map before the agent reads, a check after it writes
The tool has two working modes and they map to the two moments agents waste the most tokens. Before a change, you describe the task in words and ripwire returns a ranked call graph: what to touch, what that touch breaks, which tests reach the affected code. After the edit, it reports the blast radius, the tests that exercise the changed lines, and ten categories of quality findings that only surface when something got worse, alongside forgotten co-changes and fields read or written.
The determinism is the pitch. This is not a language model summarizing your codebase with plausible errors, it is a static index producing the same answer on every run, which is why the project leans on the ripgrep comparison. ripgrep did not displace grep by being cleverer at guessing intent, it won on speed and exact correctness, and ripwire is aiming for that same relationship to the context problem: boring, repeatable, and right, at a cost your token budget barely notices.
CLI first, MCP second, for a stated reason
The unusual design decision is recommending the plain CLI ahead of the MCP server, and the README argues it in token terms: a server’s verb definitions occupy agent context in every session, whether or not the agent calls them. A shell command, by contrast, draws on the window only for the moments it actually executes. For a tool whose whole value is spending fewer tokens on discovery, making the expensive-by-default integration the optional one is coherent, and it is rare to see a project reason about its own integration cost this explicitly. For teams already standardized on MCP the server remains a fine second step, but the default recommendation, cheapest interface first, is the one to follow unless you have a reason not to, and the reference guide spells out every other install route, hooks and per-agent skills included, for the cases that need them.
The MCP server exists and is one optional second step for teams standardized on MCP tooling, covered with every other route in the INSTALL document. But the one-line installer’s default path, a self-contained binary at ~/.local/bin plus task-shaped skills that teach the agent when to reach for each verb, works across the shell-capable agents, from aider and opencode to Cursor, Windsurf, Codex, and Claude Code, because anything that can run shell commands can use it.
The commands map to agent moments, priced in tokens
The command surface is organized around the moments where an agent would otherwise start reading files wholesale, and the README publishes a token cost for each, measured against the naive read-everything alternative on a real repository:
| Agent moment | Command | ripwire spend | Naive alternative |
|---|---|---|---|
| Orient me in this repo | ripwire . | ~5.6K tokens | 20K to 25K reading the README and architecture docs |
| Where is X handled? | --for | ~2.1K tokens | 4.9K to 20K grepping then reading |
| Who calls this function? | --callers | ~580 tokens | 40K to 52K grepping a symbol, mostly noise, then opening files |
| I have a stack trace | --from-trace | ~1.4K tokens | 124K to 298K grepping every frame name |
| I changed files, what breaks? | --situ | ~410 tokens | 3K to 132K diffing and grepping test paths |
The pattern in those numbers is the entire product argument: the questions agents ask most are the ones where naive discovery is most wasteful. The project also publishes a retrieval benchmark against named alternatives, with its --for path ahead of codebase-memory-mcp, repowise, graphify, the Aider repo map, and codeseek on both recall and mean reciprocal rank at a fraction of a second per query. Self-reported benchmarks deserve skepticism, but the methodology and per-tool versions are printed beside the numbers, which is more checkable than most.
The lineage table is the credibility flex
The part that separates ripwire from the weekly wave of agent tooling is its research grounding, published as a checkable artifact. A LINEAGE document folds in lessons from 49 repositories and 71 papers, each row naming the lesson taken and the code file it lives in, running from McCabe on complexity in 1976 and Halstead on volume in 1977 through seventeen papers from 2026 alone. Beside it sits a separately labelled roster of 237 tools reviewed and judged to have contributed nothing, with the two sets kept disjoint by construction.
That is a strange and effective form of honesty, and it extends to the benchmark tables, which print the competing tools by name and version rather than gesturing at unspecified alternatives. The settled measurements behind the quality checks are named and dated, the recent ones carry arXiv identifiers, and the negative survey preempts the where-did-this-come-from question by answering where it did not come from. For a tool that grades your code, showing its own grading is the right instinct.
Where it fits in a real agent workflow
Concretely, ripwire slots into the three phases of an agentic coding session. At the start, orienting beats repo-wide reads, and a single call replaces the ritual where an agent opens the README, then the architecture doc, then greps for the symbols it found. During planning, the impact and callers commands turn “figure out what this affects” from an exploration task into a lookup, which is where the largest naive costs hide. After the edit, the situational report and quality findings give the agent, or its reviewer, a deterministic second opinion on what changed and what might have regressed.
The interesting team effect is standardization. When everyone’s agent starts sessions the same way, with the same cheap map, code review conversations stop re-deriving context per reviewer and start from a shared artifact. That is the same argument that made ripgrep ubiquitous in editor tooling a decade ago, applied one layer up the stack, and it is why the ripgrep comparison is more than a tagline borrowed for the README banner.
Try it in one session
The install is deliberately boring, and the README suggests using it before finishing the page:
RIPWIRE_REPO=redhat-et/ripwire bash -c "$(curl -fsSL https://raw.githubusercontent.com/redhat-et/ripwire/main/scripts/install.sh)"
export PATH="$HOME/.local/bin:$PATH"
cd your-repo
ripwire . --for="the change you are about to make, in words"Then point your agent at it, one sentence in your session opener, and let the installed skills handle the rest; the security command can even vet third-party agent-skill files before you install them into your own setup.
What does terminality mean in the project’s own framing?
The README names its objective with a made-for-the-domain word: terminality. One question deserves one complete answer, and an answer that still needs follow-up greps and whole-file reads to become usable has not terminated anything. The reasoning is economic. Paying for a ranked call graph and then paying again for the searches it should have replaced is a double bill, and neither the token budget nor the developer gets anything back for it. Two design choices serve the goal. Counts that cannot be exact are labelled as floors instead of posing as totals, so an answer never overstates its own completeness, and the tool prefers the cheap deterministic lookup over the expensive traversal whenever both would settle the question. It is a useful standard for judging any context tool: score it by what is left to do after it answers, not by what it printed.
Who is behind it and what does Red Hat ET’s involvement signal?
redhat-et is Red Hat’s emerging technology group, an incubation space the company uses for experimental tooling, and that provenance shows in the engineering culture: zero runtime dependencies, a single self-contained binary, CI and release discipline, and documentation that argues its design decisions rather than listing features. The signal for adopters is nuanced. Emerging-tech projects carry Red Hat engineering standards without carrying product-level support commitments, so treat it as a well-built open-source tool from a serious team rather than a supported platform. The Apache 2.0 licence and the offline, local-only architecture keep the adoption risk low, and the C++23 choice is the kind of bet an incubation group can make that a product group usually cannot. Watch the release cadence rather than the star count to judge its trajectory, because a tool like this earns trust through benchmark transparency and maintenance discipline, both of which the project currently shows in unusual measure.
When is plain grep or your agent’s built-in search still the right call?
Often, and knowing the boundary keeps the tool valuable. Exact-string lookups, single-file questions, and mechanical renames do not need a call graph; grep and the editor answer them in one step, and routing everything through a heavy tool adds latency without adding truth. ripwire earns its place when the question is relational: what breaks if I change this signature, which tests actually execute this path, what must co-change with this edit. Those are questions naive search answers with a pile of files and a hope, and they are also exactly the questions where a wrong answer is expensive, because the agent then builds confidently on top of an incomplete map. A practical rule for agent workflows: if your prompt to the agent contains the phrase “figure out what this affects,” that is the moment to say “use ripwire on this repo” instead.
What are the ten quality kinds actually measuring?
The post-edit check reports across families, and the README documents each with its research lineage. The structural family measures shape: complexity, size, nesting depth, and how much of a body is deeply nested, parameter and local-variable counts, reported against absolute bars rather than a relative ranking. The lexical family covers the ten naming lint rules, short, wordy, case-mixed, uninformative names, and is the one family that ships a fix rather than only evidence. The confusion family catches syntactic idioms that mislead readers, implicit predicates and nested ternaries among them. The historical family scores churn against cognitive complexity to surface hotspots, with the honest caveat that churn is measured per file and inherited by every symbol in it. The colocation family measures how much a reader must fetch from elsewhere to reason about a function, and the state family traces mutable state a change could perturb that caller-based impact analysis never asks about. Unsound-by-construction counts are labelled as floors, which is the right default for static analysis honesty, and the reporting rule, only what got worse, keeps the post-edit output focused on regressions the change actually introduced rather than a wall of pre-existing findings nobody will fix.
What did trying it on unfamiliar code feel like?
The workflow claims hold up in the shape of the output. The ranked graph answers read like a guide who already knows the repo, front-loading the handful of files that matter for the stated task and naming the tests that reach them, which is precisely the context an agent needs before touching anything. The post-edit situational report is the quiet star: a few hundred tokens that answer the question every reviewer asks first, what else does this change touch. Two friction points to expect. The first run builds an index, so budget a cold start on large repositories, and warm runs are the fast ones the token table quotes. And the output format is dense by design, carrying counts and flags rather than prose, which agents parse happily and humans learn to skim, and which keeps the per-answer token costs quoted in the documentation honest in practice. Teams that internalize that output discipline stop asking for more context and start asking for better context, which is the shift that actually bends the cost curve. Teams adopting it should standardize the phrase that triggers it, telling the agent to use ripwire on the repo, so the habit sticks across sessions. The skills the installer drops in do most of that teaching already, which is why the project insists the one-line install is the whole onboarding for most people.
Why does a context tool need C++23 and zero dependencies?
The engineering choices are load-bearing, not aesthetic. Context tooling only wins adoption if it is faster than the alternative it replaces, and the alternative is a local grep, which sets a brutal speed floor. A compiled language with no runtime dependency keeps indexing and queries at that floor, keeps the artifact a single binary an agent can install in one line with no language runtime to bootstrap, and removes an entire class of supply-chain surface, which matters for a tool your agent runs against every repository you own. The C++23 choice is aggressive for portability, and the project mitigates it with prebuilt binaries on the install path, so the language bet is carried by the maintainers rather than by you. The offline, local-only architecture completes the argument: no telemetry, no service dependency, and nothing about your proprietary code leaves the machine.
What is the security command doing in a context tool?
It is the crossover feature that makes sense the moment you think about it: the same static reading of code that powers the call graph can vet an agent-skill file before you install it into your own setup. The security command scans a skill directory or file for the patterns that should stop an install, and the README frames it exactly as a gate for the agent-skill ecosystem rather than a general security product. In a world where teams paste third-party skills into coding agents with full shell access, a deterministic pre-install check from a tool you already trust is a sensible control point, and it costs a few hundred tokens. It does not replace a real security review, and the tool does not claim to, but it catches the obvious malicious patterns cheaply and offline.
ripwire is the first context tool we have picked that argues its own token economics, grounds its checks in fifty years of published research, and ships as one offline binary. Try it on your largest repo, where the call graph pays for itself in one session, and keep it in the agent’s toolbox before reaching for bigger context windows.