Documentation

Get started

reproit drives your app like a user, finds bugs, and hands each one back as a repro: a saved case that fails the same way every time. This gets you from install to your first reproducible bug, then to catching them in production.

Install the CLI

macOS and Linux:

curl -fsSL https://reproit.com/install.sh | sh

Windows (PowerShell):

irm https://reproit.com/install.ps1 | iex

Both scripts verify a published checksum and honor REPROIT_VERSION to pin a release. You can also cargo install from source. The CLI is key-free and runs fully offline; nothing is sent anywhere until you opt into the hosted cloud.

Your first bug

From inside your app's project, the three core verbs:

# build a graph of your app's screens (optional, good for a first look)
reproit map
# -> mapped 47 screens

# audit the bugs visible on every reachable screen, saving annotated clips
reproit scan --record
# -> 6 issues across 4 screens

# hunt deeper for sequence-dependent bugs (crashes, jank, hangs, leaks)
reproit fuzz --all
# -> 3 repros found.  id fnd_a3f2c1b8e0d5

# confirm a finding really reproduces, then save it as a regression guard
reproit check fnd_a3f2c1b8e0d5   # -> fail (3/3). real bug, reproduced every run
reproit keep  fnd_a3f2c1b8e0d5 --as login-crash

Point reproit at a running app by URL, a terminal program, or a framework config. The full command reference lives in the CLI guide.

How a repro works

Two properties make a reproit repro different from a bug report:

• It is deterministic. A bug is captured as a seed plus an exact sequence of actions. Replay it and you get the identical failure on any machine, in CI, or on a teammate's laptop.
• It survives your app changing. reproit identifies a screen by its structure, never its on-screen text, so a repro is unaffected by copy edits or translations. The same screen in English and German is the same screen.

reproit check classifies every replay into one of four outcomes, which is what makes it safe to run in CI: pass, regression (a guarded bug came back), flaky, or stale (the path no longer exists). A kept bug lands quarantined until its first green, so adding a guard never breaks your build on day one.

Use it with your AI agent

reproit has no model inside it. The engine that finds and replays bugs is plain, offline, and key-free; your coding agent plugs in from the outside over MCP to read a repro and write a fix, and reproit then proves the fix by replaying it. Add the MCP server to Claude Code, Cursor, or any MCP client:

reproit mcp   # prints the MCP server config for your agent

The agent gets tools to list repros, read the exact failing action sequence and a fault-localized suspect, and re-run check after editing. It fixes; reproit decides whether the fix holds.

Capture production crashes

The same determinism works the other way around: a crash in your shipped app becomes a repro on your machine. Drop in the SDK for your platform, and it captures the structure of what happened, never your users' data: screen signatures, the interaction path, and PII-safe input fingerprints (a field's length and character classes, never its value). A card number and a phone number of the same length produce the identical fingerprint.

SDK setup by platform

Each SDK sends the same structural signal, so a crash on any platform reproduces the same way. Pick yours:

The web SDK is one snippet:

import { ReproIt } from 'reproit-web';

ReproIt.start({
  appId: 'your-app',
  endpoint: 'https://ingest.reproit.com',
  key: 'your-project-key',
  redactLabels: false,   // set true to send structure only, no visible text
  sampleRate: 1.0,
});

Nothing is hardcoded to a reproit server: the endpoint is yours to set, and self-hosters point it at their own. Full per-SDK options are in each SDK's README, linked above.

The cloud loop

With the SDK reporting and a project connected to your repo, the loop closes on its own:

• Crashes arrive and are grouped into buckets by structural signature, ranked by impact.
• To reproduce one, the cloud dispatches a job to your CI (via GitHub repository_dispatch), which runs reproit cloud reproduce and posts back a verdict: did it reproduce, N out of N.
• You pull the repro locally, fix it, and reproit check confirms the fix, on your machine and then in the same CI.

reproit cloud buckets              # impact-ranked list of production bugs
reproit cloud reproduce <bucket>    # turn a production crash into a local repro

Because the reproduction executes in your CI, reproit never needs your source, and the artifact you get is a test that actually fails, not a suggested guess.