Launching today
BugShot
Discover, fix, capture, and report bugs in one shot
78 followers
Discover, fix, capture, and report bugs in one shot
78 followers
Catch a bug and file a complete report from Chrome's side panel. Captures, console/network logs, and environment attach automatically. Or tweak the CSS live and send the before/after side by side. AI drafts it for you. Free, no account, straight to your tracker.
BugShot
Hey Product Hunt 👋
I'm a product designer. My job is to notice when something is four pixels off — and then the hard part starts, because I have to describe it. I'd screenshot the bug, type "the spacing looks off here" into a ticket, and a developer would have to guess which property I meant. The rest of the report was clerical work: reproduce it, copy the URL and the browser version, dig through the console, paste it all into a tracker. By the time you're done you've forgotten what you were actually working on.
So I built BugShot, a Chrome side panel that collapses that into one pass:
• Pick an element and fix it live. Edit its CSS right on the page — through form fields or a real CSS editor with autocomplete and color swatches. Every change is tracked as a before → after table in the report, so the developer gets the diff, not my adjectives. It resolves var() chains too, so the report says --color-primary instead of rgb(79, 70, 229).
• Capture what you need. An element, a region, a screen recording, or the last 30 seconds of the tab. Annotate it before attaching.
• Logs come along for free. Console, network, and user actions are recorded while BugShot is running, including inside cross-origin iframes.
• File it where you already work. Jira, GitHub, Linear, Notion, GitLab, Asana, ClickUp — or share straight to a Slack channel or DM.
No sign-up, no account. Everything runs locally in the extension and posts directly to your tracker — your screenshots, logs and report text never touch a server of mine. The one exception is OAuth: platforms that require a client secret (Jira, GitHub, Notion, Asana, ClickUp, Slack) have their auth code exchanged through a small proxy that relays the token and stores nothing. Linear and GitLab use PKCE and skip it entirely.
I'd love to hear where it breaks for you — especially which tracker or workflow you'd want next. Happy to answer anything in the comments.
honestly this looks super useful for my workflow but it would be great if you could save a default assignee or team channel per project so reports go straight to the right place without me having to select it every single time
BugShot
@peklrql
Thank you, İpek! This is really thoughtful feedback 🙏
Part of this already works today, although we clearly haven't made it obvious enough—that's on us.
BugShot remembers your last-used destination (repo, team, project, channel, assignee, labels, etc.) and pre-fills it the next time you report. You can also set defaults for each connected integration in the Connect tab.
That said, you're absolutely right about the missing piece: those defaults are currently stored per integration, not per project. So if you're working across multiple sites or repos, BugShot can end up defaulting to whatever you used most recently. That's a real usability gap, and I've added it to our roadmap.
One question, if you don't mind: would you rather have defaults tied to the website you're reporting from (e.g. staging.foo.com → repo X), or would a few named presets be more useful? I'd love to build whichever fits real workflows best.
the part that stands out is the privacy claim, not the css diffing. a lot of bug tools that say everything stays local quietly still route auth tokens through their own servers, so I like that you called out the OAuth proxy explicitly instead of hiding it. does that proxy log anything at all for debugging on your end, or is it truly stateless per request
BugShot
@galdayan
Fair question — and honestly, it's the one I'd ask too. "Everything stays local" often has an asterisk hidden somewhere around OAuth.
In our case, the proxy is stateless. It's open source, so you don't have to take my word for it:
https://github.com/SinhyeokKang/bugshot-2/blob/main/oauth-proxy/worker.ts
All it does is exchange the authorization code for an access token and immediately relay the response back. It doesn't persist tokens or request bodies, and nothing is logged for debugging. There's no storage attached to the Worker either (no KV, D1, R2, or database), so there's nowhere for anything to land.
Your screenshots, logs, and report text never go near the proxy in the first place—they're sent directly from the extension to your tracker.
After reading your comment, I also double-checked the Cloudflare side: Workers Logs, Traces, and Log Exports are all disabled for that Worker, and there's no Tail Worker attached. The only thing Cloudflare exposes is aggregate metrics like request count, error rate, and CPU time—no request content, tokens, or user identifiers.
There are a couple of extra guardrails too: the proxy only accepts requests from the registered extension and only for our own client IDs, so it can't be used as a generic token-exchange service. And providers that support PKCE (like Linear and GitLab) don't use the proxy at all.
If you spot anything in the code that contradicts this, please let me know. I'd genuinely appreciate it.
finally something that grabs console logs automatically because honestly copying those into jira tickets every single time is kind of my least favorite part of the job. the live css tweak diff idea is actually clever too
BugShot
@abangciv
Thank you — that's exactly the pain point I built BugShot to solve.
One thing you might like: BugShot captures console and network activity across every frame, including cross-origin iframes like Stripe or chat widgets. Those are often the hardest things to reproduce because the relevant errors aren't always in the frame you're inspecting.
Everything is collected while BugShot is running, so by the time you decide to report a bug, the logs are already there.
To keep the ticket itself readable, BugShot adds a short summary and attaches the full console, network, and action timeline as a single logs.html file that developers can open and filter locally.
One thing I'd love is the ability to mark sensitive fields like emails or tokens for auto-redaction before the report gets sent. Even with a free tool, hitting send without scrubbing that stuff feels a little risky.
BugShot
@hakanzcpn
Funny timing — this is exactly what I worked on today.
BugShot already redacts sensitive data automatically, and the next release makes it even stricter. It detects common sensitive fields (passwords, auth tokens, etc.), masks values that look like email addresses or long numeric identifiers, and completely excludes content from rich-text editors like email composers and document editors.
That said, you're pointing at a real gap: today it's entirely heuristic-based. It catches most sensitive data automatically, but there will always be edge cases like internal IDs, customer references, or app-specific fields that don't look sensitive to a generic detector.
In the meantime, nothing gets sent blindly. Before submitting, you can open the log card to review exactly what was captured, or disable the action log entirely if you're working with sensitive data.
A user-defined redaction system is probably the right long-term solution, and it's already on my roadmap. I'm curious which you'd prefer: clicking a field on the page to always redact it, or defining rules or patterns once in settings that apply everywhere?
The before/after CSS diff plus console/network evidence is the important bit. AI can draft the ticket, but the raw evidence needs to travel with it so the developer is not debugging a summary of a bug instead of the bug itself.
BugShot
@krekeltronics
That's exactly the line I tried not to cross.
The AI draft only writes the prose—the title and description. It's entirely optional, and it never touches the evidence. Skip it, and the report is exactly the same, just without the prose.
Style changes are captured as a before → after table of the actual CSS declarations, not a description of them. If a value came from a design token, you'll see --color-primary, not the rgb(79, 70, 229) it happened to resolve to. Developers get the value they'd otherwise have to go looking for.
The logs travel with the report as a self-contained logs.html: the full console, network activity, and user-action timeline—not a digest. The ticket itself only includes a one-line summary so it stays readable, while the raw data is one click away in the attachment. You can filter by origin, inspect request and response bodies, or export everything as HAR or JSON. Nothing gets summarized along the way.
So the AI drafts around the evidence, never in place of it. If it ever became the only thing in the ticket, the tool would be worse than the screenshot-and-a-sentence workflow it was built to replace.
It would be awesome if Bug Shot could automatically generate clear reproduction steps from the captured session. That would make it even more valuable.
BugShot
@bernard_lewis
I love this suggestion because it's exactly where I think bug reporting should go.
BugShot already records your interactions as a structured timeline, and the AI Draft feature turns that into a title, description, and reproduction steps.
The hard part isn't capturing everything—it's knowing what to leave out. Right now it mainly looks at the last ~20 actions, so it's great at explaining what happened right before the bug, but not yet at distilling a longer session into the few steps someone else can reliably follow.
I'd love for BugShot to get there.