GitHub

Install the GitHub app

Workspace owners and admins connect GitHub, as a workspace connection.

1. In Settings, under Connections, choose New connection, then GitHub.
2. Tick what agents holding it may do, then choose Install the GitHub App.
3. On GitHub, choose the repositories Arbituro’s app can see, and install it.
4. Sign in to GitHub when asked, so Arbituro can confirm you can reach that installation.

• Finish within 15 minutes of starting.
• If your GitHub organisation requires an admin to approve new apps, Arbituro tells you, and an admin there has to approve it.
• An installation can belong to one Arbituro workspace.
• To change which repositories the app can see later, change them on GitHub.

Link repositories to a project

On a project’s settings page, under Repositories, workspace owners and admins add the repositories that project works in. The first one added is the default, and another can be made the default.

• Agents’ GitHub tools in the project reach its linked repositories.
• With none linked, an agent’s GitHub tools reach every repository the app can see.
• A repository can’t be removed while a job being worked expects its result there.

Link pull requests and issues

A job’s GitHub section appears once its project has a linked repository, or the job already has links. Choose Link a PR and paste the address of a pull request or an issue. Anyone who can change work in the project can link one.

Each linked pull request shows the state of its CI checks:

Checks passed

Every check succeeded.

Checks pending

A check is still running.

Checks failed

A check failed, timed out, was cancelled, or needs action.

Checks error

A check couldn’t start, or went stale.

Pull requests and issues an agent opens are linked to its job for you. Coding agents connected over MCP, such as Claude Code, can link the pull request they opened too. See Connect Claude. So can your own programs, such as a CI workflow, through the API. See Link a pull request.

Let CI decide criteria

An acceptance criterion can be decided by a named CI check. When a check of that name finishes on a pull request linked to the job, it settles the criterion: met when the check succeeds, and not met when it fails, times out or can’t start. Other outcomes change nothing, and a check never overrides a criterion a person waived.

Criteria decided by a check come from an agent’s suggestions. See Acceptance criteria.

What agents can do

With the GitHub connection shared with it, an agent can:

• read code, listing up to 200 files and reading about 12,000 characters at a time, and say which commit it read
• read pull requests with their checks, and issues
• comment on pull requests, and create and comment on issues
• propose code changes

Reading runs without asking. Comments, issues and code changes each wait for the connection’s owner, or someone they let approve, unless that kind of action was approved in advance.

Proposed code changes

An approved change goes to a new branch, opened as a draft pull request. It never writes to the branch it started from, and it is linked to the job.

• Up to 10 files in one change, text only, with up to 64 KB of changes in a file and 256 KB in all.
• Changes to an existing file quote the text they replace, from the commit the agent read.
• A change that adds anything that looks like a credential is refused.

Agents can never merge pull requests, close issues, or create branches or pull requests directly. Those stay with your team.