Describe the bug
When a token (GitHub App, fine-grained PAT, or GITHUB_TOKEN) lacks the project permission, commands that query projectItems fail with:
GraphQL: Resource not accessible by integration (repository.pullRequest.projectItems.nodes.0),
Resource not accessible by integration (repository.pullRequest.projectItems.nodes.1)
The ProjectsV2IgnorableError function is designed to gracefully ignore project-related permission errors, but it only checks for these specific strings:
"field requires one of the following scopes: ['read:project']"
"Field 'projectsV2' doesn't exist on type 'User'"
"Field 'projectsV2' doesn't exist on type 'Repository'"
"Field 'projectsV2' doesn't exist on type 'Organization'"
"Field 'projectItems' doesn't exist on type 'Issue'"
"Field 'projectItems' doesn't exist on type 'PullRequest'"
It does not match:
"Resource not accessible by integration" (GitHub Apps, GITHUB_TOKEN)
"Resource not accessible by personal access token" (fine-grained PATs)
These errors surface when the token can resolve the projectItems connection but cannot read individual ProjectV2Item nodes due to missing project permissions.
Affected commands
ProjectsV2IgnorableError is called in five places:
pkg/cmd/pr/shared/finder.go — PR lookup (affects pr view, pr edit, pr checks, etc.)
pkg/cmd/issue/shared/lookup.go — issue lookup (affects issue view, issue edit)
api/queries_repo.go — repo metadata fetching (three call sites)
Any command that fetches projectItems will crash instead of gracefully degrading when the token lacks project access.
Steps to reproduce
- Use a
GITHUB_TOKEN or fine-grained PAT without the project permission
- Run any command on an issue/PR that is linked to a ProjectV2, e.g.:
gh pr view 123
gh pr edit 123 --body "new body"
- Observe the error:
GraphQL: Resource not accessible by integration (repository.pullRequest.projectItems.nodes.0)
Expected vs actual behavior
Expected: Project fields are omitted from the output (graceful degradation), and the command succeeds for non-project fields.
Actual: The entire command fails with a permission error.
Proposed fix
Add "Resource not accessible by" as an ignorable pattern in ProjectsV2IgnorableError. This prefix covers all three authorizer variants (integration, personal access token, this actor) and is safe because the function is only called in project-specific code paths.
Related issues
Describe the bug
When a token (GitHub App, fine-grained PAT, or
GITHUB_TOKEN) lacks theprojectpermission, commands that queryprojectItemsfail with:The
ProjectsV2IgnorableErrorfunction is designed to gracefully ignore project-related permission errors, but it only checks for these specific strings:"field requires one of the following scopes: ['read:project']""Field 'projectsV2' doesn't exist on type 'User'""Field 'projectsV2' doesn't exist on type 'Repository'""Field 'projectsV2' doesn't exist on type 'Organization'""Field 'projectItems' doesn't exist on type 'Issue'""Field 'projectItems' doesn't exist on type 'PullRequest'"It does not match:
"Resource not accessible by integration"(GitHub Apps,GITHUB_TOKEN)"Resource not accessible by personal access token"(fine-grained PATs)These errors surface when the token can resolve the
projectItemsconnection but cannot read individualProjectV2Itemnodes due to missing project permissions.Affected commands
ProjectsV2IgnorableErroris called in five places:pkg/cmd/pr/shared/finder.go— PR lookup (affectspr view,pr edit,pr checks, etc.)pkg/cmd/issue/shared/lookup.go— issue lookup (affectsissue view,issue edit)api/queries_repo.go— repo metadata fetching (three call sites)Any command that fetches
projectItemswill crash instead of gracefully degrading when the token lacks project access.Steps to reproduce
GITHUB_TOKENor fine-grained PAT without theprojectpermissionExpected vs actual behavior
Expected: Project fields are omitted from the output (graceful degradation), and the command succeeds for non-project fields.
Actual: The entire command fails with a permission error.
Proposed fix
Add
"Resource not accessible by"as an ignorable pattern inProjectsV2IgnorableError. This prefix covers all three authorizer variants (integration,personal access token,this actor) and is safe because the function is only called in project-specific code paths.Related issues
gh pr editdoes not work with onlypull-requests: writepermissions #6274 —gh pr editunconditionally fetches project data even when not editing projects (separate root cause, same symptom)gh pr editnot working on FGAT + GH Actions despite having all the necessary permissions #8784 — same asgh pr editdoes not work with onlypull-requests: writepermissions #6274 but with fine-grained PATs