checkout@v5 intermittently requires workflow-scope token to push branch updates while same workflow succeeds with checkout@v4

[masspaz]

After upgrading from actions/checkout@v4 to @v5, several of our deploy workflows that reset and force-push an archival branch begin failing intermittently with:

remote: error: Unable to determine if workflow can be created or updated due to timeout; `workflows` scope may be required.
! [remote rejected] HEAD -> deploy/<component>/<env> (Unable to determine if workflow can be created or updated due to timeout; `workflows` scope may be required.)
error: failed to push some refs to 'https://github.com/<org>/<repo>'

Here are the steps:

• Reads/checkout always succeed.
• The push sometimes fails when updating a deploy/* branch to a specific commit.
• If we change nothing else but set token: ${{ secrets.TOKEN }} (a PAT with workflow/workflows:write), the push succeeds.
• Oddly, after one successful run with the PAT, subsequent runs without the PAT sometimes succeed (until we target another commit/branch where it fails again).
• This behavior did not occur with checkout@v4.

With permissions: contents: write for GITHUB_TOKEN, git push should succeed for branch updates not changing workflow files, as it did with checkout@v4.

With checkout@v5, the push intermittently fails with the server-side message shown above unless we use a PAT/App token with workflow permission.

After one success with PAT, re-running without PAT sometimes works, which suggests a caching/timing/path issue in validation on the GitHub side or a behavioral change in how @v5 configures/persists creds.

Questions

Did checkout@v5 change anything about how credentials are persisted/used that would affect server-side validation for pushes (esp. around workflow file checks)?

What we’ve tried

• Ensured runner versions are ≥ 2.327.1 (Node 24).

• Kept persist-credentials at default (true).

• Verified permissions: include contents: write.

• Rolling back to checkout@v4 mitigates the issue.