GITHUB_TOKEN gets 403 when posting PR comments on branch protected by ruleset despite pull-requests: write permission

[llegaz]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

Bug report

Summary

The GITHUB_TOKEN returns a 403 error when trying to post a comment on a pull request targeting a protected branch (via a ruleset), even though pull-requests: write is explicitly declared in the workflow permissions and the ruleset only restricts merging, not interactions.

Steps to reproduce

1. Create a branch ruleset on the default branch with pull_request rule requiring 1 approving review
2. Run a GitHub Actions workflow with pull-requests: write and issues: write permissions
3. Have the workflow attempt to post a comment on a PR targeting the protected branch via the GitHub API (/repos/{owner}/{repo}/issues/{pr_number}/comments)
4. Observe a 403 error

Expected behavior

The GITHUB_TOKEN with pull-requests: write should be able to post comments on a PR regardless of branch protection rules, since commenting is not a protected operation — only merging is.

Actual behavior

Failed to call GitHub API (https://api.gh.umua.top/repos/{owner}/{repo}/issues/{pr_number}/comments): curl: (22) The requested URL returned error: 403

Workarounds attempted

• Set repository-level Actions permissions to "Read and write"
• Added issues: write and pull-requests: write to the workflow job permissions
• Added Write, Maintain, Deploy keys and all available bypass actors as Exempt on the ruleset (except Repository admin)
• None of the above resolved the issue

Context

• The same workflow posting to a PR targeting an unprotected branch works fine
• The ruleset only enforces deletion, non-fast-forward, pull_request review requirements, and linear history — nothing related to issue comments
• Observed with super-linter/super-linter but maybe reproducible with any workflow posting to the API endpoint

Environment

• GitHub Actions hosted runner (ubuntu-latest)
• Repository ruleset enforcement: active

[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. ⭐

[davex-ai]

Yeah—this one looks like a permissions bug at first glance, but it’s actually GitHub being stricter than the docs make obvious.

Let’s break it down cleanly.

---

🚨 What’s really happening

Even though you set:

permissions:
  pull-requests: write
  issues: write

the GITHUB_TOKEN is not treated like a normal user when a PR targets a protected branch (ruleset).

GitHub applies extra restrictions to automation tokens when:

• The PR targets a branch with rulesets / protections
• The workflow is triggered from certain events (especially pull_request from forks)

👉 Result:
The token gets silently downgraded in capability, even if permissions say write.

That’s why:

• ✅ Works on unprotected branches
• ❌ Fails (403) on protected branches

---

🔥 The key hidden rule

GITHUB_TOKEN cannot perform certain write actions on PRs targeting protected branches unless explicitly allowed via workflow context.

And commenting via /issues/{pr}/comments is treated as a write interaction, not just a harmless action.

---

🧠 Most likely root causes (ranked)

1. Wrong event context (pull_request vs pull_request_target)

If your workflow runs on:

on: pull_request

👉 Then for security:

• Token is read-only-ish when PR comes from forks
• Even stricter with protected branches

---

✅ FIX: Use pull_request_target

on:
  pull_request_target:

This runs in the base repo context, giving proper permissions.

⚠️ BUT: This is dangerous if you checkout PR code directly (can run untrusted code).

Safe pattern:

- uses: actions/checkout@v4
  with:
    ref: ${{ github.event.pull_request.base.ref }}

---

2. Forked PR restriction

If PR is from a fork:

• GITHUB_TOKEN is intentionally restricted
• Even with write permissions → still blocked

👉 GitHub does this to prevent supply chain attacks

---

3. Rulesets ≠ just merge protection

Even though your ruleset says:

“only restricts merging”

GitHub internally treats rulesets as:

• full branch governance layer
• affects automation behavior too

So yes—it can indirectly block comments

---

🧪 Why your workaround didn’t work

You tried:

• Repo-level write permissions ✅
• Workflow permissions ✅
• Bypass actors ✅

But:

👉 GITHUB_TOKEN is NOT considered a bypass actor

Only:

• Real users
• GitHub Apps
• PATs (Personal Access Tokens)

---

💡 Reliable solutions

✅ Option 1 (Best): Use pull_request_target

on:
  pull_request_target:

✔ Keeps using GITHUB_TOKEN
✔ Works with protected branches
✔ No extra secrets needed

---

✅ Option 2: Use a PAT (stronger but heavier)

Create a token with:

• repo scope

Then:

env:
  GH_TOKEN: ${{ secrets.PAT_TOKEN }}

Use that instead of GITHUB_TOKEN.

✔ Full permissions
✔ Not restricted by rulesets

❌ Less secure
❌ You must manage the secret

---

✅ Option 3: Use a GitHub App (cleanest long-term)

• Install app on repo
• Use installation token

✔ Proper permission model
✔ Not affected like GITHUB_TOKEN

---

🧩 Subtle gotcha (important)

You’re using:

/issues/{pr_number}/comments

That endpoint is tied to Issues API, not PR API.

👉 Even though PRs are issues internally, GitHub sometimes:

• Applies different permission checks

Try also:

/repos/{owner}/{repo}/pulls/{pr_number}/reviews

or review comments endpoints.

---

---

👉 Use this combo:

• pull_request_target for PR interactions
• Strict checkout (base branch only)
• Optional: fallback to PAT for edge cases

---

Upvote if this helps

[aboodmm0087-del]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

Bug report

Summary

The GITHUB_TOKEN returns a 403 error when trying to post a comment on a pull request targeting a protected branch (via a ruleset), even though pull-requests: write is explicitly declared in the workflow permissions and the ruleset only restricts merging, not interactions.

Steps to reproduce

1. Create a branch ruleset on the default branch with pull_request rule requiring 1 approving review

2. Run a GitHub Actions workflow with pull-requests: write and issues: write permissions

3. Have the workflow attempt to post a comment on a PR targeting the protected branch via the GitHub API (/repos/{owner}/{repo}/issues/{pr_number}/comments)

4. Observe a 403 error

Expected behavior

The GITHUB_TOKEN with pull-requests: write should be able to post comments on a PR regardless of branch protection rules, since commenting is not a protected operation — only merging is.

Actual behavior

Failed to call GitHub API (https://api.gh.umua.top/repos/{owner}/{repo}/issues/{pr_number}/comments): curl: (22) The requested URL returned error: 403

Workarounds attempted

• Set repository-level Actions permissions to "Read and write"

• Added issues: write and pull-requests: write to the workflow job permissions

• Added Write, Maintain, Deploy keys and all available bypass actors as Exempt on the ruleset (except Repository admin)

• None of the above resolved the issue

Context

• The same workflow posting to a PR targeting an unprotected branch works fine

• The ruleset only enforces deletion, non-fast-forward, pull_request review requirements, and linear history — nothing related to issue comments

• Observed with super-linter/super-linter but maybe reproducible with any workflow posting to the API endpoint

Environment

• GitHub Actions hosted runner (ubuntu-latest)

• Repository ruleset enforcement: active

[mao19901987-lang]

Arfu

[aboodmm0087-del]

Arfu

[mao19901987-lang]

Arfu

npx -y @tencent-weixin/openclaw-weixin-cli@latest install

[aboodmm0087-del]

Arfu

npx -y @tencent-weixin/openclaw-weixin-cli@latest install

[aboodmm0087-del]

Arfu

npx -y @tencent-weixin/openclaw-weixin-cli@latest install

[aboodmm0087-del]

في أحد، ٥ أبريل، ٢٠٢٦ في ٨:٥٤ ص، كتب mao19901987-lang < ***@***.***>:

…

Arfu npx -y @***@***.*** install — Reply to this email directly, view it on GitHub <#191524 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAFAR6I2YDPJBRVSLMHMM3T4UHYJPAVCNFSM6AAAAACXMIOHMSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBVGI3TCNY> . You are receiving this because you commented.Message ID: ***@***.***>