Give AI Your GitHub Repo: What Happens Next?

Getting access

Connecting a repo usually means granting an OAuth app or a bot account scoped permissions, at minimum read access, often write access to branches and pull requests, and sometimes access to CI logs and issues. It is worth checking exactly which scopes were granted, since connect-your-GitHub prompts are often broader than the task requires.

Once connected, most tools clone or fetch the repo into a sandboxed environment rather than operating on GitHub's API directly. That local checkout is what the agent actually reads and edits; changes are pushed back as commits or a pull request when the work is done.

What the agent does with the code

The agent typically builds some form of index over the repo, such as a file tree, a map of directories, sometimes embeddings for semantic search, so it can find relevant files without reading everything on every request. For a task, it searches that index, opens the files that look relevant, and starts iterating.

If the repo has a working test suite and clear build instructions, the agent will usually run them as it goes, using pass or fail signals to steer its own edits. A repo without tests or without a documented way to run them gives the agent much weaker feedback, and it shows in the quality of the result.

• Clone or check out into an isolated sandbox
• Index the file tree and search for relevant files per task
• Read, edit, and run tests or linters in a loop
• Commit changes and open a pull request for review

What you should check before connecting

Review the permission scope, confirm whether the sandbox has outbound network access, which matters for secrets and dependency installs, and check whether the tool respects a CODEOWNERS file or branch protection rules before it can merge anything.

It is also worth testing on a low-stakes repo first: watch how the agent behaves when it hits a failing test or an ambiguous instruction before trusting it anywhere near your main branch.