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
[Bug]: Private GitLab uploads do not load in MR descriptions #11412
Sign in to a self-hosted GitLab instance with glab and add a private repository to T3 Code.
Create a merge request and upload a PNG and a short MP4 to its description using GitLab's upload UI.
Open that MR in T3 Code's pull request panel.
GitLab stores these uploads as relative /uploads/<secret>/<filename> references. The same problem affects copied project-ID upload links. The private test repository is on a local network, so it cannot be shared publicly; the steps above reproduce it with another GitLab installation.
Expected behavior
The uploaded image is visible. The video plays and supports seeking using the environment's GitLab login.
Actual behavior
The image is unavailable and the video cannot play. Relative image paths can be mistaken for workspace files, and anonymous browser requests cannot retrieve private uploads.
Impact
Major degradation for MR descriptions that use screenshots or recordings to explain changes.
Version and environment
Reproduced on main at e816064945, web client on macOS, private self-hosted GitLab. GitLab returns uploaded PNG/MP4 files as application/octet-stream. The reproduction's configured login host differs from GitLab's canonical repository URL.
Related work
#23501 implements the fix (replacing #11374, #15270 and #18793). #6600 describes the related GitHub image problem; #10775 is the existing GitHub-specific proposal.
Searched existing GitLab image reports before filing; no matching bug report found.
Reacted by Tobias Marschall, SeongHoon Ryu, Arjun Radhakrishnan and Javier Santos
Could a maintainer triage this? #18793 was closed because this issue hasn't been triaged yet. I missed that the contribution policy from #14480 now requires that for a fix of this size, so sorry for the extra round.
It still reproduces on current main (511d20c6f2) against a private, self-hosted GitLab 19.4. The PR panel shows "Image unavailable" and "Video unavailable" for uploads in the MR description, for two reasons:
GitLab writes uploads as project-relative /uploads/<secret>/<name> links, which the clients treat as workspace paths.
A private project only serves uploads to a signed-in request. Without a session GitLab redirects to /users/sign_in.
Proposed behavior: images and videos uploaded to a private project's MR description or comments render in the PR view on web, desktop and mobile. They load through the environment's glab login for that host and GitLab's upload API, the same way private GitHub attachments load through GitHubCredentials and GitHub's API since #11706 and #16321. Without a login, or on GitLab older than 17.4 (no upload API), they fall back to loading the upload URL directly, as today.
#18793 implements this and includes before/after screenshots. Happy to change the approach if you'd prefer a different direction.
Also reproduces on gitlab.com (SaaS), not just self-hosted. In a private project's MR, every /uploads/<secret>/<file> image in the description shows as unavailable in the PR panel, and an uploaded .mp4 doesn't play. Requesting the upload without a login returns 302 → /users/sign_in for both gitlab.com/<group>/<project>/uploads/… and gitlab.com/-/project/<id>/uploads/…. Fetching it with glab api projects/<id>/uploads/<secret>/<file> returns the file, so the approach in #18793 would fix it. +1 for triage.
PullRequestMarkdown and ChatMarkdown support authenticated GitHub media.
Equivalent handling for GitLab uploads is absent.
MR comments use the same PullRequestMarkdown renderer.
This is consistent with the reported issue. The failing image requests and their HTTP responses have not been captured, so the exact failure path in this installation remains unverified.
Model: gpt-6.1-sol · Reasoning: medium · Harness: Codex Desktop
Triaged as a bug; no duplicate found among the open issues from the last 90 days.
Verification on Linux at 3b95e7831b stopped at reproduction step 1: this environment has no glab executable, stored GitLab login, or GitLab token. The reported private repository is not accessible here, so no browser reproduction or fix has been verified.
Maintainer follow-up needs an environment signed in to a private GitLab test project with PNG/MP4 MR uploads. The existing report supplies the steps and version; no credentials should be posted here. Leaving this issue open.
This blocks our normal code-review workflow on self-hosted GitLab. We use screenshots and videos extensively as review evidence, but screenshots in MR comments show “Image unavailable” in T3 Code while the same attachments load correctly in GitLab. We have to leave T3 Code and open GitLab to actually review that evidence, which makes the MR view much less useful for us.
We cannot share the screenshots or recordings publicly because they contain private project information, but we can help verify a fix against our self-hosted instance.
Is #23501 still the intended implementation, and could this be prioritized? Restoring access to review evidence would let us do these reviews inside T3 Code.
Tested the approach in #23501 against a private project on self-hosted GitLab 16.11.10. It can't fix this on GitLab older than 17.4:
GET /api/v4/projects/:id/uploads/:secret/:file with a valid glab token → 404 (the endpoint was added in 17.4)
GET /<group>/<project>/uploads/:secret/:file → 302 /users/sign_in with no auth, with Authorization: Bearer, and with PRIVATE-TOKEN
So on GitLab older than 17.4, private uploads can't be fetched with a token at all, and the fallback to the plain upload URL only helps public projects. The PR still looks right for 17.4+. It might be worth saying in the docs or the fallback message that private-project media needs GitLab 17.4 or later.
@pedrocostadev Thanks for testing on 16.11, that matches what I see: the upload API only exists since GitLab 17.4, and older versions serve private uploads only to a signed-in browser session, not to a token. The docs in #23501 state the 17.4 requirement.
@danddanddand If your instance runs GitLab 17.4 or later, testing #23501 against it would add another confirmation from a self-hosted setup.
Also reproduces on T3 Code Desktop 0.1.8-nightly.20261105.4218 (macOS 27, arm64) with a private gitlab.com project and glab logged in. /uploads/<secret>/<file>.png images in MR descriptions don't render in the PR panel. Looking forward to #23501.
Posted via T3 Code triage by Claude Code (Opus 5.5).
Activity
Rasalas commentedon Oct 12, 2026
Could a maintainer triage this? #18793 was closed because this issue hasn't been triaged yet. I missed that the contribution policy from #14480 now requires that for a fix of this size, so sorry for the extra round.
It still reproduces on current main (
511d20c6f2) against a private, self-hosted GitLab 19.4. The PR panel shows "Image unavailable" and "Video unavailable" for uploads in the MR description, for two reasons:/uploads/<secret>/<name>links, which the clients treat as workspace paths./users/sign_in.Proposed behavior: images and videos uploaded to a private project's MR description or comments render in the PR view on web, desktop and mobile. They load through the environment's
glablogin for that host and GitLab's upload API, the same way private GitHub attachments load throughGitHubCredentialsand GitHub's API since #11706 and #16321. Without a login, or on GitLab older than 17.4 (no upload API), they fall back to loading the upload URL directly, as today.#18793 implements this and includes before/after screenshots. Happy to change the approach if you'd prefer a different direction.
saibotma commentedon Oct 13, 2026
Also reproduces on gitlab.com (SaaS), not just self-hosted. In a private project's MR, every
/uploads/<secret>/<file>image in the description shows as unavailable in the PR panel, and an uploaded.mp4doesn't play. Requesting the upload without a login returns302 → /users/sign_infor bothgitlab.com/<group>/<project>/uploads/…andgitlab.com/-/project/<id>/uploads/…. Fetching it withglab api projects/<id>/uploads/<secret>/<file>returns the file, so the approach in #18793 would fix it. +1 for triage.ryush00 commentedon Oct 13, 2026
+1
jakubdusek commentedon Oct 19, 2026
Additional user report on desktop v0.1.0: GitLab MR images are missing in both descriptions and comments.
Environment:
User-reported reproduction:
Source inspection at release commit 81493ef:
This is consistent with the reported issue. The failing image requests and their HTTP responses have not been captured, so the exact failure path in this installation remains unverified.
Model: gpt-6.1-sol · Reasoning: medium · Harness: Codex Desktop
juliusmarminge commentedon Oct 22, 2026
Triaged as a bug; no duplicate found among the open issues from the last 90 days.
Verification on Linux at 3b95e7831b stopped at reproduction step 1: this environment has no
glabexecutable, stored GitLab login, or GitLab token. The reported private repository is not accessible here, so no browser reproduction or fix has been verified.Maintainer follow-up needs an environment signed in to a private GitLab test project with PNG/MP4 MR uploads. The existing report supplies the steps and version; no credentials should be posted here. Leaving this issue open.
danddanddand commentedon Nov 1, 2026
This blocks our normal code-review workflow on self-hosted GitLab. We use screenshots and videos extensively as review evidence, but screenshots in MR comments show “Image unavailable” in T3 Code while the same attachments load correctly in GitLab. We have to leave T3 Code and open GitLab to actually review that evidence, which makes the MR view much less useful for us.
We cannot share the screenshots or recordings publicly because they contain private project information, but we can help verify a fix against our self-hosted instance.
Is #23501 still the intended implementation, and could this be prioritized? Restoring access to review evidence would let us do these reviews inside T3 Code.
pedrocostadev commentedon Nov 2, 2026
Tested the approach in #23501 against a private project on self-hosted GitLab 16.11.10. It can't fix this on GitLab older than 17.4:
GET /api/v4/projects/:id/uploads/:secret/:filewith a validglabtoken →404(the endpoint was added in 17.4)GET /<group>/<project>/uploads/:secret/:file→302 /users/sign_inwith no auth, withAuthorization: Bearer, and withPRIVATE-TOKENSo on GitLab older than 17.4, private uploads can't be fetched with a token at all, and the fallback to the plain upload URL only helps public projects. The PR still looks right for 17.4+. It might be worth saying in the docs or the fallback message that private-project media needs GitLab 17.4 or later.
Rasalas commentedon Nov 3, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Rasalas
@pedrocostadev Thanks for testing on 16.11, that matches what I see: the upload API only exists since GitLab 17.4, and older versions serve private uploads only to a signed-in browser session, not to a token. The docs in #23501 state the 17.4 requirement.
@danddanddand If your instance runs GitLab 17.4 or later, testing #23501 against it would add another confirmation from a self-hosted setup.
MoatasemAshmawy commentedon Nov 7, 2026
Also reproduces on T3 Code Desktop 0.1.8-nightly.20261105.4218 (macOS 27, arm64) with a private gitlab.com project and
glablogged in./uploads/<secret>/<file>.pngimages in MR descriptions don't render in the PR panel. Looking forward to #23501.Posted via T3 Code triage by Claude Code (Opus 5.5).