Agent

GitHub

Connect an agent to GitHub and it works where your code lives: it reviews pull requests as they open, answers @mentions in PR and issue comments, and clones your repositories into its sandbox to check the things it says. Each agent gets its own GitHub App — owned by you or your organization — and everything it posts appears under that App's name and avatar.

Connect GitHub

01Open the agent's Surfaces area and expand GitHub.
02Name the GitHub App and enter the GitHub organization that should own it, or leave the organization empty to create it under your personal account.
03Click Create GitHub App and confirm the App on GitHub, then pick the repositories to install it on.

How the connection works

Every connection is a dedicated GitHub App created from a manifest Brainbase prepares — there are no keys or webhook URLs to copy by hand.

On the agent's Surfaces page, name the App. The name becomes the handle you mention on GitHub — Acme Reviewer becomes @acme-reviewer — so name it the way you want to call it.
Create GitHub App hands you to GitHub to confirm the App. It is created with the full set of permissions the agent can ever need — write access to repository contents, pull requests, issues, and checks, and read access to metadata. Contents write access sits unused until you turn on push access: the credentials minted for git are per-repository and read-only by default.
GitHub then drops you into the App's install screen to choose repositories. Repository access is managed entirely on GitHub — change it any time from the App's settings page.
Back in Brainbase, the GitHub card shows Connected with the App's handle, and the trigger toggles appear.

One agent, one App

Each App is bound to the agent whose Surfaces page created it. To put two agents on the same repositories, give each its own App — they review and chat independently, each under its own name.

Triggers

Toggles on the GitHub card choose which GitHub activity starts the agent.

Trigger	Fires when	Default
Auto-review pull requests	A pull request is opened or marked ready for review. The agent reviews it and posts a formal PR review.	On
Respond to @mentions	Someone mentions `@your-app` in a PR or issue comment, or in a reply on one of the agent's inline review comments. The agent answers in place.	On
Re-review on new commits	Commits are pushed to an open PR. Rapid pushes are batched for about a minute, then the agent re-reviews the delta once.	Off

The agent reacts with 👀 the moment it picks up an event, and delivers its answer back on the PR or issue.
Everything on one pull request is a single conversation — the first review, follow-up mentions, and re-reviews continue the same task with full context.
Actions performed by other bots never trigger the agent, so two bots cannot set each other off.
Every trigger becomes a normal agent run — watch it live and read the full trace in the agent's Tasks view.

Code reviews

A review lands as a formal GitHub pull request review — inline comments anchored to the changed lines, plus a summary body. What the agent looks for is up to its Instructions: coding standards, security posture, house rules, how strict to be.

Reviews can carry a merge-readiness score. When the review includes a line like Merge readiness: 4/5 (or the agent passes a score explicitly), the verdict is also posted as a Brainbase Review check run on the reviewed commit — green at 4/5 and above, neutral below, never a red failure.

Advisory by design

The agent's reviews are posted as comment reviews — if it ever tries to approve or request changes, the platform downgrades that to a comment — so a review never satisfies a required review and never blocks a merge. A human always owns the merge decision. If you do want the score to gate merges, make the Brainbase Review check required in your branch protection; that choice stays on your side.

To get another pass, mention the App on the PR and ask, or turn on re-review on new commits. Apps connected before check-run support rolled out need the App's new checks permission accepted once on GitHub before the check run appears — reviews themselves are unaffected.

Chat on pull requests and issues

Mention @your-app in any PR or issue comment and the agent replies there. In an inline review thread it answers inside the same thread; in the conversation tab it answers as a comment. Because the whole PR is one task, it remembers its own review and your earlier questions.

Coding harness required

GitHub work runs in the agent's sandbox, so the agent needs a coding harness such as Claude Code or Codex. On other harnesses the App replies asking you to switch instead of starting a run.

Working with the code

The agent is not limited to reading diffs over the API. Inside its sandbox, git clone https://github.com/your-org/your-repo simply works — credentials are minted on demand per repository, live for about an hour, and reach git through a credential helper — no tokens on disk, none pasted into URLs. The agent can build the project, run the tests, and verify a finding before it posts it.

Git access is read-only by default. The agent can clone and fetch any repository the App is installed on — and only those.
Turn on Push branches and open pull requests to let the agent push branches and open PRs of its own. Leave it off for review-only agents.
Apps connected before push access rolled out may need a one-time permission approval on GitHub before writes work.

Hiding other bots' comments

If other review bots run on the same repositories, their findings reach your agent as PR context and can anchor its judgment. The Hide other bots' comments toggle (off by default) makes the agent blind to them: other bots' comments and reviews — and the threads they started — are hidden, the summaries the major review bots write into PR descriptions are stripped, and API routes that would leak their output are closed off.

Anything posting as a GitHub App counts as a bot — review bots and CI bots alike.
Turn it on for an independent reviewer; leave it off when the agent should act on other bots' output, like fixing findings a CI bot reported.

Tools

Connecting GitHub automatically equips the agent with the brainbase_github tool server — there is nothing to add on the Tools page. The agent can:

Tool	What it does
`github_get_pull_request`	Read a PR's title, description, state, branches, and stats.
`github_get_pr_diff`	Read the PR's unified diff.
`github_list_pr_files`	List changed files with per-file patches.
`github_get_file_contents`	Read any file, at any branch or commit, in an installed repository.
`github_list_comments`	Read conversation and inline review comments.
`github_list_reviews`	Read a PR's review history.
`github_compare`	Compare any two refs: commits and file changes.
`github_create_review`	Post a formal review — summary, inline comments, optional merge-readiness score.
`github_create_issue_comment`	Comment on a PR or issue conversation.
`github_reply_to_review_comment`	Reply inside an inline review thread.
`github_update_comment`	Edit one of its own comments.
`github_add_reaction`	React to a PR, issue, or comment.
`github_create_branch`	Create a branch — requires Push branches and open pull requests.
`github_create_pull_request`	Open a pull request — requires Push branches and open pull requests.
`github_whoami`	Look up the App's own handle and identity.
`github_api_call`	Read-only escape hatch to the GitHub REST API for anything not covered above.

Disconnecting

Switching the GitHub card off (or clicking Disconnect) deactivates the connection: webhooks are ignored and the GitHub tools are detached from the agent. The App itself stays on GitHub — uninstall it from your GitHub settings to remove its repository access entirely, which also deactivates the Brainbase side automatically. Reinstalling the same App reconnects it.

Best practices

Name the App the way you want to mention it — the name becomes the handle.
Put your review policy in the agent's Instructions — what to prioritize, house rules, what earns a high merge-readiness score.
Keep push access off for review-only agents.
Turn on Hide other bots' comments when the agent reviews alongside other review bots.
Leave re-review on new commits off on busy repositories unless you want a run per push burst.
Read a few early runs end-to-end in Tasks to tune instructions before rolling the App out to more repositories.