review agent posted as the repo owner because its token was over-scoped:

Not specified by the original author.

TL;DR

Stop using the owner's personal credential for automation. Create a GitHub App (or a fine-grained personal credential) scoped to the single repo with only pull-requests write and contents read, mint a short-lived credential per run, and revoke the over-scoped owner credential. Bot actions should never wear a human's identity.

The problem

review agent posted as the repo owner because its token was over-scoped: how to fix

When to use

• Bot reviews and comments appear under the owner's name and avatar
• A personal credential with broad scopes lives in CI secrets for automation
• Commits pushed by automation are attributed to the owner
• Audit logs cannot distinguish bot actions from the owner's actions

When not to use

• A GitHub App is already posting under its own identity (working as intended)
• The wrong identity comes from git config user.name on commits (a checkout config issue)
• You intentionally want the automation to act as a specific user

Steps

1. Confirm which identity and credential are in play

Check the review's author field via the API and compare it to the credential stored in CI secrets. Note the credential's scopes: broad scopes on a personal credential are the smoking gun.

Expected output: confirmation that the poster is the owner account and the credential is a personal one with more scope than the job needs.

2. Create a least-privilege automation identity

Create a GitHub App installed on the single repo with only the permissions the reviewer needs (pull requests write, contents read), or a fine-grained personal credential limited to that repo with the same minimal scopes.

Expected output: an automation identity whose blast radius is one repo and a few permissions.

3. Mint a short-lived credential per run

In CI, mint an installation credential at job start and use it for the review steps. Never store a long-lived owner credential in repo secrets for automation to use.

Expected output: credentials that expire after the run; a leaked value is useless within the hour.

4. Rotate and revoke the over-scoped owner credential

Generate a replacement for anything legitimate still using the old credential, then revoke it. Expected output: the owner credential can no longer post as the owner from automation.

5. Re-run one review and verify the author field

Post a test review and check the author via the API. Expected output: the app or bot identity, not the owner.

Tool compatibility

• GitHub Apps installation credentials: the recommended path; fine-grained and short-lived; available on github.com and GHES.
• Fine-grained personal credentials: acceptable when an App is overkill; scope to one repo.
• gh CLI 2.x: works with either credential type via standard auth.

Variant phrasings

bot comments show up as the repo owner

Same fix. Also check the checkout step: persist-credentials can leave the triggering user's credential in git config, affecting pushes even after the API identity is fixed.

automation using my personal access credential

Migrate it to the App model in step 2. Personal credentials in shared automation are also a rotation headache when the human leaves.

review posted by wrong GitHub account

Verify with step 1 whether the wrong account is the credential identity (this fix) or just the commit author config (then fix git user.name/user.email in the job).

Why it happens

The quickest way to give a bot API access is to paste in a personal credential, and the most available one belongs to whoever set up the automation - usually the repo owner. It works, so it ships, and from then on every bot action wears the owner's identity with the owner's full permissions attached.

Edge cases

• Checkout with persist-credentials: the git remote keeps the job credential; set git author explicitly for any commits the job creates.
• Reusable workflows: secrets inherit into called workflows; audit the whole chain, not just the top workflow.
• GHES with restricted App permissions: confirm the App permission model covers review posting before migrating.
• Existing open PENDING reviews by the old identity: submit or dismiss them before revoking, or they orphan.

Provenance

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

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

Thread query: review agent posted as the repo owner because its token was over-scoped: how to fix

TL;DR: Stop using the owner's personal credential for automation. Create a GitHub App (or a fine-grained personal credential) scoped to the single repo with only pull-requests write and contents read, mint a short-lived credential per run, and revoke the over-scoped owner credential. Bot actions should never wear a human's identity.

Not specified by the original author.

TL;DR: Check the credential's granted scopes, add the missing repo scope (or contents read permission), re-authenticate, and retry. GitHub returns 404 rather than 403 for private repos when the credential lacks access, which misleads people into debugging the repo name instead of the scopes. Minimal-scope credentials are good practice, but "minimal" must still include the private repos the agent reviews.

review agent unable to read private repo diff: token lacks repo scope

1. Confirm the scope hypothesis: call the API for a public repo and the private repo with the same credential. Expected: public returns 200, private returns 404 or 403.

2. Inspect the credential's granted scopes from the response headers on any API call. Expected: the header lists the scopes, and repo is absent.

3. Grant the missing scope: for a personal token add the repo scope, for a GitHub App add repository contents read permission, for a fine-grained token add contents read on the repository. Expected: the credential now carries the scope.

4. Re-authenticate so the new scopes take effect (new token, or a fresh installation token). Expected: a test call shows the scope present.

5. Retry the private diff fetch. Expected: 200 with the full diff content.

6. Document the minimum scopes the agent needs so the next setup gets it right the first time. Expected: a short scope list in the agent's setup notes.

Use this when

• the agent reads public repos but not private ones
• diff or content API calls 404 on private repos
• the credential is new or was created with minimal scopes

Not for this skill when

• public repos fail too (the credential is invalid or expired, not under-scoped)
• the repo does not exist or was renamed (check the name first)
• the failure is SSO-related on an Enterprise account (authorize the credential for the org instead)

Variant phrasings

github api 404 on private repo with valid token

review bot cant access private repository diff

credential missing repo scope for private PR review

Why it happens

GitHub deliberately returns 404 for private repositories when the caller lacks access, to avoid leaking the repo's existence. So an under-scoped credential produces "not found" rather than "forbidden", and the natural debugging instinct is to check the repo name or the URL. The real problem is the scope list on the credential.

Edge cases

• Fine-grained tokens are repo-specific; a token scoped to repo A returns 404 on repo B by design.
• Organization SAML enforcement can 403 even with the right scopes until the credential is authorized for the org.
• GitHub Apps need the installation to include the repository, not just the permission grant.
• Cached 404s in the agent can persist after the fix; clear the cache or restart the run.

Provenance

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

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

Thread query: review agent unable to read private repo diff: token lacks repo scope

TL;DR:

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.