Repro Agent

A bug report tells you what someone saw. The Repro Agent tells you whether it still happens. It takes a recording that was analysed in Bug Report mode, reconstructs the flow from the clicks and navigations that were captured, drives that flow headlessly against an origin you control, and reports whether the failure actually fired.

It is built to be believable rather than encouraging. A verdict is only ever “reproduced” when a real signal was observed — the specific console error, the failing request, the missing element the plan named in advance as the thing to watch for. If it cannot make the bug happen, it says so, and that is a useful answer rather than a failure of the tool.

Before you can run it

• The recording must have been analysed in Bug Report mode. The agent works from the report’s steps and the interaction trail; other modes have neither.
• The recording must come from the Chrome extension or a web upload. Reports filed through the in-page widget are evidence-only — see below.
• You must have verified the target origin in your workspace. We will not drive a site you have not proven you control.
• Pro and above. Free plans cannot run it.

Running it

Open a bug report and choose Check if it reproduces. It is opt-in per report — nothing is re-driven automatically, because driving a flow means issuing real clicks and real requests against a real environment, and that is your decision to make one report at a time.

Or through the API:

curl -X POST https://api.scenerecap.com/v1/recordings/<id>/repro \
  -H "Authorization: Bearer sr_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "targetOrigin": "https://staging.example.com",
    "runs": 3,
    "bisect": false,
    "counterfactual": false
  }'

• targetOrigin — which environment to drive. Must be a verified origin on your workspace. Point it at staging to check a fix before it ships, or at production to confirm a report from a user.
• runs — how many times to attempt the flow. More runs distinguish a bug that always happens from one that happens sometimes; the verdict carries the rate.
• bisect — also compute the minimal repro. See below.
• counterfactual — also test alternative paths. See below.

The run is asynchronous. The result appears on the recording and is available from the API as the repro pass.

What the verdicts mean

• Reproduced — the flow ran and the failure signal fired. The result carries the rate (“3 of 3”), the signal that was observed, and a screenshot at the failing step.
• Not reproduced — the flow ran to completion and the failure never fired. This is a real answer, not an error: it is what you want to see after a fix, and it is worth taking seriously as evidence that a report is stale or environment-specific.
• Ambiguous — the flow ran but the evidence does not clearly support either conclusion. Read it as “a human still needs to look”, not as a soft yes.
• Blocked — it could not get far enough to find out: a login it cannot pass, a step whose target no longer exists, a consent wall. The result says what stopped it.

Minimal repro

With bisect enabled, a reproduced bug is re-run with steps removed to find the shortest sequence that still triggers it. A twelve-step report frequently collapses to three, which is the difference between an issue an engineer opens and one they postpone. It only runs when the bug reproduced — there is nothing to minimise otherwise.

Counterfactuals

With counterfactual enabled, the agent proposes plausible alternative paths to the same goal and drives those too, answering “does this happen on every route, or only this one?”. Each alternative comes back as avoided or still fails, which often localises the bug before anyone has opened the code.

Why widget reports are not re-driven

Reports filed through the in-page reporting widget carry console errors and failed network requests, but the widget does not capture a click and navigation trail from your visitors. There is therefore no flow to reconstruct, and the honest thing to do is not to guess at one. Widget reports are evidence-only: you get the failure signals, and they are never labelled as confirmed reproducible. Record the same bug with the extension if you want it re-driven.

Where it runs

In our infrastructure, in a headless browser, on a clean profile — not on the machine of whoever filed the report. It has none of their extensions, cookies, session, locale, network conditions or device. That is exactly why a “not reproduced” verdict is informative: it narrows the bug toward something specific to that environment rather than proving the report wrong. Anything that depends on being signed in as a particular user, or on a physical device, is a poor fit.

Verified origins

The agent will only drive an origin your workspace has verified. This is a hard boundary, not a setting: private and internal addresses are refused outright, and so is any origin you have not proven you control. Without it, a bug report would be a way to make our infrastructure issue requests at a third party.

Run allowances

Runs are metered. Each attempt counts, so a report checked three times uses three runs, and the bisect and counterfactual passes use additional runs on top.

• Free — not available.
• Pro — 20 runs per month.
• Team — 50 runs per seat per month, pooled across the workspace.
• Enterprise — 500 runs per month.

What it is not good at

Being straight about this is cheaper than disappointing you: flows behind a login it cannot complete, anything needing a real payment, email or SMS step, bugs that depend on a specific device or on precise timing, drag-and-drop and canvas interactions, and anything where the page has changed enough since the recording that the original steps no longer exist. Most of these come back as blocked rather than as a wrong answer, which is the failure mode we chose.