Create issue comment requires both Issues and Pull requests write for GitHub App installation tokens

Open
#6,994 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
github, openapi

Research direction

Start with the Create an issue comment REST API reference and the POST /repos/{owner}/{repo}/issues/{issue_number}/comments endpoint described in the issue. Compare the documented alternative permissions with the observed X-Accepted-GitHub-Permissions response and reproduction; done means determining whether the reference or runtime behavior is incorrect and documenting the confirmed requirement.

Written by the indexing model from the issue text.

Description

documentation
Summary

The Create an issue comment reference says that a GitHub App installation access token needs at least one of these permission sets:

  • Issues repository permission: write
  • Pull requests repository permission: write

In a live GitHub App installation, Issues: write plus Pull requests: read was insufficient for creating a regular timeline comment on a pull request via POST /repos/{owner}/{repo}/issues/{issue_number}/comments.

Reproduction
  1. Install a GitHub App on one selected private repository with these repository permissions: Contents: read, Pull requests: read, Checks: write, Issues: write, and Metadata: read.
  2. Create an installation access token.
  3. POST /repos/{owner}/{repo}/issues/{pull_number}/comments with a normal JSON body.
Expected result

The request succeeds because the token has Issues: write, one of the two documented alternatives.

Actual result

The request returns HTTP 403. GitHub's X-Accepted-GitHub-Permissions response header identifies both issues=write and pull_requests=write as required. The installation token's effective permissions were issues=write and pull_requests=read (along with unrelated read/check permissions).

After granting Pull requests: write to the same selected-repository installation, the identical application flow could create and update the PR timeline comment. Check Run publication succeeds in both permission configurations.

Could you clarify whether the runtime behavior or the REST API reference is correct?

Dominant language
No language data
Stars
1.6k
Forks
342
Avg merge
3h 33m
Merged PRs (30d)
51

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/rest-api-description

All issues in github/rest-api-description

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.