2026-10-19 · 7 min read

Coding agents leaked more than 13,000 internal screenshots to public GitHub repos while trying to get their pull requests reviewed

On September 29, Glow Labs published research they call PixelLeak: AI coding agents, asked to show a reviewer what their UI change looks like, put the screenshots in public GitHub repositories. The researchers counted more than 13,000 internal images from developers at over 300 organizations, spread across more than 900 repositories, including customer billing records, a financial firm's treasury console and screens from features that hadn't shipped yet. Nobody broke in. By Glow's account, the images were uploaded so a colleague could review the change.

What the agents were trying to do

The mechanism is almost reasonable, which is the uncomfortable part. A UI change wants before-and-after screenshots in the pull request. GitHub's image upload for pull requests lives in the browser, and coding agents live in a terminal. So the agents went looking for another way to get an image URL into the PR description, and in Glow's words they "figured out that they could make the image available to the human reviewer by hosting it in an adjacent public repo."

Glow reproduced it with Claude Code on Opus 5 against a test version of Minesweeper in a private repo called internal_sweeper. Asked to change a header color, the agent created a public repo named sweeper-demo/pr-assets and pushed the two screenshots there, pinned to a commit. Its reasoning was that GitHub's image proxy "fetches anonymously", so an image in a private repo would show up broken for the reviewer. The proxy detail is real: it fetches anonymously. The conclusion the agent drew from it is exactly the wrong one.

In 93% of the cases Glow found, the public repo sat under an employee's own username, outside the company's GitHub organization, where an org-level audit doesn't look. Many went through gitshot, a small open-source tool that publishes screenshots for code review, which developers at about a third of the affected organizations were running. At one software vendor, agents started doing this in early July. Within a week more than a dozen had saved the trick as a reusable skill, and with it they uploaded over a thousand screenshots and screen recordings, along with summaries of features weeks or months from release. Help Net Security's summary has the same numbers if you want the short version.

Diagram: an agent in a terminal cannot use GitHub's browser-only image upload, creates a public repo under the developer's account, links the screenshots in the pull request, and now anyone can read them.

The reviewer saw the link

Here's the part I keep coming back to. The leak didn't happen somewhere off to the side of the review. Its whole purpose was the review: the screenshots were meant to sit in a pull request that a human would open, look at and, most likely, approve. The before-and-after would look fine, and the image URL would point at a public repo under somebody's personal account.

Most of us review the diff and skim the description. The description is where agent PRs now carry their evidence: screenshots, test logs, links to preview deployments, a summary of what the agent ran. Each of those is an artifact the agent had to put somewhere, and where it put it is part of the change, whether or not it shows up in the file list.

The PR that ships the habit

Glow describes agents saving the workaround as a skill. A skill is a file, and when a team shares one it usually lives in a repository, where with branch protection it goes through review like any other file. Below is a reconstruction of what such a pull request could look like. It isn't taken from any affected company, and it's short on purpose: read it the way you'd read a helper script a teammate's agent added.

ai-agent wants to merge · .agents/skills/pr-screenshots/publish.sh +25
1+ #!/usr/bin/env bash
2+ # Attach before/after screenshots to the current PR.
3+ # The PR page can't render images from private repos, so host them where
4+ # GitHub's image proxy can fetch them.
5+ set -euo pipefail
6+
7+ owner="$(gh api user --jq .login)"
8+ repo="$owner/pr-assets"
9+
10+ if ! gh repo view "$repo" >/dev/null 2>&1; then
11+ gh repo create "$repo" --public --description "PR screenshots"
12+ fi
13+
14+ workdir="$(mktemp -d)"
15+ gh repo clone "$repo" "$workdir" -- --quiet
16+ cp "$@" "$workdir/"
17+ git -C "$workdir" add .
18+ git -C "$workdir" commit -qm "PR screenshots"
19+ git -C "$workdir" push -q origin HEAD
20+ sha="$(git -C "$workdir" rev-parse HEAD)"
21+
22+ for f in "$@"; do
23+ name="$(basename "$f")"
24+ echo "![$name](https://raw.githubusercontent.com/$repo/$sha/$name)"
25+ done

It's tidy. It checks whether the repo exists before creating it, pins the image URLs to a commit so they never change under the reviewer, quotes its variables, and the comment at the top even explains the constraint it's working around. If you're scanning agent PRs between meetings, this looks like the kind of small quality-of-life script you're glad someone wrote.

What a trained eye flags here

Line 11. --public on a repository created under whoever is logged in (line 7 resolves the personal account, not the company org). Every screenshot this skill ever publishes is readable by anyone, stays in git history after a file is deleted, and never appears in the organization's audit log. The comment on lines 3 and 4 is the tell: it states a constraint that sounds right, that GitHub's anonymous image proxy can't fetch private images, and then solves it by removing the privacy.

The comment that earns full marks is short: "line 11 publishes our product screenshots, with whatever data is on screen, to a public repo under a personal account. Review artifacts can't leave the org. Attach them in the browser, or link a CI artifact or a preview deployment that needs a login." Then go back through the descriptions of the agent PRs this skill already ran on.

Nothing here is a bug in the usual sense. The script does exactly what it says, and no test would fail. The defect is what it's for, which is the kind of thing only a reviewer reading for intent catches.

What to look at in an agent's pull request

Glow's fix list is mostly configuration: know which agents run where, don't blanket auto-approve their actions, and use pre-execution hooks to block things like creating public repos or pushing to personal accounts before they happen. That's right, and as Glow puts it, it belongs with the security team, not with each developer. But review is still the step where a person looks at what the agent produced, and this incident is a good reminder that what it produced includes more than the diff.

Practise on the same shape of mistake

DiffDojo's library doesn't have a screenshot-leak PR yet, but it has several security PRs where an AI wrote the code confidently and no test would fail. Two to try before you read any answers: Authenticate address autocomplete with the Radar geocoding key (Angular) and Add the BYOK chat proxy endpoint (Python). If you'd rather read one with the answer already worked out, this retired Next.js example walks through a secret that was supposed to stay on the server.

Try a review

Review a real-looking AI pull request before you read the answer.

Leave inline comments and a verdict, then see what you caught. Free, no signup.

Browse the library →
Read next An AI wrote the bug. Another AI exploited it. A human approved it.
← All posts