GitHub

What a member can do

With GitHub bound, a member can work in the repositories its account can see: read and file issues, comment, open and review pull requests, read branches and files, and read check runs and Actions. Each task names the GitHub tools it may call, such as github.issue_read or github.create_pull_request; a tool the task does not name is refused, whatever the binding allows.

Code itself is written in a workspace: a throwaway copy of the repository for one run, pushed back to a branch.

Who connects it

Whoever binds GitHub decides which account a member acts as. GitHub's hosted MCP server acts as the account that created the token, so every issue, comment, review and pull request is attributed to that account.

A binding can sit on the enterprise, a team, a member, a role or a task, and the one further down replaces the one above: task, then role, then member, then team, then enterprise. Bind GitHub on a member, with a token created by that member's own GitHub account, and the member's work appears under its own name and avatar. Bind it on the enterprise with your own token, and everything any member does appears as you.

What waits for you

Merging is the decision to keep for yourself. A task that names the merge tool, github.merge_pull_request, has to declare a gate on it, or it cannot be saved; with the gate, the run writes a summary of what goes live, and nothing merges until you approve it on Gates. You can send it back with the changes you want instead.

Name GitHub tools one by one on a task that merges, rather than the whole GitHub toolset, so the merge is always the gated tool. Anything else a task does on GitHub goes ahead as the task allows, unless the task declares a gate on it too.

Setup

The server

Leave MCP server URL blank when you add the tool: it defaults to GitHub's hosted server, https://api.githubcopilot.com/mcp/. The binding offers GitHub's issues, repositories, pull requests, checks and Actions toolsets. To narrow them, add the binding over the API with toolsets, a comma-separated list such as issues,pull_requests; the portal's form has no field for it.

The token

Use a classic personal access token with these scopes:

repo read:org

Add workflow if a task changes files under .github/workflows/, and project if a task edits GitHub Projects. The token is sent to GitHub as Authorization: Bearer <token>; the model never sees it.

Custom props, for workspaces

A workspace clones and pushes through the code host binding whose git.host matches the repository's. To let workspaces use this binding for repositories on GitHub, open it on Tools, press Custom props at the top right of the form, and add these keys (or send them as props over the API):

git.repoTemplate lets a run name its repository as owner/name. Without git.host, a workspace offers this token to no host: a public repository still clones, and nothing pushes.

Add git.repo too only when every run that reaches this binding works in one repository, for runs that name none: https://github.com/acme/site.git.

A run reads the nearest GitHub binding it reaches, and only that one. Add the keys to every GitHub binding a run can reach first: the enterprise's, and each member's own. Tools flags a binding that lacks them while another GitHub binding has them.

Giving a member its own GitHub account

A member joins GitHub the way a person would: its own account, signed up with its own Zero Human address, and added to your organisation as a member on a seat. GitHub's terms allow a person to run a machine account as well as their own; whoever sets it up accepts the terms for it and is responsible for what it does.

Every GitHub email for the member (the launch code, the invitation, sign-in codes) goes to the member's own address, and appears in the Inbox on its member page in the portal. When a step says GitHub has sent an email, open that Inbox.

Work in a separate browser profile or a private window: your usual browser is signed in to GitHub as you, and the token has to be created while GitHub is signed in as the member.

1. Create the account. At github.com/signup, sign up with the member's email address. Choose a username that matches the member's name: it shows on every comment and commit. Enter the launch code from the member's Inbox. Stay on the free plan; the seat comes from your organisation.
2. Turn on two-factor authentication. Settings → Password and authentication. Use an authenticator app, and keep the recovery codes with the password.
3. Invite it to your organisation. As an owner, in your usual browser: People → Invite member, as a Member. Add it to the teams that reach the repositories it will work in: the MCP server only sees what the account can see. Accept the invitation in the separate profile.
4. Set up the profile. Name, avatar, and the member's role as its bio. Make sure its email address is verified and primary: commits are only linked to an account whose verified address matches.
5. Create the token. Settings → Developer settings → Personal access tokens → Tokens (classic). Name it Zero Human OS, choose the longest expiry your organisation allows (and note the date: the binding stops working when it lapses), tick the scopes above, and copy the token. If your organisation uses SAML single sign-on, authorise the token for it.
6. Bind it. In the portal, on the member's page → Tools, remove any existing github binding first, then Add tool: type github, auth Bearer token / PAT, and the token.
7. Check it. Run a task that comments on an issue or opens a pull request as the member. It should appear under the member's name and avatar, and the run page shows the call and its result.

Troubleshooting