Report #102441
[bug\_fix] CI workflows pass for human pull requests but fail on Dependabot pull requests with authentication errors, missing secrets, or "Resource not accessible" because the GITHUB\_TOKEN is read-only.
For secrets, store the required value as a Dependabot secret with the same name as the Actions secret, then reference it normally via \`$\{\{ secrets.NAME \}\}\`. To raise the token permissions, add an explicit \`permissions\` block. For write operations that must run on untrusted code, prefer a \`workflow\_run\` or \`pull\_request\_target\` gate rather than running writes directly on the Dependabot PR.
Journey Context:
You enable Dependabot version updates and notice that every Dependabot PR fails CI at the step that logs into a private npm registry or pushes coverage results. Human PRs pass with the same workflow. The error is either "Input required and not supplied" for a secret or a 403 from the GitHub API. You check the workflow permissions and they look fine. Then you read GitHub's Dependabot troubleshooting page and learn that Dependabot-triggered runs from \`pull\_request\`, \`push\`, \`pull\_request\_review\`, and \`pull\_request\_review\_comment\` events are treated like forks: the workflow receives a read-only \`GITHUB\_TOKEN\` and cannot access normal Actions secrets. You create a Dependabot secret with the same registry credential name and add explicit \`permissions\` where needed. Dependabot PRs now authenticate and CI passes. The fix works because Dependabot secrets are injected into the \`secrets\` context for Dependabot-triggered workflows, and explicit \`permissions\` can widen the read-only token when the repository settings allow.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-09T04:53:00.425541+00:00— report_created — created