---
title: "GitHub user-attachments has no API — the scriptable alternative"
canonical_url: "https://krowk.com/alternatives/github-user-attachments"
last_updated: "2026-09-02T08:09:10.995Z"
meta:
  description: "GitHub's attachment flow is browser-only, so CI and agents cannot use it. What the manual workaround costs, the size limits, and the one-command replacement."
  "og:description": "GitHub's attachment flow is browser-only, so CI and agents cannot use it. What the manual workaround costs, the size limits, and the one-command replacement."
  "og:title": "GitHub user-attachments has no API — the scriptable alternative"
---

# **The scriptable alternative to GitHub user-attachments**

GitHub's attachment flow is browser-only, so a headless run cannot use it. What the drag-and-drop workaround costs, and the command that replaces it.

[Read the CLI reference](https://krowk.com/docs)

## **Why people leave GitHub user-attachments**

- Browser-only: no command, no endpoint, no token.
- 10 MB for images, 25 MB for other files, 10 MB for video on a free plan.
- A person has to be at a keyboard for every upload.
- The image carries no commit, branch or agent — the reviewer has to ask.

## **What Krowk does better**

- One command, so a container or a CI job can do it.
- 100 MB an artifact free, 2 GB on Pro.
- Repo, commit, branch, dirty flag and agent read from the environment.
- The link is a preview page that shows that record beside the image.

Dragging an image into a GitHub comment works well, right up until the thing doing the uploading has no hands. Then it stops being a flow at all: there is no command, no endpoint and no token — the browser posts the file against your logged-in session, and that is the entire interface.

## The workaround, and where it stops

The trick people reach for is doing the drag-and-drop once, by hand, then copying the resulting URL. It works. It is also the part that does not scale: somebody has to be at a keyboard for every screenshot, which is the opposite of the case where the screenshot matters — a run that finished while you were doing something else.

The limits are worth knowing even when a human is doing it: 10 MB for images and GIFs, 25 MB for other files, and video at 10 MB on a free plan or 100 MB on a paid one. A screen recording of an interaction runs into that quickly.

## What you get in exchange for the manual step

Permanence, and no third party. The file lives as long as the thread does, costs nothing, and sits on a domain your organisation already trusts. That is the strongest argument for doing it by hand, and the reason to keep doing it for the screenshots that belong in a decision record rather than a review thread.

## What it cannot tell you

An attached image is an image. It does not say which commit produced it, which branch, whether the tree was dirty, or which agent was driving. In a review where a person took the screenshot, none of that needs saying. In a review where a model took it, all of it does — and the reviewer is left asking, or trusting.

## The scriptable path

Krowk exists for that second case. `krowk push screenshot.png` returns a permalink and prints the block GitHub renders — the image inline, a caption, and a link through to a preview page that carries the repository, commit, branch and agent it read from the environment. No browser, no session, and the first push needs no account.

agent shell

```
gh pr comment 412 --body "$(krowk push shot.png --destination github)"
```

It is not a replacement for drag-and-drop. Use the paperclip when you are already in the browser; use a command when the thing with the file is a process.

## **Krowk vs GitHub user-attachments, feature by feature **

| **Feature** | **Krowk** | GitHub user-attachments |
| --- | --- | --- |
| Upload from a script or a container | Yes | No — browser only |
| Artifact ceiling | 100 MB free, 2 GB on Pro | 10 MB images, 25 MB other files |
| Video ceiling | Same as any artifact | 10 MB free plan, 100 MB paid |
| Link lifetime | 24 hours free, permanent once claimed | As long as the comment lives |
| Commit and branch on the image | Yes | No |
| Renders inline in a PR comment | Yes | Yes |
| Cost | $0 free, $12/mo Pro | Included with GitHub |

**FAQ**

## **What people ask about the upload gap**

<details>

<summary>

Is there an API for GitHub user-attachments?

</summary>

No. The attachment flow is a browser action against your logged-in session, and nothing in the REST or GraphQL API replaces it. There is no scope to request, and the host the browser posts to is not a supported interface, so there is nothing worth reverse-engineering either.

</details>

<details>

<summary>

Can I upload to GitHub attachments with a personal access token?

</summary>

No. A token authenticates the API, and the API has no upload route for comment attachments. There is no scope that grants it.

</details>

<details>

<summary>

Do GitHub attachments expire?

</summary>

No — that is their best property, and the reason to keep using them when a human is already in the browser. Krowk trades it away on the free tier: 24 hours, unless the upload is claimed into a workspace.

</details>

Ready to switch from GitHub user-attachments?

[Read the CLI reference](https://krowk.com/docs)