--- title: "GitHub" description: "Let a playbook read repositories, files and commits, and read, open and update issues and pull requests on GitHub, by sign-in or a fine-grained token." url: "https://on.auto/integrations/github" last_updated: "2026-11-10T08:17:42Z" --- # GitHub Read repositories, files and commits, and read, open and update issues and pull requests. A GitHub connection gives a playbook's functions GitHub's MCP server, with its context, repositories, issues, pull requests and users toolsets. Connect by signing in to GitHub, and the connection acts as you across the repositories you allow; or give a fine-grained personal access token, and it acts with exactly the repositories and permissions the token names. Available on Auto Cloud and on self-hosted runtimes. * * * ## What a playbook can do with GitHub * Read repositories, their files at a ref, and their commits. * Read, search, open and update issues and their comments. * Read, open and update pull requests, their comments and their reviews. * Look up users and organization membership. What a function may change is what the connection allows. A token with **Contents** read-only, as the steps below make it, changes no file in a repository; a sign-in grants GitHub's wider `repo` scope. GitHub's MCP server lists its own tools when a function runs, and once you connect, your agent lists them with `list_connection_tools`. * * * ## An example workflow Release notes every Friday. A schedule trigger starts the workflow at 16:00. A lookup function lists the pull requests merged into `main` since the last run, through the server's pull request tools. A reasoning function reads each one's title, description and labels, groups them into features, fixes and internal changes in the team's own voice, and leaves out what the labels say is internal. An interaction function opens an issue titled with the week's date and the draft in its body, assigns it to the release manager and waits for a comment that says "ship" or asks for a change, reading the issue's comments. Once approved, the workflow records the final text as its result, where the person who publishes the notes copies it from Studio. * * * ## How to connect GitHub * **Sign in to GitHub and allow access to your repositories.** The consent screen shows the permissions listed below. * **Give a GitHub fine-grained personal access token.** Make a token at [GitHub](https://github.com/settings/personal-access-tokens/new), under **Settings**, **Developer settings**, **Personal access tokens**, **Fine-grained tokens**. As **Resource owner**, choose the account or organization that owns the repositories, and under **Repository access** select the repositories your functions use. Under **Permissions**, give **Contents** read-only access, and **Issues** and **Pull requests** read and write access. An organization that requires approval keeps the token pending, reading public resources alone, until an organization administrator approves it. The token starts with `github_pat_`. Then: 1. Ask your agent to connect GitHub to Auto, or open **Settings**, **Agents**, **Connections** in [Auto Studio](https://studio.on.auto/) and choose GitHub. 2. On the Studio page, check the service and its access, choose which playbooks may use the connection, and approve it. Give a key or a client secret there, never in a conversation with your agent. 3. Have your agent check one small read through the connection before a function depends on it. * * * ## What it needs * A GitHub account with access to the repositories, or a fine-grained token made by someone who has it. A token scoped to the few repositories a playbook needs is the narrower grant. * Your agent connected to Auto and signed in as you, with permission to change your organization, if your agent adds the connection. * An organization that requires token approval needs an administrator to approve the token before it reads private repositories. GitHub's sign-in grants `repo` as one scope, which reaches every repository you can. A fine-grained token with **Contents** read-only and **Issues** and **Pull requests** read and write is the least a playbook needs, and the way to give it that and nothing more. ### Permissions Auto asks for By sign-in: * Read organization membership, organization projects and team membership. * Manage all repositories with collaborators, invitations and webhooks, and organization projects and team memberships. With a key: a key carries the permissions it was made with; the steps above name those Auto needs. * * * ## Good to know What a function reads from GitHub, a file's content or an issue's thread, is kept in the run's history, where people with access to the playbook can read it. Choose the repositories a token reaches with that in mind. On a self-hosted runtime where no GitHub client is registered, an agent that adds GitHub by name is offered the token. * * * [All integrations](https://on.auto/integrations/) · [Linear](https://on.auto/integrations/linear) · [Jira and Confluence (Atlassian)](https://on.auto/integrations/atlassian) · [Slack](https://on.auto/integrations/slack) · [Bring in business data](https://on.auto/docs/cloud/connections) · [Give a function tools](https://on.auto/docs/guides/tools) · [Pricing](https://on.auto/pricing) · [GitHub documentation](https://docs.github.com/en/copilot/how-tos/copilot-in-your-ide/customize-copilot/extend-copilot-with-tools-and-context/set-up-the-github-mcp-server) ## Sitemap See the [full documentation and product sitemap](https://on.auto/sitemap.md) for related pages.