Skip to content

Fix auto-ready promotion: markPullRequestReadyForReview needs contents: write #1201

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
accuser merged 2 commits into from
Aug 14, 2026
+12 −6
Merged

Fix auto-ready promotion: markPullRequestReadyForReview needs contents: write #1201

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5a6cb11
Fix auto-ready promotion: markPullRequestReadyForReview needs content…
claude Aug 14, 2026
ef13099
Merge branch 'main' into claude/auto-ready-draft-prs-ci-gwexg8
accuser Aug 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions .github/workflows/auto-ready.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,10 +13,11 @@
# - ci.yml's `ci-green` audit step hand-verifies its own gate; a downstream
# promote job there would need an EXEMPT entry and would tangle promotion
# into the required check's job graph.
# - the promotion needs `pull-requests: write`; ci.yml is least-privilege
# `contents: read` at the top and PR jobs there run on untrusted-input
# paths. This workflow checks out nothing and runs no project code, so the
# write scope never coexists with anything a PR author controls.
# - the promotion needs `pull-requests: write` and `contents: write` (see
# the permissions block); ci.yml is least-privilege `contents: read` at
# the top and PR jobs there run on untrusted-input paths. This workflow
# checks out nothing and runs no project code, so the write scopes never
# coexist with anything a PR author controls.
# - run-level `conclusion == 'success'` is exactly "the whole CI run passed"
# (it subsumes `ci-green`; it is marginally stricter — a red report-only
# `coverage` job also holds the draft, which is a safe default).
Expand Down Expand Up @@ -57,9 +58,14 @@ concurrency:
cancel-in-progress: true

# `pull-requests: write` marks the PR ready (a GraphQL mutation, via `gh pr
# ready`); `actions: write` dispatches the review workflow. Nothing is checked
# out, so no contents scope at all.
# ready`) — but the `markPullRequestReadyForReview` mutation also demands
# `contents: write` from integration tokens (cli/cli#6924); without it the
# call fails with "Resource not accessible by integration" even though nothing
# here reads or writes repo contents. `actions: write` dispatches the review
# workflow. Nothing is checked out and no project code runs, so neither write
# scope ever coexists with anything a PR author controls.
permissions:
contents: write
pull-requests: write
actions: write
Comment on lines 67 to 70

@claude claude Bot Aug 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scope the write permissions to the promote job rather than the whole workflow.

Every other workflow in this repo keeps the top-level block at least-privilege and elevates per job — release.yml:62 says so explicitly (contents: read # least-privilege default; the github-release job requests contents: write for itself), and stamp.yml:45-46 stays contents: read at the top and mints an App token only after the arbitrary-code steps. auto-ready.yml is now the only workflow granting write at the file level.

That matters here because contents: write is the highest-blast-radius scope in the file: it lets the token push to unprotected branches and create/move/delete tags, which pull-requests: write and actions: write do not. With a single job today the effective grant is identical, so this is purely about the next job someone appends to this file inheriting repo write silently. Since the file has exactly one job, the move is mechanical:

Suggested change
permissions:
contents: write
pull-requests: write
actions: write
permissions: {}

…with the block relocated under promote: (alongside runs-on/timeout-minutes), and the explanatory comment moving with it.

Related, on the comment above: "the security posture is unchanged" is a bit stronger than what the mitigations buy. The reasoning that holds is the one already in the header — nothing is checked out, no project code or third-party action runs, and the untrusted values (HEAD_BRANCH, HEAD_SHA) travel via env and jq --arg. The capability of the token did widen; it's the absence of anything attacker-controlled in the job that keeps it safe. Worth saying it that way so a future edit that adds a checkout step doesn't read this comment as a blanket clearance.


Expand Down
Loading