All docs

GitHub work

Link project tasks to GitHub issues and pull requests, review checks and control merging.

Ophio isn’t released yet. These docs describe the development version; app downloads are not available.

Ophio’s GitHub workflow uses the GitHub account in Accounts on the selected computer. It needs no GitHub App, webhook or public computer address. It works with Git repositories whose origin is on github.com. Other Git hosts are not supported by this workflow.

Configure a project

Sign in to GitHub under Settings → Accounts first. Then open Settings → GitHub and choose the project. Changing its settings requires Manage access permission.

GitHub workflow has three choices:

ChoiceBehavior
OffThe default. Tasks do not post through the linked workflow.
DraftsThe agent opens and updates draft pull requests. You mark them ready and merge.
Through mergeThe agent can open a draft, respond to checks, mark it ready and merge when the rules permit. Available only where the account administers the repository.

Before autonomous merging, read Before it merges by itself. Keep Through merge accepts it for the displayed repository; Use Drafts switches back. Nothing merges until that choice is made. Choosing Through merge again or changing origin requires another warning decision.

For an unprotected default branch named main, Protect main can require changes through pull requests and passing checks, including for administrators. It requires no approving review. Existing checks and rules are preserved. Change protection later in GitHub’s repository settings.

Details

  • Branch prefix defaults to ophio/.
  • Open pull request limit defaults to five of the agent’s open pull requests. Opening more requires your decision.
  • Issues per finder run defaults to five and permits up to 20.
  • Label what the agent opens “agent” applies that label in repositories you own.
  • Fix what the finder files chooses By itself or Ask me first.
  • Check before merging is on by default. It runs a read-only Plan review by the finder, or otherwise the task’s agent, before merge or handoff.

In a new task’s review, open Where → GitHub, below Branch. Choose:

  • Not linked for no workflow posts.
  • New pull request to open a draft for the task’s branch.
  • Fix an issue to choose an issue by number or repository link.
  • Take over a pull request to continue an existing pull-request branch.
  • Stack on PR #12, for example, to put queued follow-up work on a new branch targeting that pull request.
  • Find issues, Triage, or Check a pull request for Plan work.

When the workflow is enabled, new coding Work defaults to a new pull request. Ask and Plan default to unlinked. Choose Claude Code or Codex explicitly.

Find with and Fix with select the finder and fixer. Those choices are remembered per project. Find, Triage and Check stay in Plan; their review does not allow switching them to Work. Finding issues reads without changing project files but can file findings on GitHub through the workflow. Triage sorts work and never starts it by itself.

You can also open Work → Issues and pull requests. An issue offers Start a task; a pull request offers Take it over or Check it. These open review before starting. Content from someone who cannot write to the repository begins in Plan and needs your approval before becoming Work.

Queued fixes and pull-request updates

Finder-created issues become separate queued fixes. Review Fix with, including its Launch flags: each fix keeps the chosen fixer’s permission policy rather than inheriting the finder’s read-only mode. Automatic start applies only to that finder’s own issues, with the queue unpaused and authorization still valid within one day. Other people’s issues never start automatically. Ask me first waits for your go-ahead.

For a linked pull request, Ophio sends failed checks, conflicts and review comments back to the agent. It holds for a person after five repair rounds or six hours without a commit.

The pre-merge review is not a GitHub approving review. A failure, unreadable or oversized change, stale checks or a newer unresolved task result can hold the merge. The latest relevant check and task control the hold. An origin change prevents an action against the wrong repository.

Review and merge from the phone

Open the pull-request chip in a task to see Checks, open review threads and the merge blocker. Fix failing checks and Address comments prepare follow-up work.

Mark ready and Squash and merge, or the repository’s allowed merge method, require task permission and phone confirmation. They check the expected current head and repository. A changed head is refused; refresh and review it again.

In Drafts mode you retain the ready-and-merge decision. Through merge allows the agent to make it under the selected workflow and repository rules. This is separate from native coding approval prompts.

Posting and safety limits

Workflow posts use your signed-in GitHub account and disclose the agent and model. Finder and fixer attribution is retained. On a repository you do not own, each post requests approval. Public-repository security findings are directed to private reporting rather than filed publicly.

The bridge controls workflow writes. Agent gh reads are allowed, while direct gh writes through that route are refused. Push controls reject force pushes, branch deletions, tags, pushes to another repository and pushes to the default branch.

These controls do not make untrusted repositories or unrestricted coding tasks safe. Review task permissions, account access and repository branch rules separately.

There is no per-project GitHub account choice, automatic work on other people’s issues, posting reviews on others’ pull requests, or shortcut to open a pull request from an unlinked finished task.