Github Workflow unable to create a release on a known and pushed branch with error "HTTP 403: Resource not accessible by integration"

[rdelfin]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

We have a workflow that runs when commits are pushed to branches that follow a certain pattern (think release branches with a naming convention). This job builds some code, and uses the gh CLI to create and publish a release on our repo. The relevant step looks as follows (repo named anonymised as <ORG>/<REPO>):

- name: Create GitHub release
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          RELEASE_TAG="${{ env.RELEASE_NAME }}"

          if gh release view "${RELEASE_TAG}" >/dev/null 2>&1; then
            echo "GitHub release ${RELEASE_TAG} already exists; skipping creation."
            exit 0
          fi

          echo "Creating GitHub release ${RELEASE_TAG}..."
          gh release create "${RELEASE_TAG}" \
            --title "Release ${RELEASE_TAG}" \
            --generate-notes \
            --target "${GITHUB_SHA}"

And the logs result in the following error (replaced the commit hash with deadbeef00):

Creating GitHub release 2026.07.22-1-gdeadbeef00...
HTTP 403: Resource not accessible by integration (https://api.github.com/repos/<ORG>/<REPO>/releases)

After some additional digging, we tried pushing the tag first (doing a git tag -a ${TAG} ${GITHUB_SHA} followed by git push origin "refs/tags/${TAG}) and got a slightly different error:

To https://github.com/<ORG>/<REPO>
 ! [remote rejected]   2026.12.24-1-gdeadbeef00 -> 2026.12.24-1-gdeadbeef00 (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>'
git-push-tag=FAILED

So it seems a check internally timed out. Is this a known and expected behaviour or a bug in how tags are checked against rulesets? The branch's commits include no additions to any workflows, but main has changed a fair bit since this release was cut and main has moved forwards a fair bit.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[asp53826]

These look like two permission checks, not a problem with the branch-name pattern.

For the release call, give only the release job write access to repository contents:

jobs:
  release:
    permissions:
      contents: write
    steps:
      # ...
      - name: Create GitHub release
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          gh release create "${{ env.RELEASE_NAME }}" \
            --title "Release ${{ env.RELEASE_NAME }}" \
            --generate-notes \
            --target "${GITHUB_SHA}"

GH_TOKEN tells gh which token to use; it does not increase that token's permissions. New repositories commonly give GITHUB_TOKEN read-only contents access by default, while the create-release endpoint requires Contents: write.

You also do not need to push the tag separately here. When the tag does not exist, gh release create creates it, and --target selects the branch or commit for that tag.

If the release still fails after adding contents: write, check these in order:

1. Confirm this is a push run from the same repository. Tokens for fork pull requests and Dependabot runs are forced read-only in the usual configuration.
2. Check Settings → Actions → General → Workflow permissions at both repository and organization level. An organization or enterprise policy can keep the token restricted.
3. The separate workflows scope may be required response means the new ref is also crossing GitHub's workflow-file permission guard. The built-in GITHUB_TOKEN does not expose a workflows: permission in workflow YAML. Prefer targeting a commit whose workflow changes are already present on the default branch. If that is impossible, use an organization-approved GitHub App or fine-grained token limited to this repository with Contents: write and Workflows: write rather than a broad personal token.

Relevant GitHub references:

• permissions for GITHUB_TOKEN
• Create a release permissions
• gh release create tag behavior

[rdelfin]

I have done all this already, it already has contents: write. The problem is this failure is intermittent, not consistent, as this workflow has been in place for months. Providing a github action workflow permissions when it isn't required seems like quite a bad idea as it's disabled for a reason.