workflow_run "Use the data" example omits the permissions the example itself needs #45520

Code of Conduct

• I have read and agree to the GitHub Docs project's 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:

• How permissions are calculated for a workflow job
• Setting GITHUB_TOKEN permissions for a repository
• Download an artifact
• Create an issue comment

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.