Documentation

State a property that must hold in your code, in plain English, and RedMirror searches your real code for a concrete way to break it. Any security or correctness rule, not a fixed catalog; you get a reproducible counterexample, or a bounded proof it holds.

Custom angles are the point of the engine. Most scanners match a fixed list of bug patterns. RedMirror checks your rule: hand it a requirement with --focus (say "a user can never withdraw more than their balance", "deleting a task removes it for every user", or "only the owner can change the fee"), and it turns that into a checkable property and hunts your real code for an input that violates it. Security, business logic, data integrity: if a rule is either true or has a counterexample, RedMirror can chase it down. See §5.

1. Install

RedMirror is a single native binary. Install it in one line, paste into your terminal, or hand it to your coding agent:

# macOS / Linux
curl -fsSL https://redmirror.io/install.sh | sh

# Windows (PowerShell)
irm https://redmirror.io/install.ps1 | iex

The installer downloads the binary, puts it on your PATH, and prints the next steps. After that it self-updates, redmirror update downloads and replaces the binary in place, so you never reinstall (and redmirror nudges you when a new version is out).

Prefer to grab the binary yourself? Download it from the home page, chmod +x redmirror, and move it onto your PATH.

Supported languages: JavaScript, TypeScript, Python, Go, Rust, Java, C#, Ruby, PHP, and C/C++.

2. Sign in & get a key

Sign up in your browser at redmirror.io/wallet: connect your wallet, add your name and email, and your account is created instantly with $1 of free credit. Then mint an API key on the dashboard and sign the CLI in with it:

redmirror login --key rm_live_xxxxxxxx

Or set it directly (handy for CI):

export REDMIRROR_API_KEY=rm_live_xxxxxxxx
export REDMIRROR_SERVER=https://redmirror.io

The key is the only credential the CLI holds, and it is useless except against your account.

3. Quickstart

# estimate what a scan will cost FIRST - runs locally, free, no tokens spent
redmirror estimate ./my-project --subsystem src/billing
    # -> estimated cost: $0.27  (likely $0.12 - $0.71)

# scan a repo (or a subfolder) - findings stream back as it goes
redmirror scan ./my-project

# focus the scan on a specific concern you care about
redmirror scan ./my-project --subsystem src/billing \
    --focus "a user can never withdraw more than their balance"

# scan on a cheaper tier - same engine, lighter models (see §9)
redmirror scan ./my-project --provider tresor

Each finding prints a severity, a confidence, and a one-line reason. Confirmed findings come with a reproduction; refuted ones are marked so you can ignore them.

4. Commands

5. Custom angles: the core of the tool

This is what sets RedMirror apart from a linter or a fixed-rule scanner. An angle is a property you want to hold ("this should always be true"), stated in plain language with --focus (one or several). RedMirror turns each into a checkable invariant and searches your real code for an input that violates it, handing back the exact steps that do. The rule can be anything you can phrase as true-or-false:

redmirror scan ./repo \
    --focus "only the owner can change the fee" \
    --focus "the total of all balances always equals the supply" \
    --focus "a request is never served before the auth check runs"

Good angles are concrete and falsifiable: a rule that is either true or has a counterexample. If you leave --focus off, RedMirror derives angles from the code itself (see the catalog below).

6. The angle catalog

Even with no --focus, a default scan runs ten built-in angles, each matched to the part of your code where it applies. Most are checked by walking the state machine, so the engine either proves them or hands back a counterexample; the input-facing ones (injection, cryptographic integrity, algorithmic DoS) run dedicated detectors. You can select any by name, for example --angles injection,crypto. The families:

Each family maps to standard CWE categories; the label is applied after the bug is found, never the other way around.

7. Recipes

Review a pull request

Scope to the area the PR touches and state what the change is meant to guarantee. The PR's own intent makes the best custom angle:

# a PR that adds per-tenant isolation to the reports API
redmirror scan . --subsystem src/reports \
    --focus "a request can only read reports that belong to its own tenant" \
    --focus "a refund can never exceed the original charge"

RedMirror checks the changed code against those rules and returns the file:line plus the steps that reach a violation, if one exists.

Find candidate bugs and vulns (no specific rule)

To sweep a subsystem with nothing specific in mind, drop --focus and RedMirror derives the angles from how the code guards itself (auth, bounds, conservation, lifecycle, state, injection, crypto, algorithmic DoS, safety; see §6). Estimate the cost first, then scan one security-dense directory:

redmirror estimate ./repo --subsystem src/auth     # free, no tokens
redmirror scan ./repo --subsystem src/auth -o auth-findings.md

You get a ranked worklist of candidates, each with a confidence band. Scope one subsystem at a time for the best signal per dollar.

Triage a finding

A confidence band is a starting point, not a verdict — but RedMirror already vets each candidate against your real code before it's shown, resolving the symbols a claim depends on (often defined in another file), not just the flagged line. A plausible-but-wrong finding is debunked instead of forwarded, so what you see has already survived scrutiny. To press on a specific concern, re-scan the subsystem with a --focus that names it:

redmirror scan . --subsystem src/auth \
    --focus "an old key cannot sign a valid token after rotation"

8. The sandbox (cuts false positives)

If you install the optional sandbox, RedMirror reproduces each confirmed finding by running a minimal probe in isolation on your machine. Findings reproduced in the sandbox sharply reduce the probability of false positives. Check whether it is available with:

redmirror doctor

Without the sandbox, RedMirror falls back to its proof step, so you still get a verdict, just with the sandbox you get a runnable reproduction too. It is used automatically when available; pass --no-sandbox to skip it.

9. Choosing a provider

A scan has two brains: the one that reads your code and proposes findings, and a stronger one it escalates to when the first cannot settle a hard call. --provider picks both, and with them what the scan costs you. Leave it off and you get aws, the default.

redmirror scan ./src --provider openrouter

What you actually trade. The cheaper tiers are not simply worse. On the first pass they find more, not less: the lighter models read more of your code for the same money. What you give up is the escalation, the second opinion on the findings the first pass could not resolve on its own. That is where the stronger model earns its price, and it is why aws stays the default.

Put plainly: on a ten-line file with a deliberate authorization hole, tresor confirmed it for $0.004 and aws confirmed it for $0.045. openrouter found the same issue for $0.004 but talked itself out of it at the escalation step. Cheap tiers are excellent for everyday scanning, CI and triage; reach for aws when a missed finding is the expensive outcome.

The scan prints the tier and its rate before it spends anything, and every call is billed at that tier's rate, so your bill never mixes them.

10. How it works

RedMirror is not a linter and not an LLM reviewer. The product is a proof or a counterexample.

• Lift. The CLI reads the relevant code on your machine and lifts it into a state-machine model - the variables that change, the transitions between them, and the guards that gate each one.
• Explore. For each part of the code, RedMirror identifies the single most-important property it must satisfy and checks that — together with any --focus angles you gave and the catalog above. A verification engine walks the model exhaustively, looking for any reachable state that breaks one.
• Refute or prove. If it finds one, you get the exact sequence of steps that reaches it - a reproducible counterexample. If it doesn't, within the search budget, you get a bounded proof.
• Widen & verify. A review pass surfaces broader candidates; an adversarial pass re-checks each against the real code and discards the weak ones.
• Reproduce. With the sandbox, confirmed findings are run for real to confirm they reproduce.

11. Coding agents

RedMirror ships a skill so your coding agent (Claude Code and compatible agents) can run scans for you: it picks a scope, runs the scan, and reads back the findings by impact. Read the agent skill

The fastest way: run redmirror skill --install and the CLI writes it into your agent's skills directory (for Claude Code, .claude/skills/redmirror/SKILL.md). Or point your agent at redmirror.io/skill.md directly. Then ask it to "scan the auth subsystem" or type /redmirror. It drives the same redmirror scan commands above: scoping deliberately, leading with a --focus requirement, and triaging each finding against the real code before reporting back.

Programmatic payment (x402)

For agents that run unattended, RedMirror is an x402 seller: top up your balance programmatically in USDC on Base over the standard HTTP 402 flow, with no browser wallet steps. Point an x402-capable client at the top-up endpoint, and it settles on-chain and credits your account, and the CLI then bills against that balance just like a card or manual top-up. Bring your own x402 client; RedMirror only sells.

12. Where your code goes

When you scan, the in-scope source (the subsystem you point RedMirror at) is uploaded to the analysis engine and processed in memory. You control exactly what is sent by scoping with --subsystem. Within that scope, a review fetches only the specific code windows it needs, not your whole tree. Any local caching that speeds up re-scans is written in your own repo directory, never uploaded.

The code a check needs also reaches the model provider behind the tier you choose (§9), and the tiers are not equal on this:

• --provider tresor is the most private. Every request runs inside a hardware enclave (a TEE): the provider cannot read your code even in principle, and each answer carries a signed receipt proving it was processed there.
• aws and openrouter are ordinary cloud model APIs, with those providers' own terms and no enclave guarantee.

If your requirement is that code never leaves your own network at all, no hosted tier meets it, and we would rather say so than reassure you. That is what the on-prem harness is for: the same engine, running against your own model, inside your infrastructure.