Connect GitHub so OpenClaw can ship code

For the building side of what people do with an agent, GitHub is usually the first connection. Once your Operator.io agent has access, it can read your code, open and update pull requests, file and triage issues, and handle the routine repository chores you would rather not do by hand. There are two ways to connect it, a fine grained token or the official GitHub MCP server, and this covers both, plus what the agent can do once it is in.

What you get

The agent works against the GitHub REST API with your token, so it can do anything the API allows inside the scope you grant. It reaches first for a set of prebuilt actions: listing the repositories it can see, reading any file from them, committing a new or changed file, listing pull requests by state, and opening one from a branch into another. The same token unlocks the rest of the API too, so issues, labels, reviews, and releases are within reach when a task calls for them.

What makes this matter is that GitHub access does not sit on its own. OpenClaw can search the web for how a dependency changed, read the affected file in your repo, write the fix, and open the pull request in one pass, then drop the link in your channel for you to review. Because it keeps context between messages, you can follow up with "tighten the description" or "also bump the changelog" and it carries on from where it stopped.

GitHub recommends fine grained personal access tokens over classic tokens because you can limit each token to specific repositories and grant permissions on a read or read and write basis rather than handing over the broad repo scope. The permissions reference maps each REST endpoint to the permission it needs, which is useful when you want read only issue triage without write access to Contents.

It helps to picture what each grant actually opens. Contents read lets the agent read every file in the repositories you selected, and that includes anything checked in that should not have been, like an API key or a .env someone committed by accident. Contents write lets it commit, and on a repository with no branch protection a commit can land straight on your default branch.

Keeping that comfortable comes down to the controls GitHub already gives you. Select only the repositories the work touches, grant read only where the job is reading and triage, and protect your main branch so the agent's changes arrive as a pull request you merge rather than a push that is already live.

For the common jobs, opening pull requests and triaging issues, that comes down to a short set of permissions:

Option A: a fine grained personal access token

This is the most direct path and gives you tight control over what the agent can touch.

Mickey Gousset's introduction to fine grained tokens walks the same screen, showing how a token gets scoped to specific repositories and given read or write permissions one at a time.

1. On GitHub, click your profile picture, open Settings, then Developer settings, then Personal access tokens, and choose Fine-grained tokens.
2. Click Generate new token. Set a name and an expiration, and under Resource owner pick your account or organization.
3. Under Repository access, select only the repositories you want the agent to work in. Keeping this tight is good practice.
4. Under Permissions, grant what the work needs. For opening pull requests and triaging issues, that is Contents read and write, Pull requests read and write, and Issues read and write. Metadata read is included automatically.
5. Generate the token and copy it. GitHub shows it once.

If the repositories live in an organization that enforces SAML single sign on, you also need to authorize the token for that organization on the same page, or GitHub will hide those repos from it even when the permissions look correct. Organization owners can also require approval for fine grained tokens before they take effect.

Then add it to Operator: open Environment, add a variable named GITHUB_TOKEN, and paste the token. The GitHub skill is already installed and finds the token by name, so you are done as soon as you save. GitHub accepts the token in the Authorization: Bearer header on REST calls, which is what the skill uses.

Option B: the official GitHub MCP server

If you would rather connect through OAuth than manage a token, open the MCPs page in your Operator dashboard, find GitHub, and click Add. That runs you through GitHub's authorization in a popup and connects GitHub's official MCP server to OpenClaw. The MCP server exposes repository, issue, and pull request tools through the Model Context Protocol, refreshes its own access through OAuth, and spares you from rotating a token by hand. Pick whichever fits how you work, and you do not need both. The MCP route is better when you want GitHub to manage consent and token lifetime; the PAT route is better when you want explicit repository boundaries written into the token itself.

A first job

You talk to OpenClaw from Telegram or Discord, so connect one on the channels page first. Then give it something real but low stakes. Triage is a natural starting point, because it is read only and the output is easy to sanity check:

Look at the open issues on my-org/web, group them by theme, and tell me which three are worth doing first.

Once you trust how it reads the repo, let it close the loop on a small change:

There's a typo in the footer copy on the marketing repo. Fix it and open a pull request, then send me the link.

It reads the file, commits the corrected version, opens the pull request, and replies with the URL. You merge it, or tell it what to change and it pushes again.

Good to know

GitHub gives authenticated REST requests 5,000 calls an hour per user on github.com, far more than a normal day of agent work will spend, so rate limits are rarely what stops you. Fine grained tokens require an expiration, which means the token goes dead on the date you set and you will need to mint a new one, so leave yourself a reminder. Keep the permissions as narrow as the task allows, and use separate tokens for separate jobs so you can revoke one without disturbing the others.

If the agent reports that it cannot see a repository, the cause is almost always the token: either that repo was not selected when you created it, or the token was never authorized for the organization that owns it. If a specific API call fails with a permissions error, check the X-Accepted-GitHub-Permissions response header GitHub returns on failed requests; it lists the permission sets that would satisfy that endpoint, as described in GitHub's changelog on the header.

For public repositories only, a token with no repository permissions can still read public data, but any write action or access to private repos requires the explicit permissions above. Revoke a token anytime from Settings, Developer settings, Personal access tokens, and the agent loses access on the next call.