Coding Agents Made Public Repos to Host 13,000 PR Screenshots. gh Couldn't Attach Images Glow Labs reported on September 29 that AI coding agents created more than 900 public GitHub repositories containing over 13,000 internal screenshots, tied to developers at more than 300 organizations, because the GitHub CLI could not attach images to pull requests. In 93% of cases the images sat in repositories employees created under their own usernames, outside company GitHub organizations and invisible to security teams. GitHub shipped a fix on September 1, 2026, adding a repeatable --attach flag to gh 2.99.0 for pull requests, issues and comments. A developer at a manufacturer with more than 100,000 employees asked a coding agent to check a fix to an internal billing screen and show the result. The agent took the screenshots, created a public repository under the developer's personal GitHub account, and posted the images there for the reviewer. They showed billing records for a utility company. The repository sat outside the company's GitHub organization, so the security team never saw it. It was still public when researchers told the company Glow Labs https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies . That is one case from Glow's report, published on September 29 and covered by The Hacker News https://thehackernews.com/2026/09/ai-coding-agents-exposed-13000-internal.html a day later. Glow counts more than 13,000 internal images in more than 900 public repositories, tied to developers at more than 300 organizations. In 93% of cases the images sat in a repository an employee created under their own username. Nobody attacked anything. The agents were doing what they were asked: put before-and-after screenshots on the pull request. The tool they had couldn't do that, so they found another way. Coding agents work through the shell, and on GitHub that mostly means the GitHub CLI https://cli.github.com/ , gh . For six years gh could put text in a pull request and nothing else. The request is old. cli/cli 1895 https://github.com/cli/cli/issues/1895 , "Upload and Embed Files to PRs / Issues / Comments", was opened on September 22, 2020. A maintainer explained that browser uploads go through an upload policy an API client like gh can't obtain, and closed it that November as not likely to be built soon. The obvious workaround is to commit the PNG to the branch and link it. That works on a public repo. On a private one it doesn't. cli/cli 13256 https://github.com/cli/cli/issues/13256 , opened on April 21, 2026, explains why: linking the file's raw GitHub URL fails for private repos because GitHub's camo image proxy "cannot authenticate to private content", so the image renders broken. So an agent working on a private repo, told to show the reviewer a screenshot, had three facts in front of it: gh pr create and gh pr edit take text only. You can see where that goes. GitHub shipped the fix on September 1, 2026: gh 2.99.0 added a repeatable --attach flag https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments for gh pr create , gh pr edit , gh pr comment and the issue equivalents. It needs write access to the repository. GitHub's docs https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files say that in private and internal repositories, "only people with access to the repository can view the uploaded files." By then, agents had been routing around the gap since at least early July. The private repo can't show the image, so the image goes somewhere that can. Glow reproduced it in a lab. A developer asks Claude Code https://code.claude.com/docs running an Opus 5 model to change the header color in a Minesweeper test project and show the result. The project lives in a private repo, internal sweeper . The agent created a new public repository, sweeper-demo/pr-assets , and put two screenshots there, pinned to a commit SHA. Its reasoning, quoted in the report: "internal sweeper is private, and GitHub cannot render images from a private repo in a PR description." The only way to give the reviewer what they asked for, it concluded, was to "host the PNGs elsewhere." It is right about GitHub, and it is trying to help the reviewer. What it doesn't weigh, by Glow's account, is that a public repo is a security risk. Glow says this reasoning was representative of what it saw at many of the affected organizations, and that the agents involved ran on several AI models, which it hasn't named The Hacker News https://thehackernews.com/2026/09/ai-coding-agents-exposed-13000-internal.html . One lab run on one model reproduces the behavior. It doesn't show that any given vendor's agent did this in the wild. At one software company in Glow's report, agents working for several engineers started publishing code-review screenshots publicly in early July. Within a week, more than a dozen agents had written the approach into a skill applied to every development ticket. A skill here is a file of instructions an agent loads and follows. Those agents then uploaded more than 1,000 screenshots and screen recordings of the product, with written summaries of features weeks or months from release. Glow calls it the most complete leak in the investigation. The second path was a tool. About a third of affected organizations had developers running gitshot, a small open-source tool that publishes screenshots for code review. At several large organizations, agents found it and used it to get around the CLI limit. It can be installed as a skill in more than 40 coding agents. The Hacker News reviewed its code https://thehackernews.com/2026/09/ai-coding-agents-exposed-13000-internal.html on September 30, in a version last changed in April: gh , it puts images in a public repository named gitshot-images under your personal account. The warning was there. At one financial services firm, gitshot images included an internal treasury and settlement console and a withdrawal screen for a named institutional client. Glow found more than 100 public accounts sharing internal work through it. Three caveats on the numbers. Glow hasn't said whether anyone besides its own researchers downloaded the images, and it hasn't published how it found or counted them. Glow also sells software it says stops agents from taking actions like these. The Hacker News notes all three. Checking only your GitHub organization misses most of it, since 93% of cases sat in personal accounts. Glow's advice: start from the people who commit to your private repositories, former employees included, and look at their personal accounts. Check releases and gists, not just files, and check endpoints for packages like gitshot. Given how gitshot works, also search for releases tagged gitshot and for repositories named gitshot-images , the default name The Hacker News found in its code. And don't trust scanners alone; as Glow's report puts it, "They read text, not pixels." Here is a first pass with gh , run by someone with access to the private repo: bash /usr/bin/env bash Usage: ./pixel-check.sh your-org/private-repo set -u repo="$1" logins=$ gh api "repos/$repo/contributors" --paginate \ --jq '. | select .type == "User" | .login' for u in $logins; do echo "== $u" gh repo list "$u" --visibility public --limit 500 \ --json name,createdAt \ --jq '. | "\ .createdAt repo \ .name "' gh api "users/$u/gists" --paginate \ --jq '. | "\ .created at gist \ .html url "' if gh release view gitshot -R "$u/gitshot-images" \ /dev/null 2 &1; then echo "FOUND: $u/gitshot-images has a gitshot release" fi done It lists every public repo and gist for each contributor with a creation date, so a pr-assets repo created the week your team started using agents stands out. The contributors endpoint only knows commits whose email maps to a GitHub account, so treat the output as a starting list. For any suspicious repo, run gh release list -R owner/name too, since release assets don't show in the file tree. If you find something, Glow's order is: remove it everywhere, ask anyone who has a copy to delete it, and rotate any credential visible in an image. Three changes. First, give agents the right tool. Make sure every machine has gh 2.99.0 or later gh --version . --attach isn't supported on GitHub Enterprise Server yet, per the changelog https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments , so on GHES the agent will hit the stop rule below. Then say it in the instructions file your agents load, whether that's AGENTS.md or CLAUDE.md : Screenshots in pull requests - Attach images with gh pr edit