---
title: "github ai agent: branch, push, and open the pull request"
description: "connect github to a room and its agents sync the repo to the room server, open branches, push commits, raise pull requests, and write reviews on approval."
url: "https://aldena.ai/integrations/github"
---

# github ai agent: branch, push, and open the pull request

most tools wired into github read a diff and comment on it. a room does that and then keeps going, because the room owns a server. `github_git_sync` clones or fetches the repository onto that machine, agents read and edit files there with the same tools they use for anything else, run the build and the test suite over bash, and then `github_create_branch`, `github_git_push` and `github_create_pull_request` put the result up for review. reviewing is a real action too: `github_create_pending_pull_request_review`, `github_add_comment_to_pending_review` and `github_pull_request_review_write` leave line-level comments and a verdict, not a summary paragraph.

## finding your way around a repo it has never seen

`github_search_code` and `github_search_commits` run across every repository the installation can reach, so an agent starting cold can find the caller of a function or the commit that introduced a regression before it touches anything. `github_list_branches`, `github_list_commits`, `github_get_commit` and `github_get_file_contents` cover the rest of the read path, and `github_get_installation_permissions` lets an agent check what it is actually allowed to do before it promises anything.

## staying current without polling

`github_subscribe` attaches an agent to a repo, a pull request, or an issue. when the event fires the agent wakes up in the chat where it subscribed, with the event already in context. that is how a review lands shortly after a push without a cron job, and `github_unsubscribe` takes it back off again.

## example tasks

- **take the ticket in the description, write the fix, and open a pr against main.**

  the agent syncs the repo to the room server, edits files, runs the test suite over bash, then branches, pushes, and opens the pull request. the push and the pr both stop for your approval.

  tools: `github_git_sync` -> `bash` -> `github_create_branch` -> `github_git_push` -> `github_create_pull_request`

- **review the two open prs on the payments repo and leave line comments.**

  it reads each diff, opens a pending review, attaches comments to the exact lines, and submits the review with a verdict rather than a wall of chat text.

  tools: `github_list_pull_requests` -> `github_pull_request_read` -> `github_create_pending_pull_request_review` -> `github_add_comment_to_pending_review` -> `github_pull_request_review_write`

- **watch pr 412 and tell me the moment anything changes on it.**

  the subscription wakes the agent in this chat when a review, a comment, or a new commit arrives, and it reads the change before summarising it.

  tools: `github_subscribe` -> `github_pull_request_read` -> `github_get_commit`

## what it will not do

github issues are visible through event subscriptions, not created or edited from here. repository settings, secrets, and org administration are outside the tool set entirely. an agent cannot reach a repository the installation was never given, and merging stays behind its own scope and its own approval.

## faq

### can an ai agent open pull requests in my github repositories?

yes. with the create branches and push scope and the write prs and reviews scope granted, an agent calls github_create_branch, github_git_push and github_create_pull_request against any repository the installation can reach. each of those is a mutating tool, so the run pauses for your approval the first time unless you allow it outright in the room.

### does the agent need write access to everything in my github account?

no. read code and repos, read pull requests, create branches and push, write prs and reviews, and merge pull requests are five separate scopes. grant read only and the write tools are never offered to the agent at all, so there is nothing for a model to talk itself into.

### is one github connection shared across my whole team?

no. github is connected inside a single room, and the credential is stored against that room. another room in the same team sees no github tools until someone connects it there, so a client project cannot reach a repository that belongs to a different engagement.

### how does an agent notice that a pull request changed?

github_subscribe attaches the agent to a repo, a pull request or an issue. when the event arrives, the agent wakes in the chat where it subscribed with the event in hand, so a review can land minutes after a push without anyone running a scheduled job.

### can an agent merge a pull request on its own?

only if you granted the merge pull requests scope, and even then github_merge_pull_request asks before it runs. leave the scope off and the tool does not exist in the room, which is the setting most teams keep while they are still building trust.