Put a named engineer on every pull request OpenHands opens, and decide up front which GitHub labels and mentions, Slack channels, Jira tickets, and automations can start a conversation. Install the GitHub app only on the repositories that need it, because it can write code, workflows, and pull requests wherever it is installed.
When you need this
- Engineers want to label issues for OpenHands and get pull requests back.
- You plan scheduled or event-driven runs that nobody watches live.
- Pull requests from OpenHands arrive with no clear owner.
Evaluation criteria
GitHub issues
Which issues start work on their own?
Look forRestrict who can apply the openhands label, because anyone with label access can start work. That label, or a comment that starts with @openhands, opens a conversation. OpenHands posts a progress link and a summary, and opens a pull request when it resolves the issue.
Pull requests
Who can steer OpenHands from a pull request?
Look forAdd both the source and the target repository to OpenHands. After that, an @openhands mention in a pull request comment asks a question or requests an update.
Automated review
How does the review workflow run, and who triggers it?
Look forOnly users with write access can trigger review, with the review-this label or a review request to openhands-agent. Store LLM_API_KEY as a GitHub Actions secret for the workflow. The docs tell the person who triggers it to read the pull request first and confirm it is safe to run. Put project rules in a review skill under .agents/skills.
Slack and Jira
Who installs the apps, and how does a request reach the right repository?
Look forA Slack admin installs OpenHands, and each user links their own OpenHands Cloud account. Jira Cloud connects through a service account. Name the repository in the ticket, then add the openhands label or an @openhands comment to request a pull request.
Automations
Which recurring work runs with nobody watching?
Look forEach scheduled automation runs in a fresh sandbox with its owner's model settings, secrets, and Git credentials, and saves the conversation for review. Check what the owner's account can reach before you schedule anything. Agent Canvas ships automations that turn issues into pull requests and review pull requests, plus repository and Slack monitors. Event-driven runs need a backend that GitHub or Slack can reach.
Ownership
Whose name is on each commit and pull request?
Look forSet a custom Git author so the requesting engineer is the primary author and OpenHands is co-author. Without that setting, commits are authored as openhands. The requesting engineer stays responsible for review.
Questions to ask vendors
- Who can apply the openhands label, and on which repositories?
- Which automations run on a schedule or an event, and who reviews each run?
- Has every Slack user linked an OpenHands Cloud account, and which repositories can those requests reach?
- Whose name appears on each OpenHands pull request?
Red flags
- The openhands label available on every repository with no owner for the results.
- A review workflow triggered on pull requests nobody has read.
- Automations posting to Slack through broad tokens stored as personal secrets.
- Pull requests authored as openhands with no human named in review.
Products in this piece
Sources
- Official documentation
- 11
- Public source
- 2
- OpenHands docs: GitHub integration
- OpenHands docs: GitLab integration
- OpenHands docs: Slack integration
- OpenHands docs: Jira Cloud integration
- OpenHands docs: PR review workflow
- OpenHands docs: Automations
- OpenHands docs: Pre-built automations
- OpenHands docs: Application settings
- OpenHands docs: Cloud API
- OpenHands docs: Enterprise vs. open source
- OpenHands docs: Use cases
- gnovak, GitHub issue #13007: the resolver opens a duplicate pull request (Feb 23, 2026)
- Tim-Pohlmann, GitHub issue #7888: resolver edits fail on copied line numbers (Apr 16, 2025)