Guide to Giving AI Tools Access to GitHub

Connecting an AI app builder to GitHub usually takes a few clicks, and most people accept every screen without reading it. Those screens decide which repositories the tool can see, what it can change there, and whether it keeps that access long after you've stopped using it. For someone trying three builders in a week, that can mean three tools with access to every repository they own.

Most AI tools reach GitHub in two steps: you sign in with your GitHub account, and then you install the tool's GitHub App, choosing whether it gets all of your repositories or only selected ones. Each app also asks for specific permissions, like reading code or opening pull requests. Different tools do very different things with that access: some only push to a branch, others open pull requests, and a few can review them. GitHub's settings list every app with access, so you can narrow or remove it at any time.

The safest connection gives a tool only what it needs for the job. Narrow access limits how far a mistake can reach. Reviewing that access every few months, and removing tools you no longer use, keeps old connections from turning into open doors.

How AI tools get into a repository

Most AI tools reach a GitHub repository through two separate steps. Authorizing a tool lets it act on a user's behalf. Installing its GitHub App gives it access to specific repositories, with specific permissions. The two are independent: an app can be installed without being authorized, and authorized without being installed ^[1].

Builders usually walk through both in one sitting, which is why the screens blur together. When a connection fails, knowing which step went wrong is half the fix: a tool that was authorized but never installed on a repository can't work in it.

Older integrations use OAuth apps instead. They act only on behalf of a user and can't be limited to chosen repositories, which is one reason GitHub generally prefers GitHub Apps ^[2].

Installing a GitHub App

Installation happens on a GitHub page the tool sends its user to. If the app needs repository permissions, the page asks for a choice between All repositories and Only select repositories, lists the permissions the app requests, and ends with Install^[3].

Anyone can install apps on their personal account, while organization owners install them for an organization. A member without that right can still pick the organization, and GitHub sends the request to an owner.

Whatever repositories are chosen, an installed app always has at least read-only access to every public repository on GitHub. Public code is public to everyone, so the private repositories are the ones to choose carefully.

All repositories vs. selected repositories

The repository choice during installation decides how far a tool's access reaches. All repositories covers every repository the account has, including ones created later. Only select repositories limits the app to the ones picked, and the list can be changed at any time.

For an AI builder working on one project, selected repositories are almost always the better choice. If the tool misbehaves, or its account is ever compromised, the damage stays within the project it was meant to touch.

The cost is a small extra step when a new project needs the tool. Adding a repository to an app's list takes seconds, while cleaning up after a mistake in the wrong repository can take days.

GitHub App permissions

Each GitHub App requests specific permissions, like read access to metadata, read and write access to code, or access to issues and pull requests. They're listed during installation and again in settings afterwards ^[4].

GitHub Apps use fine-grained permissions, so a well-built app asks only for what it needs ^[5]. A tool that only reads files has no reason to ask for write access to workflows or administration.

Permissions that change how code runs or ships deserve the closest look. Write access to workflows, for example, lets an app change the automation that tests and deploys a project.

Reviewing and revoking app access

Every app with access is listed in settings. On a personal account, Installed GitHub Apps under Applications shows each one, and Configure opens its permissions and repository access ^[6]. Organization owners find the same list under Third-party Access.

From there, the repository list can be narrowed, or the app can be Suspended, which keeps it installed but blocks its access, or Uninstalled entirely. A separate tab, Authorized GitHub Apps, lets a user Revoke an app's permission to act on their behalf ^[7].

Tools tried once and forgotten are the ones worth removing. A review every few months, especially after testing several AI builders, keeps the list short and every remaining connection intentional.

AI tool capabilities on GitHub

AI tools that work with GitHub differ sharply in what they're allowed to do with a pull request, and those differences decide where human review has to happen.

For example:

• Copilot cloud agent opens draft pull requests but can't mark them ready, approve, or merge them ^[8]
• Copilot code review leaves comments by default and approves only when admins turn that on ^[9]
• Claude Code's GitHub Action pushes a branch and leaves opening the pull request to a person ^[10]
• v0 opens its own pull requests and merges them as part of publishing ^[11]

These rules change often, so a tool's documentation is the place to check before connecting it. The question to answer is simple: at which step does a person have to say yes?

Tasks to keep away from AI agents

GitHub's own guidance lists the kinds of work its cloud agent handles poorly ^[12]:

• Broad, complex tasks, like large refactors across repositories or work that needs deep domain knowledge
• Sensitive and critical tasks, like production incidents, security, personal data, or authentication
• Ambiguous tasks, where the goal itself isn't clear
• Learning tasks, where the point is for a person to understand the work

The good starting points are the opposite: bug fixes, small interface tweaks, documentation, test coverage, and accessibility improvements.

The list works as a filter for any AI tool, not just one. When a task falls into the sensitive or ambiguous groups, a person should lead, and the tool can assist.

Disconnecting an AI tool without losing work

Disconnecting an AI builder from GitHub can have consequences the button doesn't mention. Lovable's documentation, for example, notes that a project can't be reconnected after it's disconnected, and that renaming or deleting the connected account, organization, or repository breaks the sync ^[13].

Before disconnecting, it's worth making sure the latest work is committed on GitHub, so the repository holds a complete copy whatever happens to the connection. Users have reported losing a morning's work after reconnecting a builder that pulled in an older version of their project ^[14].

Once a tool is disconnected, its GitHub App can be uninstalled from settings, so the access ends along with the connection.