Create issue comment requires both Issues and Pull requests write for GitHub App installation tokens
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
- Domain
- api, authorization, documentation
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
Summary
The Create an issue comment reference says that a GitHub App installation access token needs at least one of these permission sets:
Issuesrepository permission:writePull requestsrepository 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
- Install a GitHub App on one selected private repository with these repository permissions:
Contents: read,Pull requests: read,Checks: write,Issues: write, andMetadata: read. - Create an installation access token.
POST /repos/{owner}/{repo}/issues/{pull_number}/commentswith a normal JSONbody.
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/rest-api-description
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
github/rest-api-description#7201 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/rest-api-description#7163 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
github/rest-api-description#7162 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
github/rest-api-description#7135 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
github/rest-api-description#7111 · 1 comment ·
All issues in github/rest-api-description
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
use-agent-os/agent-os#3312 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
needs-acceptance wg/data-plane-networking
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vllm-project/semantic-router#4024 · 1 comment ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
amponce/archive-movie-browser#165 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100