TraceBug - Instant bug reports your AI agent can actually debug

@ramazan793230 Thanks for testing it on a real one CSS bugs are a fun case because the DOM replay carries the actual computed state, so whoever opens the file sees the broken layout itself, not a screenshot of it. "Sharing without granting access to internal tools" is a use case I underestimated hearing it from users repeatedly now.

@kazmmersinqkcj This is the exact loop I built it for file survives offline, agent reads evidence instead of guessing. "Pulled useful stuff from the timeline instead of guessing" is going on a sticky note above my desk. If you hit a session where Claude does end up guessing, send me that file those are the ones that improve the timeline format.

@kriyexqxx Thanks! "Attach it to a ticket or paste it into a prompt" you've described the two halves of the design in one sentence: the same file works for a human reviewer and an AI agent, no translation step. Curious how the Cursor MCP flow holds up on your real bugs that path is newer than the Claude Code one, so honest reports welcome.

@emirhanenetefg Partly there today, honestly not all the way. Known token shapes (JWTs, Bearer headers, API keys) are auto-masked in network snippets, URLs, and storage and the next release shows a summary of what was masked right in the export flow.

The part that's genuinely missing is what you're describing: free-form customer PII in payloads — names, emails, account data. Pattern-matching can't reliably catch those without a cloud model, which I won't do (everything stays on your machine). So the plan is configurable redaction rules: you declare field names / JSON paths / regexes in the SDK config or extension options, and they're masked at capture. That's next on the roadmap would love your input on what the config should look like for your support-channel case.

@emirhanenetefg Follow-up: I built it. Next release adds a redact option to the config:

TraceBug.init({
  projectId: "my-app",
  redact: {
    fields: ["email", "customer_id", "phone"],   // matches form fields, storage keys, URL params, and JSON keys in payloads — "email" also covers "customer_email"
    patterns: ["\\b\\d{3}-\\d{2}-\\d{4}\\b"]     // custom regexes masked anywhere in captured text
  }
});

A matched payload field becomes "customer_email": "[REDACTED]" at capture time it never enters the file at all and everything masked shows up in the export summary so your support channel can see the pipeline ran. Since I asked for your input: does field-name matching cover your case, or do you need JSON-path precision (e.g. only user.email, not every email key)? Genuine question you're the use case.

@enesgryelfkhz Appreciate it. "Not forcing yet another web app" was a genuine design constraint, not a limitation the moment there's a backend, there's an account, an upload, and a retention policy, and the whole trust story collapses. Local MCP means the evidence never travels further than your own agent. Glad that landed.

@baharhoruztgwc You found a real one. Two bugs, actually: console.info wasn't captured at any level, and warn/log events rendered in the repro timeline as raw truncated JSON instead of the message. Both fixed in the next release, warn shows as ⚠ message, info as ℹ message, right in the timeline where the state-transition breadcrumbs belong. Capped at 50 per level so a chatty app can't bloat the file. Thanks for the exact framing ("state transitions") that's what made the fix obvious.

@idemod4m Thank you! The Loom + Slack + "wait, which thread was the console screenshot in?" shuffle is exactly the tax this removes one file, everything in it, works offline. If anything's still missing from the bundle when you share a repro, tell me the roadmap this week is literally being built from these comments.

@englaltmhlbp Agreed on closing that loop with one constraint I can't route around: GitHub issues don't accept .html attachments (drag-drop rejects them), and the Issues API can't attach files at all. What exists today: githubRepo config gives you an "Open in GitHub" button that opens a prefilled issue with the full report as markdown the file just can't ride along automatically.

The plan: a "Download as .zip" export (.zip is an allowed GitHub attachment type) with the prefilled issue body containing a "drag the zip here" placeholder. One drag instead of a broken automation, and no cloud relay the no-backend thing is the whole point. On the roadmap.

@englaltmhlbp Follow-up: this landed faster than "roadmap" implied. Next release adds Download .zip (attach to GitHub) in the export menu same offline replay, wrapped in a .zip (which GitHub does accept via drag-and-drop). And the prefilled issue body now ends with a "Full Repro Replay drag the .zip here" section, so the issue itself tells whoever files it how to attach the evidence. One drag, loop closed, still no backend. Thanks for pushing on this one.

@aysel1129285 Good news, this already exists, and your comment made me realize I never surface it. TraceBug masks token shapes at capture time, before they ever enter the report: JWTs, Bearer headers, OpenAI/Stripe sk- keys, GitHub PATs, AWS, Slack, Google API keys and ~10 more patterns, plus sensitive URL params (?api_key=… → [REDACTED]), password fields, and secret-looking localStorage values.

Your comment also made me audit the pipeline, and I found one real gap: tokens logged via console.log were only scrubbed on paths that never touch the offline file. That's fixed — scrubbing now happens at capture for console output and error stacks too.

And since invisible redaction earns zero trust: the export modal and the report itself now show exactly what was masked — "4 sensitive values auto-masked (2 tokens, 1 URL param, 1 form field)". Landing in the next release. Thank you for this one, genuinely.