Secure screenshot sharing for Jira, GitHub and Linear issues

When you drag a screenshot into a GitHub issue, a Jira ticket or a Linear card, it feels like a private note to whoever is working on the bug. It is not. The audience is much wider than the person you are replying to, and it stays that way.

• On a public GitHub repo, the issue page is world-readable. The attached image has its own URL, the page gets crawled, and the contents can surface in search results. Anyone, not just contributors, can open it.
• On a private Jira or Linear project, the screenshot is visible to everyone with project access, which is usually more people than you picture, plus contractors and anyone added later.
• Integrations and bots read the same issues you do. A tracker synced to Slack, to another project tool, or to a notification service quietly fans your attachment out to systems you never see.
• Email notifications push the image, or a link to it, straight into inboxes the moment you post, where it sits indefinitely.

So the question is never just "do I trust the person reading this ticket". It is "am I happy with this image on a page that is crawled, mirrored to other tools, and emailed out the second I hit comment". For a public repo, the honest answer is that you are publishing it, with everything that posting a screenshot publicly implies.

The instinct after a bad paste is to fix it later: edit the comment, delete the file, move on. The problem is that "later" does not undo the exposure. By the time you notice, the notification email has already gone out with the original, an integration may have copied it, and on a public repo a crawler may already have indexed the page. You can remove the attachment, but you cannot prove nobody saw it.

In practice, almost nobody goes back and audits old issue attachments. Tickets get closed, they scroll out of view, and the screenshots sit there with whatever was in frame. That is exactly why the safe point is before the upload, not after. If you scrub the token or the stray data into the image first, there is nothing to clean up and nothing to regret. This is the same logic behind doing it before you paste into Slack, where an edited message still leaves the original in everyone's notifications.

The specific danger for developers and PMs is that the most useful screenshot to attach is often the most loaded one. A raw stack trace or an admin panel is exactly what the engineer wants to see, and exactly where the sensitive stuff hides. The error is the point; everything around it came along for free.

• Tokens and keys printed in a failing request, in headers, or in an environment dump at the top of the trace.
• Internal hostnames and file paths that quietly map out your infrastructure and directory layout to anyone reading the ticket.
• Another user's data that happened to be in the request that broke, so a bug report ends up exposing a real person who has nothing to do with it.
• Connection strings and environment variables caught in the same console output you grabbed for the error message.

An admin or back-office view is the same trap from the other side: you open it to show one broken button and capture a customer's name, email and account ID in the surrounding rows. None of that belongs in the ticket. The fix is to scrub it before the image leaves your Mac. There is a fuller checklist of what to look for, aimed at this exact reader, in the guide to screenshot redaction for developers.

The whole thing only works if redacting is faster than skipping it. With ScrubShot the loop fits in the gap between hitting the bug and filing the ticket:

• Press the shortcut. ScrubShot captures the screen with the trace or the admin view on it.
• Drag the Scrub tool over any token, hostname, connection string or stray data. It is pixelated straight into the image as you go.
• Scan the edges and the scrollback for anything you missed, and scrub that too.
• Use the Marker to circle the actual error and Text to label it, so the person picking up the issue looks where you want.
• Copy it or let it save to your Pictures folder, then drop it into the GitHub, Jira or Linear issue.

The Scrub tool rewrites the underlying pixels, so a scrubbed area cannot be lifted off or recovered from the attachment later, and there is Undo if you over-scrub. None of it touches the network, which matters here for the same reason it matters everywhere: a tool that uploads your screenshot to redact it would send the unredacted original to a server before you ever cleaned it. The reasoning behind keeping the whole thing on-device is laid out in the guide to redacting screenshots without uploading them.

I make ScrubShot, a one-person Mac app, and I file plenty of issues myself, so I write this from the chair of someone who has pasted a stack trace and then squinted at it half a second too late. I am not going to pretend every screenshot needs scrubbing; most are harmless. The point is that the loaded ones, the traces and the admin views, are the ones you most want to attach and the ones most likely to carry a token or someone else's data, and a public repo turns that into a published page. Scrub before you attach and the decision stops being something you have to get right under pressure.

ScrubShot is a Mac app for exactly this: press the shortcut, drag over the token or the stray data to pixelate it into the image, then copy or save and attach the cleaned shot to your issue. It is the only version that ever leaves your Mac. There is a free 7-day trial with no card required. After that it is $30 once.

Try ScrubShot free →