Summary
A workflow that lists a GitHub App in on.bots activates for that App's /command comment, then fails in the agent job at Checkout PR branch:
ERR_PERMISSION: Refusing PR checkout: actor '***' has 'none' permission (requires write or higher)
checkout_pr_branch.cjs requires GET /repos/{owner}/{repo}/collaborators/{actor}/permission to return write, maintain or admin. GitHub Apps are not collaborators and always get none. The only exemption is for pull_request opened/synchronize events sent by a Bot on a same-repository PR (the code comment says comments "do not prove the sender can write the PR branch"). GH_AW_ALLOWED_BOTS / on.bots is not consulted, and there is no setting for this.
Reproduction
- Workflow with
on.slash_command, on.bots: ["my-app[bot]"] and a PR checkout in the agent job (any pull-requests: read review workflow).
my-app[bot] posts /command as a comment on a same-repository PR.pre_activation passes ("matched the allowed bots list"), activation passes, agent fails at Checkout PR branch with the error above.
Seen in two independent fleets, on GitHub Enterprise Cloud with data residency and on github.com, for an automation that requests a deep review after remediation.
Expected
on.bots should mean what the docs say for the whole run. Suggested rule in assertTrustedCheckoutRuntime, for issue_comment and pull_request_review_comment events:
- the actor (canonicalized,
<slug> and <slug>[bot] equivalent) is in GH_AW_ALLOWED_BOTS, and
payload.sender.type === "Bot" and the comment author is that actor, and- the PR head repository id equals the base repository id (never a fork).
Every other actor keeps today's collaborator check.
Security notes
The allow-list is an explicit, reviewed choice in the workflow source. A same-repository head branch already requires push access, so trusting an allow-listed bot's comment does not execute code from an untrusted author. Forks stay refused.
Workarounds today
- Post the command with a machine user token that has
write (works, but every caller needs that token).
- Patch the step to answer the permission lookup
write for that one actor; we have this as a small shim but would rather not carry it.
Summary
A workflow that lists a GitHub App in
on.botsactivates for that App's/commandcomment, then fails in the agent job at Checkout PR branch:checkout_pr_branch.cjsrequiresGET /repos/{owner}/{repo}/collaborators/{actor}/permissionto returnwrite,maintainoradmin. GitHub Apps are not collaborators and always getnone. The only exemption is forpull_requestopened/synchronizeevents sent by a Bot on a same-repository PR (the code comment says comments "do not prove the sender can write the PR branch").GH_AW_ALLOWED_BOTS/on.botsis not consulted, and there is no setting for this.Reproduction
on.slash_command,on.bots: ["my-app[bot]"]and a PR checkout in the agent job (anypull-requests: readreview workflow).my-app[bot]posts/commandas a comment on a same-repository PR.pre_activationpasses ("matched the allowed bots list"),activationpasses,agentfails at Checkout PR branch with the error above.Seen in two independent fleets, on GitHub Enterprise Cloud with data residency and on github.com, for an automation that requests a deep review after remediation.
Expected
on.botsshould mean what the docs say for the whole run. Suggested rule inassertTrustedCheckoutRuntime, forissue_commentandpull_request_review_commentevents:<slug>and<slug>[bot]equivalent) is inGH_AW_ALLOWED_BOTS, andpayload.sender.type === "Bot"and the comment author is that actor, andEvery other actor keeps today's collaborator check.
Security notes
The allow-list is an explicit, reviewed choice in the workflow source. A same-repository head branch already requires push access, so trusting an allow-listed bot's comment does not execute code from an untrusted author. Forks stay refused.
Workarounds today
write(works, but every caller needs that token).writefor that one actor; we have this as a small shim but would rather not carry it.