GITHUB_TOKEN returns HTTP 403 when reading PR comments despite Issues: read

[tatsuya27code]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Hello,

I'm investigating a GitHub Actions authorization problem in a private repository.

An "issue_comment" (created) event successfully triggers my workflow.

The workflow declares:

"permissions: contents: read, issues: read"

The job setup log confirms "Issues: read".

A Python script uses the workflow-issued "${{ github.token }}" to call:

"GET /repos/{owner}/{repo}/issues/{pr_number}/comments?per_page=100&page=1"

However, GitHub responds with:

• HTTP 403
• "Resource not accessible by integration"
• Core rate-limit remaining: 4997

The "X-Accepted-GitHub-Permissions" header lists "issues=read" or "pull_requests=read" as accepted alternatives.

The PR is already merged and contains comments. Another authorized GitHub integration can retrieve the comments, but it uses a different authentication identity.

My questions:

1. Why is "GITHUB_TOKEN" denied access despite the job reporting "Issues: read"?
2. Are there restrictions for "issue_comment" events on merged PRs?
3. Is there a least-privilege solution without adding a PAT or unnecessarily expanding permissions?

The workflow intentionally fails closed when comment history cannot be verified.

Thank you for your help.

[marcuspaula-seceng]

issues: read should be enough for GET /repos/{owner}/{repo}/issues/{pr_number}/comments. The X-Accepted-GitHub-Permissions: issues=read; pull_requests=read header confirms either scope works, and there's no restriction on merged PRs. So when you get "Resource not accessible by integration" with that permission granted, it's almost always one of these:

1. The request isn't hitting the repo the token is scoped to.
GITHUB_TOKEN is an installation token limited to the repository running the workflow. If {owner}/{repo} is built from something like github.event.issue.repository_url, a head-repo field, or a hardcoded value, a mismatch (fork, renamed repo, different casing/org) gives exactly this 403. Log the final URL and compare it with ${{ github.repository }}.

2. A different token is actually being sent.
Python libraries often pick up GH_TOKEN/GITHUB_TOKEN from the environment or a .netrc. Make sure the header is built from the value you pass in:

env:
  TOKEN: ${{ github.token }}

headers = {"Authorization": f"Bearer {os.environ['TOKEN']}",
           "Accept": "application/vnd.github+json"}

3. Job-level permissions: overrides the workflow-level block.
If any job declares its own permissions:, the top-level block is ignored for that job. Check the "GITHUB_TOKEN Permissions" section of that specific job's setup log.

Quick isolation test (same job, before your script):

- run: gh api "repos/${{ github.repository }}/issues/${{ github.event.issue.number }}/comments" --jq 'length'
  env:
    GH_TOKEN: ${{ github.token }}

If this works, the problem is in how the script builds the request (URL or token). If it also fails with 403, add pull-requests: read. It's still read-only and least-privilege, and it's the other permission GitHub lists as accepted for PR-backed issues:

permissions:
  contents: read
  issues: read
  pull-requests: read

No PAT needed.

[c4rlosst]

I think, your token’s probably fine. It’s what the token can actually reach that’s the issue.

That “Issues: read” in the setup log? It just shows what your workflow asked for. Doesn’t mean you got it. If your org or repo has a default cap (Settings -> Actions -> General -> Workflow permissions), that cap wins over your YAML. Also, if there’s a job-level permissions: block anywhere, it wipes out the workflow-level one. Anything you didn’t list there goes to none. Sneaky.

The 4997 rate limit thing is a hint too. The request went through as authenticated, so it’s a straight-up “you’re not allowed” and not a rate limit or bad token.

also, comments stay readable after merge. But issue_comment workflows always run from the default branch’s workflow file, and if the PR came from a fork or Dependabot, GitHub gives you a nerfed token no matter what you wrote. Check if that’s your case.

Easiest fix, just add pull-requests: read. That header literally listed it as an accepted option:
permissions: -> contents: read -> issues: read -> pull-requests: read

Still read-only, still GITHUB_TOKEN, no PAT needed.

If it still 403s, check these:
-Org/repo workflow permission defaults
-Fork or Dependabot trigger
-Job-level permissions overriding the top one
-Make sure pr_number is the actual PR number, not a comment ID or run number

hope this helpsss

[UJJWAL-2027]

I'd start by isolating whether the 403 comes from the API request itself or from how the workflow token and repository are being resolved.

A few checks that may help:

1. Verify the exact endpoint and repository. Log the final API URL and compare its owner/repository with ${{ github.repository }}. For a PR comment-history check, confirm that pr_number is the actual pull request number.

2. Test with the same token in the same job. Try:

   - name: Test comment access
     run: gh api "repos/${GITHUB_REPOSITORY}/issues/${PR_NUMBER}/comments?per_page=100&page=1" --jq 'length'
     env:
       GH_TOKEN: ${{ github.token }}
       PR_NUMBER: ${{ github.event.issue.number }}

   If this succeeds, compare the Python request's URL, authorization header, and environment variables with the CLI request.

3. Check the effective permissions. A job-level permissions: block overrides the workflow-level block. Since the endpoint accepts issues: read or pull-requests: read, adding pull-requests: read is a reasonable minimal test if the repository and token are correct.

I wouldn't assume the merged state is the cause. The key is to identify why this particular request is denied despite the reported permissions. If the CLI test also returns 403, inspect repository policy and the event's token context before changing authentication methods.

This should help narrow it down without introducing a PAT or granting write permissions.

[Edgar-Ontiveros]

Your permissions look fine to me. What caught my attention was the rate limit shown in the 403 response.

The GITHUB_TOKEN has a limit of 1,000 requests per hour per repository (15,000 for Enterprise Cloud), while GitHub App installation tokens and user tokens typically have a 5,000-request limit.

Your response showed 4,997 requests remaining, which suggests the request might be using a different token instead of the workflow's GITHUB_TOKEN, even if you're passing ${{ github.token }} somewhere.

Also, the Resource not accessible by integration error usually means the token doesn't have the required access to that resource.

I'd check these three things first:

• Whether GITHUB_TOKEN or GH_TOKEN is being set somewhere else at the workflow, job, or step level, overriding the original token.
• Whether an earlier step is writing another token to $GITHUB_ENV, possibly through actions/create-github-app-token.
• Whether your Python script is actually reading the same environment variable you're setting in the workflow.

You can verify this without exposing the token by adding the following step:

- name: Check token rate limit
  env:
    GH_TOKEN: ${{ github.token }}
  run: |
    gh api -i "repos/${GITHUB_REPOSITORY}/issues/${{ github.event.issue.number }}/comments?per_page=1" \
      | grep -iE '^(HTTP|x-ratelimit-limit|x-ratelimit-resource)'

If everything is configured correctly, you should get a 200 response with x-ratelimit-limit: 1000.

Then, in your Python script, log only resp.headers.get("x-ratelimit-limit"). If it shows 5000, that's a good indication the script might be using a different credential.

As for your three questions:

1. Permissions: issues: read is enough for that endpoint. Based on the response, I suspect the issue is related to which token is being used.
2. Merged PR comments: There's no specific restriction preventing an issue_comment workflow from reading comments on merged pull requests.
3. PAT: You don't need one. You can keep issues: read (or pull-requests: read) and pass the job token to your script using a dedicated environment variable to avoid conflicts.

In your workflow:

env:
  COMMENTS_TOKEN: ${{ github.token }}

And in Python:

token = os.environ["COMMENTS_TOKEN"]

I'd start there, since the most likely explanation is that your script is picking up a different token than the one you intended to use.