To reproduce a bug report, follow the reporter's steps in the same browser, account state and data until you see the same failure. Then cut the steps down to the shortest path. Sai does this on a real computer. It reads the ticket, signs in with your test account, follows the steps and tells you whether the bug reproduced.
What it means to reproduce a bug report
Reproducing a bug report means triggering the reported failure again, on purpose, by following a known set of steps in a known environment. A reproduced bug has precise steps, an expected result, an actual result and the environment where it happens. Mozilla's bug-writing guide calls steps to reproduce the most important part of any bug report.
Most reports arrive without that. A customer writes "export fails after login" or "checkout does nothing on Edge". Before anyone can fix it, someone has to find the browser, the account state and the click that triggers it.
Why bug reproduction takes so long
- The environment is missing. The bug may only happen in one browser, on one operating system, or with one plan or feature flag on the account.
- The state is hard to rebuild. Many bugs need a signed-in user with a cart, an expired trial or a half-finished onboarding.
- You do not have the machine. A Mac developer cannot check Edge on Windows without a second computer or a device cloud.
- Your own profile hides it. Extensions, cached data and saved settings can make a bug vanish on your machine. Mozilla suggests trying a new browser profile first.
Checklist: how to write a bug report anyone can reproduce
Use this checklist in your issue template, with or without Sai:
- One bug per report. A summary that names the symptom and where it happens.
- Environment. Browser and version, operating system, device, app version and the URL.
- Account state. Plan, role, feature flags and any data needed, such as "annual plan in the cart".
- Numbered steps. Start from a known page and include every click and value typed.
- Expected and actual result. Keep observations separate from guesses about the cause.
- Evidence. Screenshots, error messages and console errors, with times.
- Frequency. Every time, sometimes, or once, and whether it happens in another browser.
- Latest version. Confirm it still happens on the current release.
On GitHub, issue forms can make fields such as steps and browser required, so reports arrive complete.
Ways to reproduce a bug report, compared
| Approach | What you get | Other browsers and OS | Effort per report | Best for |
|---|---|---|---|---|
| Manual repro | Your own observations | Only the machines you have | High, every time | Quick checks you can do in minutes |
| Session replay (LogRocket, Sentry Session Replay) | A reconstruction of the user's real session, with logs and errors | Shows what happened in the user's browser | Low, if the SDK was installed and recording | Seeing exactly what one user did |
| Scripted repro (Playwright) | A test that fails, with a trace of actions, DOM snapshots and logs | The browsers your test setup runs | Writing code and selectors | Turning a confirmed bug into a regression test |
| Device clouds (BrowserStack Live) | A remote real browser you drive by hand | Real browsers and devices, chosen per session | Manual, per session | Device- and browser-specific bugs |
| Sai | Reproduced or not, shortest steps, screenshots, errors on screen | Windows or Linux cloud computer, or your own Mac or PC | Paste the ticket | First triage of vague tickets that need a signed-in user |
If session replay already captured the failing session, watch that first: it shows the user's real state, which no repro can fully rebuild.
How to reproduce a bug report with Sai
- Prepare a test account. Use staging or a test user on production with the same plan and flags as the reporter.
- Paste the ticket. Give Sai the issue text or link, the app URL and the browser to use. The full prompt is in the Start with a prompt tab above.
- Approve the sign-in. Sai asks before signing in, and you approve credentials through a link.
- Watch it follow the steps. Sai clicks and types in the real browser, takes screenshots, and opens developer tools if you ask for console errors.
- Get the result. Reproduced or not, the shortest steps, expected vs actual, and the evidence. Sai asks before it comments on the issue.
- Replay after the fix. Run the same task again to confirm the bug is gone.
Sai ranks #1 on OSWorld, the public benchmark for agents that complete tasks on a real computer. Once Sai completes a task, its steps are kept as code that replays the same way, so checking the fix repeats the exact path.
From your coding agent: add the Sai MCP server to Claude Code, Codex or Cursor. Ask the agent to have Sai reproduce the issue before it writes a fix, then again on the preview deployment. You can watch the screen live and answer approvals there, or call POST /v1/agents/message. Read the quick start.
Keep bug reproduction safe
- Test accounts only. Never ask any tool to sign in as a real customer. Rebuild their state on a test user.
- Test payment details. Use your payment provider's test mode and test cards, never real cards.
- Mind customer data. Copy only what is needed from the ticket. Sentry Session Replay masks text and inputs by default for the same reason.
- Note every deviation. If a step was changed or retried, it belongs in the report.
Related use cases: test your signup flow end to end and test a desktop app from Claude Code.
Last reviewed October 13, 2026.