In this repo (

OpenHands/software-agent-sdk

), the current PR review workflow is

.github/workflows/pr-review-by-openhands.yml

, which triggers on

pull_request_target

and runs a composite action

.github/actions/pr-review@main

. That action checks out the PR code, installs the SDK/tools, and runs

examples/03_github_workflows/02_pr_review/agent_script.py

inside GitHub Actions, and it authenticates to GitHub for posting review comments via `github-token: ${{ secrets.ALLHANDS_BOT_GITHUB_PAT }}`—so review comments appear as the identity that owns that PAT (currently

all-hands-bot

). I pulled and reviewed issue #2082: it proposes a “cloud mode” where the workflow would pass an

OPENHANDS_API_KEY

(no GitHub token), and OpenHands Cloud would run the review and post back to GitHub via the existing OpenHands Cloud GitHub App installation, so the review would appear from the Cloud bot identity and avoid PAT management. I then listed and compared the main alternatives for achieving a new reviewer identity like

openhands-reviewer

, focusing on (a) where the agent runs, (b) what GitHub credential is used, and (c) what identity appears on the PR: - Machine user

openhands-reviewer

+ PAT: agent runs in GHA; identity is exactly `openhands-reviewer`; simplest change but involves long-lived PAT management and is awkward for broad user adoption. - Use default Actions

GITHUB_TOKEN

: agent runs in GHA; identity is `github-actions[bot]`; easiest adoption but doesn’t meet the identity goal and can have permission quirks. - GitHub App

openhands-reviewer

(mint short-lived installation token in workflow): agent runs in GHA; identity is typically `openhands-reviewer[bot]`; better security/permission model than PAT but higher setup complexity and includes the

[bot]

suffix. - Cloud mode (per #2082): agent runs in OpenHands Cloud; identity is the Cloud GitHub App bot; best security/UX if you accept requiring a Cloud account/API key. - Hybrid cloud-auth: compute in GHA but GitHub posting delegated to Cloud; usually more complex and can reintroduce token-exfiltration concerns depending on design. - Pure GitHub App webhook service: no GHA workflow; app triggers review in Cloud/self-hosted and posts; clean product integration but requires operating a service. No code changes were made in the repository, so there is no diff to check, nothing to push, and no PR to open.

- I inspected the existing PR review workflow in

OpenHands/software-agent-sdk

and identified exactly how it works and why reviews currently appear from `all-hands-bot`: the workflow

.github/workflows/pr-review-by-openhands.yml

runs the agent inside GitHub Actions and authenticates to GitHub using

secrets.ALLHANDS_BOT_GITHUB_PAT

, so the review author is the PAT owner. - I pulled and reviewed issue #2082 and treated it as input: it proposes a “cloud mode” where GitHub Actions becomes a thin trigger and OpenHands Cloud (using the existing OpenHands Cloud GitHub App) runs/posts the review, avoiding PAT management and making the identity the Cloud App bot. - I produced a full alternatives analysis comparing feasible approaches for having a separate reviewer identity like

openhands-reviewer

, including: - machine user

openhands-reviewer

+ PAT - using built-in

github-actions[bot]

token - creating/using a GitHub App (

openhands-reviewer[bot]

) - Cloud mode via OpenHands Cloud GitHub App - hybrid cloud-auth variants - pure webhook/GitHub App service model with a tradeoff table focused on identity, where the agent runs, secrets required, and adoption/security implications. - Per your instruction, I posted exactly that initial response as a Markdown comment on issue #2082, and then verified by re-fetching the latest issue comment body that it is correctly formatted as Markdown and should render properly in GitHub. Checklist against your request: - [x] “Look at the pr-review workflow and understand it” — done (workflow + composite action + where agent runs + auth mechanism identified). - [x] “We want another reviewer agent identity than all-hands-bot, named `openhands-reviewer`” — addressed via explicit identity/auth alternatives and their implications. - [x] “Look at issue #2082 (grain of salt)” — done; incorporated as one option rather than assuming it’s correct. - [x] “List all alternatives and compare them” — done (6-option breakdown + comparison table). - [x] Post the initial response verbatim to the issue as a Markdown comment — done and verified. No code changes were made in the repo, so there is no git diff to review and nothing to push.

OpenHands encountered an error: **Request timeout after 30 seconds to https://eujkmwfnqwcyalyb.prod-runtime.all-hands.dev/api/conversations/64868de9-15d6-4ea8-9de9-76944421a3d3/ask_agent**. [See the conversation](https://app.all-hands.dev/conversations/64868de9-15d6-4ea8-9de9-76944421a3d3)for more information.

OpenHands encountered an error: **Request timeout after 30 seconds to https://eujkmwfnqwcyalyb.prod-runtime.all-hands.dev/api/conversations/64868de9-15d6-4ea8-9de9-76944421a3d3/ask_agent**. [See the conversation](https://app.all-hands.dev/conversations/64868de9-15d6-4ea8-9de9-76944421a3d3)for more information.

I'm on it! can track my progress here.

The current PR review flow’s “reviewer identity” is entirely determined by which GitHub credential you use to call the GitHub API to create the review (i.e., whose token is in

GITHUB_TOKEN

when the action posts the review). ## What the current

pr-review

workflow does (today) In

software-agent-sdk

(and it’s essentially mirrored in

OpenHands

too): - Workflow:

.github/workflows/pr-review-by-openhands.yml

- Trigger:

pull_request

(opened / ready_for_review / labeled / review_requested) - Fork behavior: it skips forks (because

pull_request

runs don’t get secrets for forks) - Action: runs

.github/actions/pr-review@main

- Execution location: the agent runs inside GitHub Actions, and it checks out the PR repo and runs: -

examples/03_github_workflows/02_pr_review/agent_script.py

- GitHub write credential (identity): the workflow passes: -

github-token: ${{ secrets.ALLHANDS_BOT_GITHUB_PAT }}

so the resulting PR review is authored by whoever owns that PAT → currently

all-hands-bot

. If we want reviews to come from

openhands-reviewer

, the core question is: what auth mechanism produces that identity without wrecking security/UX. --- ## Alternatives (identity + where the agent runs), and how they compare ### Option 1) GitHub machine user

openhands-reviewer

+ PAT (closest to today) How it works - Create a GitHub user

openhands-reviewer

- Add it to the org/repo - Create a (fine-grained) PAT and store it as a secret - Pass that PAT as

github-token

Identity in PRs - Exactly

openhands-reviewer

(this is the only mainstream way to get exactly that, i.e. no

[bot]

suffix) Pros - Minimal code/workflow change (mostly secrets + maybe update the

review_requested

login allowlist) - Clean separation from

all-hands-bot

Cons - Long-lived PAT security/rotation burden - For external users adopting this, it’s annoying: they must create their own machine user + PAT Best for - OpenHands-internal repos where you control org secrets and just want the name change fast. --- ### Option 2) Use GitHub Actions’ built-in

GITHUB_TOKEN

(

github-actions[bot]

) How it works - Don’t use a PAT at all; use

${{ github.token }}

Identity in PRs -

github-actions[bot]

(not

openhands-reviewer

) Pros - No extra GitHub credential secret needed (for GitHub auth) - Easiest for OSS adopters Cons - Identity is wrong for your goal - Still constrained by event security model (forks, permissions, etc.) Best for - “Make it easy for anyone to try” workflows, when identity doesn’t matter. --- ### Option 3) GitHub App named

openhands-reviewer

(token minted inside Actions from App private key) How it works - Create a GitHub App

openhands-reviewer

- Install it on the repo/org - Store

APP_ID

+

PRIVATE_KEY

as secrets - In workflow, mint an installation token (e.g.,

actions/create-github-app-token@v1

) - Pass that token as

github-token

Identity in PRs -

openhands-reviewer[bot]

(GitHub Apps virtually always show with

[bot]

) Pros - Short-lived installation tokens (better than PATs) - Granular permissions and auditability - A scalable pattern for other orgs (they can create/install their own app) Cons - More setup complexity than PAT - Still requires a sensitive secret (private key) in GitHub secrets - If you require the display name to be exactly

openhands-reviewer

(no

[bot]

), this doesn’t satisfy it Best for - Better security posture than PAT while keeping “agent runs in Actions”. --- ### Option 4) “Cloud mode” (Issue #2082): run the agent in OpenHands Cloud, post via the existing Cloud GitHub App How it works - GitHub Action becomes a thin trigger: - send

{repo, pr_number, options}

to OpenHands Cloud - Cloud runs the agent (compute + LLM config) - Cloud posts the review using the already-installed OpenHands Cloud GitHub App installation token Identity in PRs

- The OpenHands Cloud App bot identity (not `all-hands-bot`; also not necessarily exactly

openhands-reviewer

) Pros - No PAT/App private key stored in the repo workflow - Better story for running on fork PRs (since Cloud can hold credentials safely) - Avoids “untrusted PR code runs next to powerful secrets” problems Cons - Yes: users effectively need an OpenHands Cloud account/API key (unless you add an OIDC-based trust flow) - Requires SaaS backend endpoints + reliability/SLA Best for - Product-grade experience, best security model, but couples to Cloud. --- ### Option 5) Hybrid: agent runs in GitHub Actions, but identity/auth is “brokered” by Cloud There are two meaningful sub-variants: 5a. Cloud returns a short-lived installation token to the workflow - Then the agent in GHA posts the review. - Downside: if PR code is untrusted in that job, token exfiltration is a risk. 5b. Cloud never returns GitHub tokens; Cloud posts the review - GHA sends “review output” (or PR metadata) to Cloud, Cloud posts. - This is effectively “Cloud mode”, just with some compute still in GHA. Identity in PRs - Cloud App bot identity Pros - Can reduce what secrets live in GitHub - Can keep some compute local if you really want Cons - More moving parts than pure GHA or pure Cloud - Still likely requires Cloud account unless you do OIDC trust --- ### Option 6) No GitHub Actions: a GitHub App / webhook integration triggers reviews How it works - GitHub App receives PR events (label, ready_for_review, etc.) - Triggers agent in Cloud (or self-hosted service) - Posts review Identity in PRs - App bot identity Pros - Cleanest GitHub-native integration - Avoids

pull_request

vs

pull_request_target

security footguns entirely Cons - Requires operating a service (Cloud or self-host) - More initial engineering --- ## Quick comparison table | Option | Where agent runs | Review author identity | Secrets in repo | Cloud account required | Notes | |---|---|---|---|---|---| | 1) Machine user + PAT | GitHub Actions |

openhands-reviewer

| PAT (+ LLM key) | No | Only way to get exact name (no

[bot]

) | | 2) Built-in

GITHUB_TOKEN

| GitHub Actions |

github-actions[bot]

| LLM key only | No | Easiest OSS adoption; identity doesn’t match | | 3) GitHub App | GitHub Actions |

openhands-reviewer[bot]

| App key (+ LLM key) | No | Better than PAT; identity has

[bot]

| | 4) Cloud mode (2082) | OpenHands Cloud | Cloud App bot | OpenHands API key only | Yes | Best security/UX if Cloud is acceptable | | 5) Hybrid cloud-brokered | Mixed | Cloud App bot | OpenHands API key (maybe) | Yes | Usually more complex than it’s worth | | 6) App webhooks → service | Cloud/self-host | App bot | none (in repo) | Depends | Most “product-grade”; needs service | --- ## The key decision point If “`openhands-reviewer` must be exactly that username (no

[bot]

)”, then realistically: - Best match: Option 1 (machine user + PAT) If “`openhands-reviewer[bot]` is acceptable”, then: - Best self-contained GHA approach: Option 3 (GitHub App) - Best security/product approach: Option 4 (Cloud mode) If you tell me which of those two identity requirements you mean (exact username vs bot identity OK), I can narrow this to the top 1–2 options and outline the concrete workflow changes needed (secrets, trigger allowlist changes like adding

openhands-reviewer

/

openhands-reviewer[bot]

, etc.).

The current PR review flow’s “reviewer identity” is entirely determined by which GitHub credential you use to call the GitHub API to create the review (i.e., whose token is in

GITHUB_TOKEN

when the action posts the review). ## What the current

pr-review

workflow does (today) In

software-agent-sdk

(and it’s essentially mirrored in

OpenHands

too): - Workflow:

.github/workflows/pr-review-by-openhands.yml

- Trigger:

pull_request

(opened / ready_for_review / labeled / review_requested) - Fork behavior: it skips forks (because

pull_request

runs don’t get secrets for forks) - Action: runs

.github/actions/pr-review@main

- Execution location: the agent runs inside GitHub Actions, and it checks out the PR repo and runs: -

examples/03_github_workflows/02_pr_review/agent_script.py

- GitHub write credential (identity): the workflow passes: -

github-token: ${{ secrets.ALLHANDS_BOT_GITHUB_PAT }}

so the resulting PR review is authored by whoever owns that PAT → currently

all-hands-bot

. If we want reviews to come from

openhands-reviewer

, the core question is: what auth mechanism produces that identity without wrecking security/UX. --- ## Alternatives (identity + where the agent runs), and how they compare ### Option 1) GitHub machine user

openhands-reviewer

+ PAT (closest to today) How it works - Create a GitHub user

openhands-reviewer

- Add it to the org/repo - Create a (fine-grained) PAT and store it as a secret - Pass that PAT as

github-token

Identity in PRs - Exactly

openhands-reviewer

(this is the only mainstream way to get exactly that, i.e. no

[bot]

suffix) Pros - Minimal code/workflow change (mostly secrets + maybe update the

review_requested

login allowlist) - Clean separation from

all-hands-bot

Cons - Long-lived PAT security/rotation burden - For external users adopting this, it’s annoying: they must create their own machine user + PAT Best for - OpenHands-internal repos where you control org secrets and just want the name change fast. --- ### Option 2) Use GitHub Actions’ built-in

GITHUB_TOKEN

(

github-actions[bot]

) How it works - Don’t use a PAT at all; use

${{ github.token }}

Identity in PRs -

github-actions[bot]

(not

openhands-reviewer

) Pros - No extra GitHub credential secret needed (for GitHub auth) - Easiest for OSS adopters Cons - Identity is wrong for your goal - Still constrained by event security model (forks, permissions, etc.) Best for - “Make it easy for anyone to try” workflows, when identity doesn’t matter. --- ### Option 3) GitHub App named

openhands-reviewer

(token minted inside Actions from App private key) How it works - Create a GitHub App

openhands-reviewer

- Install it on the repo/org - Store

APP_ID

+

PRIVATE_KEY

as secrets - In workflow, mint an installation token (e.g.,

actions/create-github-app-token@v1

) - Pass that token as

github-token

Identity in PRs -

openhands-reviewer[bot]

(GitHub Apps virtually always show with

[bot]

) Pros - Short-lived installation tokens (better than PATs) - Granular permissions and auditability - A scalable pattern for other orgs (they can create/install their own app) Cons - More setup complexity than PAT - Still requires a sensitive secret (private key) in GitHub secrets - If you require the display name to be exactly

openhands-reviewer

(no

[bot]

), this doesn’t satisfy it Best for - Better security posture than PAT while keeping “agent runs in Actions”. --- ### Option 4) “Cloud mode” (Issue #2082): run the agent in OpenHands Cloud, post via the existing Cloud GitHub App How it works - GitHub Action becomes a thin trigger: - send

{repo, pr_number, options}

to OpenHands Cloud - Cloud runs the agent (compute + LLM config) - Cloud posts the review using the already-installed OpenHands Cloud GitHub App installation token Identity in PRs

- The OpenHands Cloud App bot identity (not `all-hands-bot`; also not necessarily exactly

openhands-reviewer

) Pros - No PAT/App private key stored in the repo workflow - Better story for running on fork PRs (since Cloud can hold credentials safely) - Avoids “untrusted PR code runs next to powerful secrets” problems Cons - Yes: users effectively need an OpenHands Cloud account/API key (unless you add an OIDC-based trust flow) - Requires SaaS backend endpoints + reliability/SLA Best for - Product-grade experience, best security model, but couples to Cloud. --- ### Option 5) Hybrid: agent runs in GitHub Actions, but identity/auth is “brokered” by Cloud There are two meaningful sub-variants: 5a. Cloud returns a short-lived installation token to the workflow - Then the agent in GHA posts the review. - Downside: if PR code is untrusted in that job, token exfiltration is a risk. 5b. Cloud never returns GitHub tokens; Cloud posts the review - GHA sends “review output” (or PR metadata) to Cloud, Cloud posts. - This is effectively “Cloud mode”, just with some compute still in GHA. Identity in PRs - Cloud App bot identity Pros - Can reduce what secrets live in GitHub - Can keep some compute local if you really want Cons - More moving parts than pure GHA or pure Cloud - Still likely requires Cloud account unless you do OIDC trust --- ### Option 6) No GitHub Actions: a GitHub App / webhook integration triggers reviews How it works - GitHub App receives PR events (label, ready_for_review, etc.) - Triggers agent in Cloud (or self-hosted service) - Posts review Identity in PRs - App bot identity Pros - Cleanest GitHub-native integration - Avoids

pull_request

vs

pull_request_target

security footguns entirely Cons - Requires operating a service (Cloud or self-host) - More initial engineering --- ## Quick comparison table | Option | Where agent runs | Review author identity | Secrets in repo | Cloud account required | Notes | |---|---|---|---|---|---| | 1) Machine user + PAT | GitHub Actions |

openhands-reviewer

| PAT (+ LLM key) | No | Only way to get exact name (no

[bot]

) | | 2) Built-in

GITHUB_TOKEN

| GitHub Actions |

github-actions[bot]

| LLM key only | No | Easiest OSS adoption; identity doesn’t match | | 3) GitHub App | GitHub Actions |

openhands-reviewer[bot]

| App key (+ LLM key) | No | Better than PAT; identity has

[bot]

| | 4) Cloud mode (2082) | OpenHands Cloud | Cloud App bot | OpenHands API key only | Yes | Best security/UX if Cloud is acceptable | | 5) Hybrid cloud-brokered | Mixed | Cloud App bot | OpenHands API key (maybe) | Yes | Usually more complex than it’s worth | | 6) App webhooks → service | Cloud/self-host | App bot | none (in repo) | Depends | Most “product-grade”; needs service | --- ## The key decision point If “`openhands-reviewer` must be exactly that username (no

[bot]

)”, then realistically: - Best match: Option 1 (machine user + PAT) If “`openhands-reviewer[bot]` is acceptable”, then: - Best self-contained GHA approach: Option 3 (GitHub App) - Best security/product approach: Option 4 (Cloud mode) If you tell me which of those two identity requirements you mean (exact username vs bot identity OK), I can narrow this to the top 1–2 options and outline the concrete workflow changes needed (secrets, trigger allowlist changes like adding

openhands-reviewer

/

openhands-reviewer[bot]

, etc.).