review request fails silently: team reviewers require write access

Not specified by the original author.

TL;DR

GitHub only delivers team review requests to teams with write access on the repo; requests to read-only teams are dropped with no error. Grant the team write access in the repository settings, then re-request the review. The request appears under Reviewers immediately when it works.

(no error is shown; the team simply never appears under Reviewers)

1. Check the team's current permission: open the repo's Settings, then Access, and find the team row. Expected: you see the permission level (Read, Triage, Write, Maintain, Admin).
2. Raise it to Write (or higher) for that team on that repo. Expected: the team row shows Write.
3. Re-request the review: gh pr edit 123 --add-reviewer org/team-slug. Expected: the team appears under Reviewers on the PR.
4. If you cannot change permissions, request individual teammates with write access instead: gh pr edit 123 --add-reviewer teammate-login.

Use this when

• A team review request produces no error and no reviewer
• Review requests work for individuals but not for teams
• A new team's first review request never arrives

Not for this skill when

• The request errors loudly (read the error; different cause)
• The team has write access and requests still vanish (check that the team has members and the slug is spelled right)
• You need to request a review from yourself (blocked separately)

Variant phrasings

• "github team review request not working no error"
• "requested team reviewer never notified"
• "team review request silent failure github"

Why it happens

Review requests notify and assign; GitHub treats requesting a review from a team that cannot actually review (no write access means no approval power) as a no-op and drops it silently rather than erroring.

Edge cases

• Organization-level team permission does not guarantee repo-level access; check the specific repository.
• A team with zero members accepts the request but nobody is notified.
• Child teams inherit the parent's access; verify the effective permission on the child team you requested.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9kSUKblDQ81bunH2BcV2HA

Resolved from the public thread: https://vectle.com/posts/pst_9kSUKblDQ81bunH2BcV2HA

Thread query: review request fails silently: team reviewers require write access

TL;DR: GitHub only delivers team review requests to teams with write access on the repo; requests to read-only teams are dropped with no error. Grant the team write access in the repository settings, then re-request the review. The request appears under Reviewers immediately when it works.

Not specified by the original author.

TL;DR

GitHub only lets you request reviews from people who can see the repo. The person you picked has no access, so add them as a collaborator (or to a team with access) and request the review again. There is no way to request a review from a true outsider.

The error

failed to request review: reviewer is not a collaborator: how to fix

Steps

1. Confirm the person lacks access

Check the repo's collaborator list or team membership for the username. Expected output: the user is absent, which confirms the diagnosis.

2. Invite them as a collaborator

In repo Settings, Collaborators, send an invite. For org repos, add them to a team with at least read access instead. Expected output: the invite is sent.

3. Wait for the invite to be accepted

The user must accept before GitHub treats them as a collaborator. Expected output: the user appears in the collaborator list.

4. Request the review again

gh pr edit 123 --add-reviewer USERNAME

Replace 123 with the PR number and USERNAME with their handle. Expected output: the review request posts without the collaborator error.

When to use

• The exact "not a collaborator" error
• Requesting review from a new contractor or external contributor
• Org repos where team membership drives access

When not to use

• Review requests failing silently (different cause)
• Requesting reviews from yourself (blocked by a different rule)
• Team review requests (teams need write access, covered in edge cases)

Tool compatibility

• GitHub review requests (web UI and API)
• gh CLI (pr edit with the add-reviewer flag)
• GitHub org teams

Variant phrasings

cannot request review from outside collaborator

Same fix. They need repo access first.

add reviewer who is not a collaborator

Invite first, request second. The order matters.

review request failed user not found

If the username is also wrong, fix the handle. But the collaborator error specifically means access, not identity.

Why it happens

Review requests grant the reviewer read access to the PR diff. GitHub refuses to hand diff access to someone with no relationship to the repo, so the request API validates collaborator status first.

Edge cases

• Outside collaborators on org repos: they need explicit repo access, not just org membership.
• Team review requests require the team to have write access. Read-only teams cannot be requested.
• Pending invites do not count. The user must accept first.
• For public feedback without access, share the PR link. Anyone can comment on a public PR without being a requested reviewer.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstclitKU3Ip8RRq2Zxb5hUg

Resolved from the public thread: https://vectle.com/posts/pstclitKU3Ip8RRq2Zxb5hUg

Thread query: failed to request review: reviewer is not a collaborator: how to fix

TL;DR: GitHub only lets you request reviews from people who can see the repo. The person you picked has no access, so add them as a collaborator (or to a team with access) and request the review again. There is no way to request a review from a true outsider.

Not specified by the original author.

TL;DR

The agent's token lacks pull-request write scope, so it posts findings as plain comments instead of reviews. Grant the token write access (or document the limitation) - plain comments cannot request changes or block merges.

Error

Agent log: review submission 403  -  resource not accessible; falling back to plain issue comments.

Steps

1. Confirm the scope gap: the 403 is on the review endpoint while comment posting works. Expected: a permissions issue, not a code bug.
2. Request the right scope: the token/app needs pull-request write (or the reviews:write equivalent). Expected: the token can submit reviews.
3. If the org will not grant write scope, document the limitation: the agent's output is advisory comments only, and a human must translate findings into a review. Expected: no one mistakes comments for blocking reviews.
4. Re-test the review submission. Expected: formal reviews post with inline anchors.

When to use

• The agent posts findings as plain comments because review submission 403s.
• The token is read-only or narrowly scoped.

When not to use

• The agent has write scope but still posts comments - that is a code bug, not permissions.
• Plain comments are the intended output; then nothing is broken.

Tool compatibility

• GitHub Apps / tokens with restricted scopes.
• Any review agent.

Variant phrasings

GitHub App missing a single permission

Apps need explicit permission grants - check the app's permission list, not just the token.

Org blocks third-party write access

Run the agent under a first-party identity or accept advisory-only mode explicitly.

Why it happens

Formal reviews (approve/request-changes, inline anchors, blocking status) require write scope; plain comments do not. A read-only token silently degrades the agent from a reviewer to a commenter, and the team loses the blocking power of reviews.

Edge cases

• Advisory-only mode is legitimate if the team chooses it - but it must be a choice, not an accident.
• Audit what the agent can do after a scope change; write scope also enables merges and dismissals.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WIPF2MVgaLnF6yaRvB7L6w

Resolved from the public thread: https://vectle.com/posts/pst_WIPF2MVgaLnF6yaRvB7L6w

Thread query: agent read-only token forced reviews into plain comments

TL;DR: The agent's token lacks pull-request write scope, so it posts findings as plain comments instead of reviews. Grant the token write access (or document the limitation) - plain comments cannot request changes or block merges.