[codex] Add OpenHands PR review bot

[Fieldnote-Echo]

Summary

• add an OpenHands PR review workflow using the official per-repo GitHub Actions plugin path
• pin OpenHands/extensions/plugins/pr-review and the plugin's extensions-version to the same OpenHands/extensions commit
• add an ordvec-specific OpenHands code-review guide
• create the review-this label for explicit maintainer-triggered review

Trigger Model

This is the GitHub Actions based OpenHands reviewer. It runs the OpenHands agent in Actions with LLM_API_KEY and posts PR review comments through GITHUB_TOKEN.

The workflow is label-only for security:

• it listens only for pull_request_target: labeled
• the job runs only when the label is exactly review-this
• there is no automatic run on PR open, draft-to-ready, synchronize, or reviewer request

This keeps the pull_request_target + secret path behind explicit maintainer intent. To request a review, apply the review-this label.

Token Scope

The job grants only:

• contents: read
• pull-requests: write

issues: write was intentionally omitted; the pinned plugin path uses PR review APIs for review submission.

Setup

The repo secret is present:

• LLM_API_KEY

Model selection is controlled by repository variables:

• OPENHANDS_LLM_MODEL is currently set to litellm_proxy/minimax-m2.7; if unset, the workflow falls back to anthropic/claude-sonnet-4-5-20250929.
• OPENHANDS_LLM_BASE_URL is optional and should point at the LiteLLM proxy/custom provider endpoint when the selected model requires one.

Verification

• actionlint -color .github/workflows/openhands-pr-review.yml
• actionlint -color
• zizmor --offline --persona=regular .github/workflows/openhands-pr-review.yml
• zizmor --offline --persona=regular .github/workflows/
• bash tests/release_publish_invariants.sh
• python3 tests/release_publish_invariants.py
• git diff --check

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[qodo-code-review]

PR Summary by Qodo

Add OpenHands PR review workflow and ordvec review guide
✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

Description

• Add a GitHub Actions workflow to run OpenHands PR reviews and post review comments.
• Gate execution via PR state/labels/reviewer requests and pin the PR-review plugin to a fixed
 commit.
• Add ordvec-specific OpenHands code review guidance for /codereview-triggered reviews.

Diagram

graph TD
  A["PR event (opened/labeled/etc)"] --> B["GA workflow: OpenHands PR Review"] --> E[("Repo secrets/vars")] --> C["OpenHands PR-review action"] --> D["GitHub PR review comments"]
  C --> F["LLM provider/API"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use pull_request + workflow_run (avoid pull_request_target)

• ➕ Reduces risk of secrets exposure from untrusted forked PR contexts
• ➕ Simplifies threat model (no base-repo privileged context on PR events)
• ➖ Harder to post review comments directly with sufficient permissions
• ➖ May require additional indirection (e.g., workflow_run) and careful artifact passing

2. Manual workflow_dispatch only (no automatic triggers)

• ➕ Strongest safety posture; reviewers explicitly opt-in per run
• ➕ Eliminates label/reviewer-gating complexity
• ➖ More friction; reduced adoption/coverage for routine PRs
• ➖ Harder to keep reviews timely without automation

3. GitHub App/Checks-based integration instead of Actions secrets

• ➕ Fine-grained permissions and stronger isolation for posting feedback
• ➕ Centralized key management outside repo secrets
• ➖ More operational overhead to build/host and maintain the app/service
• ➖ Longer time-to-deliver than the action-based approach

Recommendation: The current approach is reasonable given the need to comment on PRs (which often pushes teams to pull_request_target), and it mitigates risk by gating triggers (non-draft open, ready_for_review, explicit label, or explicit reviewer request) and pinning third-party actions. Reviewers should still scrutinize the pull_request_target threat model (especially around what code gets executed and when secrets are exposed) and ensure the gating conditions match the intended policy.

Files changed (2) +83 / -0

Documentation (1) +29 / -0

custom-codereview-guide.mdAdd ordvec-specific OpenHands code review guidance skill +29/-0

Add ordvec-specific OpenHands code review guidance skill

• Introduces a custom OpenHands skill file that provides repo-specific review priorities and security/correctness checks. Emphasizes release invariants, malformed input handling, and least-privilege CI/release scrutiny for agent-authored changes.

.agents/skills/custom-codereview-guide.md

Other (1) +54 / -0

openhands-pr-review.ymlAdd pinned OpenHands PR review GitHub Actions workflow with gated triggers +54/-0

Add pinned OpenHands PR review GitHub Actions workflow with gated triggers

• Adds a pull_request_target workflow that runs OpenHands PR review on specific PR events (non-draft open, ready_for_review, review-this label, or openhands-agent review request). Pins the OpenHands PR-review plugin and harden-runner action, validates LLM_API_KEY presence, and passes model/base URL via repository variables.

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

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Secrets on auto PR review ✓ Resolved 🐞 Bug ⛨ Security

Description

The pull_request_target workflow runs automatically on opened/ready_for_review for non-draft
PRs while passing LLM_API_KEY and GITHUB_TOKEN into a third-party, LLM-driven action, creating a
secrets-available execution path on PR open rather than only on explicit maintainer-triggered gates.
This significantly increases the risk that untrusted PR content can influence an agent that has
access to sensitive credentials (prompt-injection / action misuse surface).

Code

.github/workflows/openhands-pr-review.yml[R19-54]

+    if: |
+      (github.event.action == 'opened' && github.event.pull_request.draft == false) ||
+      github.event.action == 'ready_for_review' ||
+      (github.event.action == 'labeled' && github.event.label.name == 'review-this') ||
+      (github.event.action == 'review_requested' && github.event.requested_reviewer.login == 'openhands-agent')
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+    permissions:
+      contents: read
+      pull-requests: write
+      issues: write
+    steps:
+      - uses: step-security/harden-runner@9af89fc71515a100421586dfdb3dc9c984fbf411 # v2.19.4
+        with:
+          egress-policy: audit
+
+      - name: Check OpenHands API key
+        env:
+          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
+        run: |
+          if [ -z "${LLM_API_KEY}" ]; then
+            echo "::error::Set the LLM_API_KEY repository secret before triggering OpenHands review."
+            exit 1
+          fi
+
+      # Keep both the action ref and the extensions checkout ref pinned to the
+      # same reviewed OpenHands/extensions commit. The plugin itself performs
+      # the PR checkout with persist-credentials disabled.
+      - name: Run OpenHands PR review
+        uses: OpenHands/extensions/plugins/pr-review@bb34a76d5230ba287cda4ea2883b5d008111575c
+        with:
+          extensions-version: bb34a76d5230ba287cda4ea2883b5d008111575c
+          llm-model: ${{ vars.OPENHANDS_LLM_MODEL || 'anthropic/claude-sonnet-4-5-20250929' }}
+          llm-base-url: ${{ vars.OPENHANDS_LLM_BASE_URL }}
+          llm-api-key: ${{ secrets.LLM_API_KEY }}
+          github-token: ${{ secrets.GITHUB_TOKEN }}

Relevance

⭐⭐⭐ High

Repo hardens workflows against dangerous triggers/secrets exposure; PR177 explicitly rejects
pull_request_target in sensitive publishing contexts.

PR-#177

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow is triggered via pull_request_target for opened and the job condition explicitly
enables non-draft PR opens, while secrets are injected and passed into the OpenHands action as
inputs.

.github/workflows/openhands-pr-review.yml[5-7]
.github/workflows/openhands-pr-review.yml[19-23]
.github/workflows/openhands-pr-review.yml[35-42]
.github/workflows/openhands-pr-review.yml[47-54]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`.github/workflows/openhands-pr-review.yml` runs on `pull_request_target` and currently allows automatic execution on `opened` (non-draft) and `ready_for_review`, while supplying `LLM_API_KEY` (and a write-capable `GITHUB_TOKEN`) to a third-party, LLM-driven action. This creates a secrets-available run path on PR open, not just on explicit maintainer intent.

### Issue Context
This workflow is explicitly designed to post review comments, so it uses `pull_request_target` and grants write permissions; that combination is high-risk unless execution is tightly gated.

### Fix Focus Areas
- .github/workflows/openhands-pr-review.yml[5-7]
- .github/workflows/openhands-pr-review.yml[19-23]
- .github/workflows/openhands-pr-review.yml[35-54]

### What to change
- Remove the automatic triggers from the job gate (or from `on.pull_request_target.types`) so secrets are only used on explicit maintainer actions, e.g.:
 - keep only `(labeled && label == 'review-this')` and/or `(review_requested && requested_reviewer == 'openhands-agent')`, and
 - drop `opened` / `ready_for_review` from the `if:` (or from the workflow `types`).
- If you intentionally want auto-review on open, add a strong trust gate before secrets are used, e.g.:
 - require `github.event.pull_request.head.repo.full_name == github.repository` (no forks), and/or
 - require `github.event.pull_request.author_association` in `OWNER|MEMBER|COLLABORATOR`.
- Consider tightening networking (egress) if supported, since `egress-policy: audit` does not prevent exfiltration.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. LLM job token too broad ✓ Resolved 🐞 Bug ⛨ Security

Description

The OpenHands job grants issues: write in addition to pull-requests: write, expanding the
capabilities of an LLM-driven action beyond what is clearly required for PR review. This increases
the blast radius if the agent is prompt-injected or malfunctions while using the provided
github-token.

Code

.github/workflows/openhands-pr-review.yml[R26-29]

+    permissions:
+      contents: read
+      pull-requests: write
+      issues: write

Relevance

⭐⭐⭐ High

Team repeatedly accepts least-privilege permissions tightening in workflows; broad job tokens are
routinely reduced/scoped.

PR-#50
PR-#54
PR-#177

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The job explicitly grants issues: write and passes an authenticated token into the OpenHands
action. Other workflows in this repo commonly keep permissions to contents: read, highlighting
that this job is materially more privileged.

.github/workflows/openhands-pr-review.yml[26-29]
.github/workflows/openhands-pr-review.yml[47-54]
.github/workflows/ci.yml[23-25]
.github/workflows/audit.yml[21-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The OpenHands workflow grants `issues: write` at job scope while also giving the action an authenticated `github-token`. For an LLM-driven agent, extra write scopes increase potential damage from prompt injection or unintended behavior.

### Issue Context
Some PR-comment APIs are implemented through the Issues API, so `issues: write` may be required depending on the plugin implementation. However, it should be justified and minimized.

### Fix Focus Areas
- .github/workflows/openhands-pr-review.yml[26-29]
- .github/workflows/openhands-pr-review.yml[47-54]

### What to change
- Verify whether the OpenHands PR review action actually requires `issues: write`.
- If not required, remove `issues: write`.
- If it is required, document why (e.g., “uses Issues API to comment on PRs”) and consider reducing other permissions or splitting into separate jobs with narrower scopes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[Fieldnote-Echo]

Codex (@codex) review

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.