#14309·cli

`--attach` cannot work for GitHub App installation tokens — the upload endpoint 404s them even with write access

Author: NinodevoCreated Sep 1, 2026Updated Sep 17, 2026
Labelsblockedenhancementplatformattachments

Describe the feature or problem you'd like to solve

The --attach stack (#14186) allowlists OAuth, classic PAT, and fine-grained PAT credentials, so a GitHub App installation token (ghs_) is rejected client-side with "unsupported authentication type".

We tested whether that allowlist is conservative or reflects the endpoint's actual behavior, since our automation runs on an installation token. Calling the endpoint directly from a GitHub Actions run (GITHUB_TOKEN, permissions: contents: write, private repo the token can push to):

POST https://uploads.github.com/user-attachments/assets?name=test.png&content_type=image/png&repository_id=<numeric id>
→ 404 {"message":"Not Found"}

The identical request with an OAuth token (gho_, same repo, WRITE permission) succeeds and returns an asset URL that renders in issues/PRs. So the exclusion is a property of the platform endpoint, not a CLI decision.

Why it matters

Bots and CI are heavy producers of images on issues and PRs: verification screenshots, visual diffs, test artifacts. GitHub App tokens are the recommended identity for exactly that automation, yet they are the one credential class that cannot use the native attachment path. Our workaround today is committing images to a dedicated assets branch and embedding raw/ URLs — the kind of hack --attach was built to retire.

Proposed solution

  1. If the token-type restriction is intentional platform behavior, say so here and route the ask upstream (github/roadmap#1324 makes no mention of credential-type requirements).
  2. If the endpoint can be extended to installation tokens with write access, please allow them and widen uploadTokenTypes accordingly.
  3. Either way, document the credential requirement in the --attach help, alongside the permission requirement requested in #14302.