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
Tier: Bottom · Effort: depends on upstream — ~30 min to switch when an option lands · Type: dev-tooling debt
Summary
PR #48 shipped a Playwright-based helper (`scripts/setup-attach-session.mjs` + `scripts/upload-evidence.mjs`) that uploads PR evidence to GitHub's `user-attachments/assets/...` CDN — the only place where videos auto-play inline and images embed natively. The reason it has to drive a real browser is that the user-attachments upload endpoint is cookie-only as of May 2026 — PATs, fine-grained tokens, `gh auth token`, and `gh-attach login` are all rejected with HTTP 422.
It works, but the ergonomics are poor:
Every contributor has to run `bun run setup:attach` once on their machine, log into github.com via a popped-up Chromium window. Google's "Continue with Google" path is detected as automation and blocked, so they have to use GitHub username/password directly.
The session inside Chromium's persistent profile expires every few weeks → re-run setup. Annoying for active contributors.
Anti-bot detection is a moving target. `--disable-blink-features=AutomationControlled` + `navigator.webdriver` override works today; could break on a Chromium update or a GitHub anti-fraud rule change with no warning.
The Chromium profile sits at `~/.local/state/aiatelie/chromium-profile/` (mode 0700, in $HOME, gitignored as defense-in-depth). Not exposed today, but every additional disk artifact is a thing future contributors could screw up.
This is fragile work that exists only because GitHub doesn't ship a CLI for inline video uploads. Whenever an upstream alternative becomes viable, we should switch and delete most of these scripts.
This issue tracks the alternatives so we know when to swap.
What we have today
`scripts/setup-attach-session.mjs` — popped Chromium with anti-bot flags, persistent profile, manual login, no plaintext cookie file written.
`scripts/upload-evidence.mjs` — headless drag-drop into a PR comment textarea, claims assets via comment submission, prints `{file, url}` JSON.
Documented in `CONTRIBUTING.md#dev-time-skills` and `scripts/setup-attach-session.mjs` header comment.
The `cuj-guardian` skill, the `verify-with-playwright` skill, and the `ship-task` orchestrator all reference `bun run upload:evidence`.
What we're watching for
In rough order of preference (best → least preferred):
First-party CLI support in `gh` — cli/cli#1895 (closed not planned, May 2025), cli/cli#12960 (closed dup), cli/cli#13256 (open, blocked on platform). If `gh pr create --attach` ever lands, this entire helper becomes a one-liner. Trigger to switch: anything in cli/cli's release notes that mentions "attach" or "asset."
A documented REST API for user-attachments uploads — would let us call `/upload/policies/assets` with a fine-grained PAT instead of a session cookie. Watch the GitHub API changelog (`api.github.com/changelog`) for new attachment endpoints. Trigger: any post-2026-03-10 changelog entry mentioning `/upload/` or `user-attachments`.
`Addono/gh-attach` adds a working browser-session mode that genuinely uses a real `_gh_sess` cookie (not the gh CLI token wrapper that v1.7.2 saved in our experiments). Trigger: a gh-attach release > v1.7.2 with changelog explicitly mentioning real Playwright/browser auth (not API fallback). Test by running `gh attach upload <small.png> --target # --strategy browser-session` after `gh attach login` — if it returns a `user-attachments/assets/...` URL (not a `releases/download/...` one), it works.
An MCP server that handles GitHub attachment uploads with a documented auth model. The official `github/github-mcp-server` had this open as #738 last we checked; if they implement it, we can swap.
Pivot to YouTube unlisted via the existing `youtube-uploader` skill. Lower-friction long-term but loses true autoplay (renders as a thumbnail). Worth doing if we get one more refresh-the-Chromium-session paper-cut.
Acceptance criteria for closing
This issue can close when at least one of:
`scripts/setup-attach-session.mjs` and `scripts/upload-evidence.mjs` are deleted in favor of a one-liner that doesn't need a persistent browser profile.
We've measured that the Playwright-based path has been stable for 6+ months with no contributor complaints. Re-evaluate then; if still working we leave it.
Why this is a Bottom-tier issue
The pain is real but local — solo maintainer + one or two contributors hit it. The current setup works, the security model is documented, the audit was clean. Don't burn cycles on this until either an upstream alternative lands OR contributor friction starts blocking PRs.
Tier: Bottom · Effort: depends on upstream — ~30 min to switch when an option lands · Type: dev-tooling debt
Summary
PR #48 shipped a Playwright-based helper (`scripts/setup-attach-session.mjs` + `scripts/upload-evidence.mjs`) that uploads PR evidence to GitHub's `user-attachments/assets/...` CDN — the only place where videos auto-play inline and images embed natively. The reason it has to drive a real browser is that the user-attachments upload endpoint is cookie-only as of May 2026 — PATs, fine-grained tokens, `gh auth token`, and `gh-attach login` are all rejected with HTTP 422.
It works, but the ergonomics are poor:
This issue tracks the alternatives so we know when to swap.
What we have today
What we're watching for
In rough order of preference (best → least preferred):
First-party CLI support in `gh` — cli/cli#1895 (closed not planned, May 2025), cli/cli#12960 (closed dup), cli/cli#13256 (open, blocked on platform). If `gh pr create --attach` ever lands, this entire helper becomes a one-liner. Trigger to switch: anything in cli/cli's release notes that mentions "attach" or "asset."
A documented REST API for user-attachments uploads — would let us call `/upload/policies/assets` with a fine-grained PAT instead of a session cookie. Watch the GitHub API changelog (`api.github.com/changelog`) for new attachment endpoints. Trigger: any post-2026-03-10 changelog entry mentioning `/upload/` or `user-attachments`.
`Addono/gh-attach` adds a working browser-session mode that genuinely uses a real `_gh_sess` cookie (not the gh CLI token wrapper that v1.7.2 saved in our experiments). Trigger: a gh-attach release > v1.7.2 with changelog explicitly mentioning real Playwright/browser auth (not API fallback). Test by running `gh attach upload <small.png> --target # --strategy browser-session` after `gh attach login` — if it returns a `user-attachments/assets/...` URL (not a `releases/download/...` one), it works.
An MCP server that handles GitHub attachment uploads with a documented auth model. The official `github/github-mcp-server` had this open as #738 last we checked; if they implement it, we can swap.
Pivot to YouTube unlisted via the existing `youtube-uploader` skill. Lower-friction long-term but loses true autoplay (renders as a thumbnail). Worth doing if we get one more refresh-the-Chromium-session paper-cut.
Acceptance criteria for closing
This issue can close when at least one of:
Why this is a Bottom-tier issue
The pain is real but local — solo maintainer + one or two contributors hit it. The current setup works, the security model is documented, the audit was clean. Don't burn cycles on this until either an upstream alternative lands OR contributor friction starts blocking PRs.
Cross-references