Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#using-data-from-the-triggering-workflow
The Use the data example in the workflow_run section.
What part(s) of the article would you like to see updated?
The example has no permissions: block, and both of its steps need a permission that the restricted default does not grant.
The workflow downloads an artifact from a different workflow run, passing run-id and secrets.GITHUB_TOKEN, and then calls github.rest.issues.createComment. Your own reference pages say what those two calls require. Downloading an artifact is documented as needing Actions: read, and creating an issue comment is documented as accepting Issues: write or Pull requests: write. The restricted repository default grants read access to contents and packages only, and the workflow permissions reference says the effective token starts from that default and changes only through a permissions: key.
So a reader who copies this example into a repository on the restricted default gets a workflow that cannot download the artifact and cannot post the comment. On a permissive default the same example works, which is why the gap is easy to miss.
Adding the block to the example would fix it:
permissions:
actions: read
issues: write
pull-requests: write is the documented alternative to issues: write here, not a third permission.
This matters more than a typo because the surrounding section is about handling a potentially untrusted triggering workflow, and the example already carries a security comment about not extracting into the workspace directory. An example in that context is the one readers are most likely to copy verbatim, and least likely to widen by hand.
Additional information
I read the source on main today, 17 August 2026, at content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md. The example there has no permissions: key.
I checked six permission combinations against the two documented requirements. The current example fails on a restricted default and passes on a permissive one. The example with actions: read and issues: write passes on a restricted default. Either permission alone fails. The pull-requests: write variant passes. This is a reading of your documented requirements and not a live Actions run, so I am not reporting an observed error message.
I searched open and closed issues first. There are reports about GITHUB_TOKEN permissions in general, but none about this example.
The pages I read for the requirements:
The GitHub Security Lab article on preventing pwn requests uses the same two-workflow pattern and declares actions: read and pull-requests: write explicitly, which is the shape I am suggesting here.
Three things would make this report wrong, and I would rather name them than have you find them. If a workflow_run job is guaranteed Actions: read and Issues: write regardless of a restricted effective default, there is nothing to fix. If the cross-run download path in this exact example does not need Actions: read when given GITHUB_TOKEN, drop that line from the suggestion. And if the restricted default grants more than contents and packages in the relevant product context, the portability argument goes away.
Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#using-data-from-the-triggering-workflow
The
Use the dataexample in theworkflow_runsection.What part(s) of the article would you like to see updated?
The example has no
permissions:block, and both of its steps need a permission that the restricted default does not grant.The workflow downloads an artifact from a different workflow run, passing
run-idandsecrets.GITHUB_TOKEN, and then callsgithub.rest.issues.createComment. Your own reference pages say what those two calls require. Downloading an artifact is documented as needingActions: read, and creating an issue comment is documented as acceptingIssues: writeorPull requests: write. The restricted repository default grants read access tocontentsandpackagesonly, and the workflow permissions reference says the effective token starts from that default and changes only through apermissions:key.So a reader who copies this example into a repository on the restricted default gets a workflow that cannot download the artifact and cannot post the comment. On a permissive default the same example works, which is why the gap is easy to miss.
Adding the block to the example would fix it:
pull-requests: writeis the documented alternative toissues: writehere, not a third permission.This matters more than a typo because the surrounding section is about handling a potentially untrusted triggering workflow, and the example already carries a security comment about not extracting into the workspace directory. An example in that context is the one readers are most likely to copy verbatim, and least likely to widen by hand.
Additional information
I read the source on main today, 17 August 2026, at
content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md. The example there has nopermissions:key.I checked six permission combinations against the two documented requirements. The current example fails on a restricted default and passes on a permissive one. The example with
actions: readandissues: writepasses on a restricted default. Either permission alone fails. Thepull-requests: writevariant passes. This is a reading of your documented requirements and not a live Actions run, so I am not reporting an observed error message.I searched open and closed issues first. There are reports about
GITHUB_TOKENpermissions in general, but none about this example.The pages I read for the requirements:
The GitHub Security Lab article on preventing pwn requests uses the same two-workflow pattern and declares
actions: readandpull-requests: writeexplicitly, which is the shape I am suggesting here.Three things would make this report wrong, and I would rather name them than have you find them. If a
workflow_runjob is guaranteedActions: readandIssues: writeregardless of a restricted effective default, there is nothing to fix. If the cross-run download path in this exact example does not needActions: readwhen givenGITHUB_TOKEN, drop that line from the suggestion. And if the restricted default grants more thancontentsandpackagesin the relevant product context, the portability argument goes away.