GitHub connector cannot download private user-attachments that authenticated `gh api` can retrieve

Summary

The OpenAI GitHub connector can read a private repository, its issues/comments, and the stable GitHub attachment URL produced by the new GitHub CLI --attach feature, but it cannot retrieve the actual private image bytes for visual inspection.

This blocks an otherwise clean agent workflow for visual QA:

coding agent screenshot -> gh pr/issue comment --attach -> GitHub attachment -> ChatGPT GitHub connector -> visual review

GitHub CLI added repeatable media attachment support (--attach) in September 2026, including for coding-agent workflows.

Environment / prerequisites

Tested 2026-09-08.

Local GitHub CLI:

gh version 2.100.0 (2026-09-03)

• gh auth status: passes
• authenticated account has ADMIN permission on the private test repository
• OpenAI GitHub connector can read the same private repository and issue/comment successfully

Reproduction

1. In a private GitHub repository, upload a PNG to an issue comment using the new CLI attachment support, e.g.:

gh issue comment <issue> --repo <owner/private-repo> `
  --body "## Visual QA attachment test" `
  --attach "<screenshot.png>#Visual QA screenshot"

2. Confirm that the issue comment Markdown contains the stable attachment form:

https://github.com/user-attachments/assets/<asset-id>

3. From ChatGPT using the OpenAI GitHub connector, read the private issue/comments. This succeeds: the connector can see both the comment and attachment metadata/URL.

4. GitHub's rendered comment HTML also exposes a temporary signed URL of the form:

https://private-user-images.githubusercontent.com/...png?...jwt=...

5. Attempt to retrieve that image through the connector's private-user-image download path. In our test this returns:

404 Not Found

As a result, ChatGPT cannot inspect the screenshot pixels even though it can read the private issue/comment containing the image.

Control test: stable attachment works with authenticated GitHub access

The stable attachment URL is valid and downloadable when authentication is applied through GitHub CLI:

gh api https://github.com/user-attachments/assets/<asset-id>

This successfully downloaded the exact PNG to a temporary file.

Verified test file size:

4,376,454 bytes

The final resolved content is an authenticated GitHub/S3-served image/png.

For comparison, a direct unauthenticated request to the same stable URL returns 404 Not Found, as expected for an attachment originating from a private repository.

This appears to isolate the failure to the connector's authenticated attachment-retrieval path rather than GitHub CLI upload, GitHub storage, repository permissions, or the attachment itself.

Expected behavior

Once the connector has authenticated access to the private repository and can read the issue/PR comment, it should be able to retrieve an attachment referenced by the stable URL:

https://github.com/user-attachments/assets/<asset-id>

Ideally the GitHub connector would expose an authenticated binary-download operation for stable github.com/user-attachments/assets/... resources (or transparently resolve them to downloadable image bytes), analogous to what authenticated gh api already accomplishes.

The model could then visually inspect screenshots attached to private PR comments without requiring the user to download and re-upload them into ChatGPT.

Actual behavior

• private repository access: PASS
• private issue/comment read: PASS
• gh ... --attach upload: PASS
• stable user-attachments URL produced: PASS
• authenticated gh api <stable-url> download: PASS
• connector retrieval of actual screenshot bytes: FAIL (404 on temporary private-user-images route)
• model visual inspection: blocked

Why this matters

This is particularly useful for independent UI review by coding agents. A coding agent can now capture desktop/mobile/edge-case screenshots and attach them directly to a PR with gh pr comment --attach. The reviewer/model should be able to consume that GitHub-hosted evidence directly.

Without authenticated attachment retrieval, private-repository users still need a manual screenshot transfer even though both the generating agent and reviewing ChatGPT session already have authorized GitHub access.

Suggested fix

Add support to the GitHub connector for authenticated retrieval of stable:

https://github.com/user-attachments/assets/<asset-id>

URLs, rather than depending only on temporary private-user-images.githubusercontent.com/...?...jwt=... URLs.

The successful control test with gh api <stable-url> suggests the stable attachment URL plus authenticated GitHub access is sufficient.

Security / privacy

The reproduction intentionally does not include the private repository name, issue URL, attachment asset ID, temporary signed JWT URL, tokens, or other private content.

The requested behavior should preserve GitHub authorization semantics: attachments from private repositories should remain retrievable only when the connected GitHub identity/app is authorized to access the underlying repository.

Start by reproducing the private attachment flow described in the issue: read the comment, follow the stable user-attachments URL, and compare connector retrieval with authenticated gh api. Verify that authorized users receive the PNG bytes rather than a 404, while unauthorized access remains denied; the issue does not name repository files or tests to start from.