[Marrrrrrrrry]

Why:

The workflow-runs-dependabot-note reusable (rendered on the workflow-syntax reference page under "Permissions for workflow runs triggered by Dependabot") states that Dependabot-triggered workflow runs "run as if they are from a forked repository, and therefore use a read-only GITHUB_TOKEN" and "cannot access any secrets".

This contradicts two other official sources:

1. The Dependabot troubleshooting article, section "Changing GITHUB_TOKEN permissions" (https://docs.github.com/en/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions): "By default, workflows triggered by Dependabot get a GITHUB_TOKEN with read-only permissions. You can use the permissions key in your workflow to increase the access for the token."
2. The same workflow-syntax reference page's own "Permissions for forked repositories" section, which scopes the write-to-read downgrade to pull requests from forked repositories — Dependabot branches live in the same repository, not a fork.
3. The dependabot/fetch-metadata README maintained by GitHub (https://github.com/dependabot/fetch-metadata), whose "Auto-approving" example relies on exactly this pattern (pull_request + pull-requests: write).

Following the reusable as written would make readers conclude that the documented auto-approval pattern is impossible.

What changes are you making?

Rewrite the reusable to match the troubleshooting article: Dependabot-triggered runs use a read-only token by default, and the permissions key can increase the access. Link to the troubleshooting article for details, keep the link to the secure-use article. One line changed; no other content affected.

Follow-up to #37657, which fixed other parts of this contradiction but left this reusable unchanged.

Validation:

• Both statements are quoted verbatim from main as of 2026-10-28; the replacement text closely paraphrases the troubleshooting article's "Changing GITHUB_TOKEN permissions" section.
• git grep sweep over content/ and data/: the stale claim exists in exactly one place on main (this reusable), the reusable renders on exactly one page (the workflow-syntax reference), and no occurrence remains after the change — the one-line edit covers the entire contradiction.
• Both AUTOTITLE link targets verified to exist in this repository.
• The runtime-behavior claim (elevation via the permissions key) is sourced from the troubleshooting article and the fetch-metadata README; no runtime test was performed as part of this docs change.

[github-actions]

How to review these changes 👓

Thank you for your contribution. To review these changes, choose one of the following options:

• Spin up a codespace
• Set up a local development environment

A Hubber will need to deploy your changes internally to review.

Table of review links

Note: Please update the URL for your staging server or codespace.

The table shows the files in the content directory that were changed in this pull request. This helps you review your changes on a staging server. Changes to the data directory are not included in this table.

Source	Review	Production	What Changed
actions/reference/workflows-and-actions/workflow-syntax.md	fpt ghec ghes@ 3.22 3.21 3.20 3.19 3.18	fpt ghec ghes@ 3.22 3.21 3.20 3.19 3.18	from reusable

Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server

🤖 This comment is automatically generated.

[subatoi]

Thanks @Marrrrrrrrry, this will be reviewed by the appropriate team

[mchammer01]

@Marrrrrrrrry 👋🏻 - thanks for noticing the discrepancy in our documentation, and for fixing it ✨
LGTM, made a minor suggestion that I'm going to apply before merging.

[github-actions]

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡