I stopped copy-pasting console errors into Claude, so I built a bug report an AI agent can actually read

prashant singh mangat — Tue, 21 Jul 2026 08:56:24 +0000

Every bug I've ever received as a report looked like this: "checkout is broken" plus a cropped screenshot. And every bug I've ever debugged with AI looked like this: me, manually copy-pasting console output into Claude, then the network tab, then describing what I clicked, then apologizing for the formatting.

Both halves of that loop lose the same thing: the evidence. The stack trace, the failed request, the exact click that triggered it — all of it exists at capture time. It just never survives the trip to the person (or agent) fixing the bug.

So I built TraceBug: a capture tool that saves the entire browser session into one offline .html file, and a local MCP server that gives Claude Code, Cursor, or Windsurf read-tools over that file.

Here's a real, unedited transcript of Claude going from crash to root cause in five tool calls: tracebug.dev/proof. I'd rather show you than tell you.

What's in the file

A free Chrome extension (or npm SDK — works in any app) records what actually happened:

DOM replay (rrweb-based) — the recipient sees the broken layout itself, not a screenshot of it
Console — errors with stack traces
Network — every request with method, status, timing, and response snippets for failures
Repro timeline — a millisecond-resolution log of what the user did: clicks, inputs, route changes, interleaved with the errors they caused
Screenshots + environment — browser, OS, viewport, storage snapshot

Two clicks exports all of it as a single self-contained .html. It opens offline in any browser. No account, no upload, no server — there is literally no backend.

The MCP part

The file is nice for humans. The interesting part is making it machine-readable:

claude mcp add tracebug -- npx -y tracebug mcp --dir ./bug-reports

That starts a local, stdio-only MCP server — it opens zero network connections. It exposes tools like:

list_bug_reports — discover reports in the directory
get_bug_report — summary + an investigation guide telling the agent what to call next
get_console_errors, get_network_activity, get_repro_steps, get_screenshot

So instead of narrating your bug to Claude, you say "investigate the report in ./bug-reports" and it reads the evidence directly — in the order a human debugger would: symptom, then errors, then the network call that caused them, then the user action that triggered the call.

Design decisions that mattered

Single file over a dashboard. A .html file survives everything: Slack, email, a ticket attachment, a USB stick, three years in a folder. Nothing to host, nothing to expire, nothing to grant access to.

Local-first is the feature, not a compromise. Cloud bug-reporting tools structurally can't offer "your session data never leaves your machine." An MIT-licensed tool with no backend can. This also makes the security review trivial: the MCP server is stdio-only, and you can read the source.

Compression does the heavy lifting. The rrweb event stream is ~89% of a typical export and gzips 8–12×, so the file compresses via CompressionStream at export time and inflates in the viewer with DecompressionStream. Typical exports are KB-to-low-MB, not the tens of MB a video would be.

Redaction at capture, not at export. Token shapes — JWTs, Bearer headers, sk- keys, GitHub PATs, AWS/Slack/Google API keys, ~20 patterns — are masked before they enter the report object. Sensitive URL params become ?api_key=[REDACTED], password fields never record their values. If a secret never enters the data, no export path can leak it.

Honest limitations

The extension is Chrome-only today (the npm SDK works in any app)
Replay is rrweb-based, so canvas/WebGL-heavy apps lose visual fidelity
TraceBug ships evidence, not an LLM — the investigation uses your own agent and your own API costs

What launch feedback is turning into

I launched on Product Hunt last week and the roadmap is being built directly from the comments. Landing in the next release: a visible redaction summary in the export flow ("🛡 4 sensitive values auto-masked"), a redact config option for app-specific PII fields, console.warn/console.info in the repro timeline, and a .zip export because GitHub issues accept .zip attachments but reject .html (learned that one the hard way).

Try it in 30 seconds

tracebug.dev/try.html has intentional bugs waiting to be captured — no install needed to see the output format.

Everything is MIT-licensed and free. If you try the MCP flow with your own agent, I want to hear the failure cases: what else would the report need for your agent to fix the bug, not just diagnose it? Source maps? Git blame context? A generated failing test? That question is the next six months of this project.