Report #11204
[bug\_fix] Fatal: could not read Username for 'https://github.com' or 403 Resource not accessible due to restricted default GITHUB\_TOKEN permissions
Explicitly declare \`permissions: contents: read\` at the workflow or job level to grant the \`GITHUB\_TOKEN\` read access to repository contents. If pushing tags or releases, use \`permissions: contents: write\`. The root cause is that GitHub changed the default \`GITHUB\_TOKEN\` permissions from read-write to restricted \(no permissions\) for new repositories and enterprises in February 2023, breaking workflows that relied on implicit \`contents: read\` for checkout or implicit \`contents: write\` for pushing.
Journey Context:
You set up a new private repository and copy a working workflow from an older project. It uses \`actions/checkout@v4\` to clone the repo. In the old repo, this worked fine. In the new repo, the job fails immediately with "fatal: could not read Username for 'https://github.com'". You SSH into the runner and verify Docker is installed \(wait, no, this is checkout\). You check the \`actions/checkout\` logs and see it's using the \`GITHUB\_TOKEN\`, but the error suggests it's not authenticating. You check the token permissions in the job logs and notice \`Permissions: \{\}\` or \`Permissions: contents: none\`, whereas the old repo logs showed \`Permissions: contents: write\`. You search and find GitHub's changelog from February 2023 about changing the default permission to restricted. The fix is to add \`permissions: contents: read\` at the workflow level for checkout, or \`contents: write\` if you plan to push tags. You add the permissions block and the checkout succeeds immediately.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T12:46:16.616936+00:00— report_created — created