Here’s the concise restatement of what I found: 1. Do we have a workflow that runs the agent from an

@ openhands-agent

tag on GitHub? ◦ No. In this repo, there is no workflow that installs or checks out

openhands-sdk

from a Git ref/tag named

openhands-agent

. ◦ The closest is

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

, which installs:

uv pip install --system "openhands-sdk @ git+<https://github.com/OpenHands/agent-sdk.git@main#subdirectory=openhands-sdk>"
       uv pip install --system "openhands-tools @ git+<https://github.com/OpenHands/agent-sdk.git@main#subdirectory=openhands-tools>"

i.e., from

@main

, not

@openhands-agent

. 2. How does the “PR Review by OpenHands” workflow work? File:

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

◦ Trigger / guard: ▪︎ Uses

pull_request_target

with

types: [labeled, review_requested]

. ▪︎ Only runs if:

github.event.label.name == 'review-this' ||
           github.event.requested_reviewer.login == 'openhands-agent'

So a maintainer must either add the

review-this

label or request

openhands-agent

as a reviewer. ◦ Steps (simplified): i. Checkout repos: •

OpenHands/agent-sdk

into

agent-sdk/

. • The PR’s head repo/branch into

pr-repo/

with

persist-credentials: false

. ii. Environment config: • Sets

LLM_MODEL

,

LLM_BASE_URL

, and PR metadata (

PR_NUMBER

,

PR_TITLE

, etc.). iii. Install tooling: • Python via

actions/setup-python@v6

. •

uv

via

astral-sh/setup-uv@v7

. •

gh

CLI via

apt-get

. • Installs

openhands-sdk

and

openhands-tools

from

agent-sdk.git@main

. iv. Check config: • Verifies

LLM_API_KEY

is set and prints some context. v. Run the agent script: •

cd pr-repo

•

uv run python ../agent-sdk/examples/03_github_workflows/02_pr_review/agent_script.py

• That script uses the SDK to analyze the PR and post a review using the LLM and GitHub APIs. vi. Upload logs as artifacts. ◦ Other workflows (

integration-runner.yml

,

run-examples.yml

) use the SDK but don’t pin to any

@openhands-agent

tag either; they rely on the local repo via

uv sync

or use the SDK from

main

. 3. Who is the author of commits and PRs created by this workflow (if any)? The YAML itself doesn’t show explicit

git commit

/

git push

or

gh pr create

, but if the underlying agent script or SDK does create commits/PRs using the provided token, the identities resolve as follows: ◦ Token used:

env:
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

plus

LLM_API_KEY

for LLM access. ◦ Commits: ▪︎ Any

git push

done with

GITHUB_TOKEN

will be pushed under the identity of the GitHub Actions / GitHub App that owns that token. ▪︎ On GitHub, this typically appears as a bot account, e.g.: •

github-actions[bot]

or •

openhands-agent[bot]

if the workflow is using that app’s installation token. ▪︎ The actual

author

/

committer

fields in the commit can be set by the script via

git config

, but the pusher and visible “who did this” in the UI is the bot/app identity. ◦ Pull requests: ▪︎ If the agent opens a new PR via the GitHub API using

GITHUB_TOKEN

, the PR’s author will be that same bot/app account (e.g.

openhands-agent[bot]

), because that’s the authenticated user behind the token. So, in summary: • There is *no workflow using an

@ openhands-agent

Git tag*; they use

@main

. • The PR-review workflow runs the agent “headless” via

examples/03_github_workflows/02_pr_review/agent_script.py

, installed from

OpenHands/agent-sdk.git@main

. • If that agent creates commits or PRs, they will be authored/pushed and opened under the GitHub App / bot account behind

GITHUB_TOKEN

(likely

openhands-agent[bot]

), not a human user. _{View full conversation}

Here’s the restated answer, focused on your follow‑up: 1. When you say “tag” you mean a GitHub mention in a comment like

@openhands-agent

, not a Git ref. The workflow can be triggered based on that (via review request / label), and the agent script could then inspect the comment and infer who mentioned it. 2. Inside that workflow, the agent can set both the commit author and committer via

git config

and/or env vars: ◦

git config user.name "Some Name"

◦

git config user.email "<mailto:some-email@example.com|some-email@example.com>"

◦ Optionally override just the author (

git commit --author=...

) or just the committer (

GIT_COMMITTER_*

). So yes: the script could pick up the GitHub username (and some email) of the person who wrote the

@openhands-agent

comment and set both author and committer to that identity. 3. How that shows up in GitHub’s UI: ◦ GitHub decides which avatar/name to show for Author and Committer based purely on the email addresses in the commit. ◦ If the email you set in

git config

belongs to a real GitHub user, the commit will look like it was authored (and, if committer matches, committed) by that user. ◦ The actual pusher/actor is still the GitHub Actions bot / GitHub App whose token (

GITHUB_TOKEN

or app token) performed

git push

. That isn’t prominently shown in the normal UI; it’s visible in audit / event data, but not the main commit list. So, technically: • Yes, the agent can forge both author and committer using

git config

based on who wrote

@openhands-agent

. • In the GitHub interface, the commit will then appear as if it was authored (and committed) by that user, even though it was actually created and pushed by the automation account behind the workflow. _{View full conversation}

Here’s the restated answer focused on your latest question about PRs: • Even if the agent forges the commit author and committer to match a human user (via

git config

or

--author

), the PR author in GitHub’s UI is determined solely by which GitHub identity is authenticated when the PR is created, not by the commit metadata. Concretely, for the four ways a PR could be opened: 1. Using

gh

(GitHub CLI) ◦

gh

authenticates with

GH_TOKEN

. ◦ The PR will be “opened by” the user/app that owns

GH_TOKEN

(e.g.

openhands-agent[bot]

), regardless of who the commits say they are authored/committed by. 2. Using the GitHub REST/GraphQL API directly ◦ The API call uses

Authorization: token

<some-token>. ◦ The PR author is the account behind that token (again, usually the bot/app in CI), independent of commit author/committer. 3. Using a custom tool like the OpenHands MCP route you linked ◦ That tool ultimately calls the GitHub API using some stored token (typically a GitHub App / bot token). ◦ The PR will be authored by that app/bot in the UI, even if all commits list the human as author/committer. 4. Using another MCP tool (e.g., GitHub’s own MCP) ◦ Same rule: whatever identity the MCP is authenticated as (GitHub App, bot, or user via OAuth) is the PR author. ◦ Commit metadata doesn’t change that. So, summary: you can make the commits look like they were made by the user (both author and committer), but unless the PR itself is created with that user’s own token, the PR will still show “opened by” the bot/app account the agent is running under. _{View full conversation}