You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pull request viewer does not load images from private repositories #6600
Images embedded in pull request descriptions from private repositories render as broken images in the pull request viewer. GitHub returns private user-attachments URLs as 404 when the desktop renderer fetches them anonymously, even though the signed-in GitHub CLI can access them.
Reproduction
Open a pull request from a private GitHub repository that contains uploaded images.
Open its Summary tab in the pull request viewer.
Scroll to the images in the description.
The image alt text and broken-image icon appear instead of the uploaded images.
Before
The screenshot uses public PR #6594 as seeded content with an unreferenced private test attachment substituted at render time. It contains no private pull request content.
Additional reproduction: this also affects images committed to a private repository and embedded in ordinary pull request comments, not only github.com/user-attachments images in the PR description.
In the Summary view, the Markdown table and image alt text render, but the image itself is broken. The PR/comment data is loaded through authenticated gh, while the renderer treats the HTTPS image as directly loadable and emits an ordinary <img src>; that browser request has no GitHub authentication.
The open fix in #6601 currently recognizes only https://github.com/user-attachments/assets/, so private repository blob/<sha>/<path>?raw=true images still take the anonymous path. This reproduction applies to PR comments and images inside Markdown tables as well as descriptions.
One finding that changes the fix shape for images committed to a private repo (the case in the comment above): the approach in #9404 / #10775 — attach the gh token to the github.com URL and follow its redirect — can't just be widened to cover them, because github.com's repo-file routes 404 even with the token.
Tested with curl against a private repo, a PNG committed to a branch, using the OAuth token from gh auth login (gh auth token):
GET https://api.github.com/repos/O/R/contents/<path>?ref=<ref> → download_url
—
200 JSON; the download_url (signed ?token=) then loads anonymously, 200 image/png
So for repo images:
The URL has to be rewritten to raw.githubusercontent.com/O/R/<ref>/<path> before the token goes on. That is a straight host/path rewrite that keeps the <ref>/<path> split untouched, so branch names containing / resolve exactly as they do on github.com.
The 302-to-a-short-lived-URL design both PRs use still works: the contents API's download_url is a signed URL the renderer can load without credentials. That route takes ref and path separately, though, so it is the one that would have to split them apart itself.
Rendering GitHub's body_html instead of the markdown doesn't help: it leaves these srcs untouched (<img src="https://github.com/O/R/raw/<ref>/<path>">). They only render on github.com because the viewer's session cookie goes along with the request.
Our shape, for reference: <img src="https://github.com/O/R/raw/develop/docs/…/screenshot.png" width="420" /> in a PR description. That's how we embed screenshots we commit to the repo so they stay private.
Activity
sensei-woo commentedon Aug 28, 2026
Additional reproduction: this also affects images committed to a private repository and embedded in ordinary pull request comments, not only
github.com/user-attachmentsimages in the PR description.Example Markdown shape:
In the Summary view, the Markdown table and image alt text render, but the image itself is broken. The PR/comment data is loaded through authenticated
gh, while the renderer treats the HTTPS image as directly loadable and emits an ordinary<img src>; that browser request has no GitHub authentication.The open fix in #6601 currently recognizes only
https://github.com/user-attachments/assets/, so private repositoryblob/<sha>/<path>?raw=trueimages still take the anonymous path. This reproduction applies to PR comments and images inside Markdown tables as well as descriptions.PetrBrabec commentedon Sep 11, 2026
One finding that changes the fix shape for images committed to a private repo (the case in the comment above): the approach in #9404 / #10775 — attach the
ghtoken to thegithub.comURL and follow its redirect — can't just be widened to cover them, because github.com's repo-file routes 404 even with the token.Tested with
curlagainst a private repo, a PNG committed to a branch, using the OAuth token fromgh auth login(gh auth token):Authorization: token <gh token>https://github.com/O/R/raw/<ref>/<path>https://github.com/O/R/blob/<ref>/<path>?raw=truehttps://raw.githubusercontent.com/O/R/<ref>/<path>image/pngGET https://api.github.com/repos/O/R/contents/<path>?ref=<ref>→download_urldownload_url(signed?token=) then loads anonymously, 200image/pngSo for repo images:
raw.githubusercontent.com/O/R/<ref>/<path>before the token goes on. That is a straight host/path rewrite that keeps the<ref>/<path>split untouched, so branch names containing/resolve exactly as they do on github.com.download_urlis a signed URL the renderer can load without credentials. That route takesrefandpathseparately, though, so it is the one that would have to split them apart itself.body_htmlinstead of the markdown doesn't help: it leaves thesesrcs untouched (<img src="https://github.com/O/R/raw/<ref>/<path>">). They only render on github.com because the viewer's session cookie goes along with the request.Our shape, for reference:
<img src="https://github.com/O/R/raw/develop/docs/…/screenshot.png" width="420" />in a PR description. That's how we embed screenshots we commit to the repo so they stay private.juliusmarminge commentedon Sep 16, 2026
Fixed by #11706 — private repository media (images/videos) now loads in pull request tabs on web and desktop.