CodeRabbit GitHub Integration: Complete Setup Guide for 2026

What you will learn

This guide walks through every step of integrating CodeRabbit with GitHub - from installing the GitHub App to configuring advanced review behavior with .coderabbit.yaml. By the end, you will have CodeRabbit automatically reviewing every pull request in your selected repositories, posting inline comments on code issues, and learning from your team’s feedback to improve over time.

Here is what this guide covers:

• Installing the CodeRabbit GitHub App and granting the correct permissions
• Selecting which repositories CodeRabbit should review
• Understanding the permissions CodeRabbit requests and why each one is needed
• Triggering your first automated PR review
• Customizing review behavior with .coderabbit.yaml including review profiles, path filters, and natural language instructions
• Advanced configuration for auto-review settings, monorepos, and integrations
• Troubleshooting common issues with the GitHub integration
• Alternative tools if CodeRabbit does not fit your workflow

If you are looking for a broader overview of CodeRabbit’s features and pricing before setting up the GitHub integration, start with our CodeRabbit review or CodeRabbit pricing breakdown.

Prerequisites

Before setting up the CodeRabbit GitHub integration, confirm you have the following:

• A GitHub account (personal or organization) with at least one repository
• Admin or owner permissions on the repositories where you want to install CodeRabbit - this is required to authorize GitHub Apps
• At least one open pull request or the ability to create one for testing the integration (optional but recommended)
• A modern web browser - the entire setup happens through the browser with no local tooling required

No CI/CD pipeline, Docker installation, API keys, or command-line tools are needed. CodeRabbit runs on its own infrastructure as a native GitHub App, which means it does not consume your GitHub Actions minutes or require workflow YAML files.

Step 1 - Install the CodeRabbit GitHub App

The GitHub App installation is the core of the CodeRabbit GitHub integration. This is what connects CodeRabbit’s AI review engine to your repositories and pull requests. Unlike tools that run as GitHub Actions, CodeRabbit operates as a standalone GitHub App - similar to how Slack, Jira, or Vercel integrate with GitHub.

Here is how to install it:

1. Open coderabbit.ai in your browser and click the “Get Started Free” button
2. Select GitHub as your Git platform
3. Authorize CodeRabbit using the standard GitHub OAuth screen - this grants CodeRabbit access to your identity so it can create your account
4. After landing on the CodeRabbit dashboard, click “Add Repositories” or “Install GitHub App”
5. GitHub will redirect you to the App installation page

The OAuth authorization in step 3 and the App installation in step 4 are two separate operations. The OAuth grants CodeRabbit access to your identity (who you are). The App installation grants it access to your repositories and pull requests (what it can read and comment on). Both are required for the integration to work.

If you are installing CodeRabbit for an organization rather than a personal account, you may need an organization owner to approve the installation. If you see a “Request” button instead of “Install,” the request will be sent to your organization owner for approval. Ask them to check the GitHub organization settings under Third-party access to approve the CodeRabbit app.

For a deeper walkthrough of the sign-up and account creation process, see our CodeRabbit setup guide.

Step 2 - Select repositories

During installation, GitHub asks you to choose which repositories CodeRabbit should have access to. You have two options:

• All repositories - CodeRabbit gets access to every repository in the organization or account, including any repositories created in the future. This is convenient for teams that want full coverage without manual configuration, but it means CodeRabbit will start reviewing PRs on every repository immediately.
• Only select repositories - You choose specific repositories from a searchable list. This is the recommended approach for teams that want to start with a pilot before expanding. You can always add more repositories later from your GitHub settings or the CodeRabbit dashboard.

For most teams, the best approach is to start with two or three active repositories that have regular pull request activity. This lets you evaluate the review quality, tune your .coderabbit.yaml configuration, and get team feedback before rolling CodeRabbit out more broadly.

After selecting your repositories, click “Install” to complete the installation. The CodeRabbit App now appears in your GitHub organization settings under Settings, then GitHub Apps (or in your personal account under Settings, then Applications, then Installed GitHub Apps).

Managing repositories after installation

You can change which repositories CodeRabbit has access to at any time:

• From GitHub: Go to your organization or account settings, navigate to GitHub Apps, find CodeRabbit, and click “Configure.” You can add or remove repositories from this screen.
• From CodeRabbit: Log in to app.coderabbit.ai and navigate to the “Repositories” tab. Toggle individual repositories on or off to control which ones CodeRabbit actively reviews.

The GitHub-level setting controls access (can CodeRabbit see the repository), while the CodeRabbit dashboard setting controls activation (should CodeRabbit review PRs on this repository). A repository must have both access and activation enabled for reviews to work.

Step 3 - Configure permissions

The CodeRabbit GitHub App requests a specific set of permissions during installation. Understanding what each permission does helps you evaluate whether the integration meets your security and compliance requirements.

Here are the permissions CodeRabbit requests and why each one is necessary:

Permission	Access level	Purpose
Repository contents	Read	Allows CodeRabbit to read the code diff and surrounding context in your repository to perform meaningful reviews
Repository metadata	Read	Lets CodeRabbit access basic repository information like the default branch name and repository settings
Pull requests	Read and Write	Read access lets CodeRabbit see PR details including title, description, and changed files. Write access lets it post review comments and review summaries
Checks	Write	Allows CodeRabbit to create check runs that appear in the PR status section showing review progress
Webhooks	Receive	CodeRabbit subscribes to pull request events (opened, updated, reopened) so it knows when to start a review

CodeRabbit does not request write access to your repository contents. It cannot push commits, create branches, modify files, or merge pull requests. The integration is strictly read-only for your code and write-only for review comments.

For organizations with strict security policies, CodeRabbit also offers SOC 2 Type II compliance on its Enterprise plan and provides data processing agreements. Code is processed in memory during review and is not stored permanently on CodeRabbit’s servers.

Step 4 - First PR review

Once the GitHub App is installed and repositories are selected, open a pull request to trigger your first CodeRabbit review. This is where you verify that the integration is working correctly.

1. Create a new branch in one of your enabled repositories
2. Make a meaningful code change - adding a new function, refactoring a method, or fixing a bug works well for testing
3. Push the branch and open a pull request targeting your default branch
4. Wait 1 to 5 minutes for CodeRabbit to complete its review

When the review finishes, CodeRabbit posts several elements on your pull request:

A walkthrough summary appears as the first comment on the PR. It describes what changed across all files, organized by file and purpose. This summary helps reviewers quickly understand the scope of the PR without reading every line of the diff.

Inline review comments appear directly on specific lines in the diff, just like comments from a human reviewer. Each comment describes the issue, explains why it matters, and often includes a suggested fix. On the Pro plan, these suggestions appear as GitHub suggested changes that you can commit with one click.

A review status indicator shows whether the review is complete and how many comments were generated. This appears in the PR’s checks section.

If CodeRabbit does not post any comments within 5 minutes, jump to the troubleshooting section below. Common causes include the PR being a draft, the repository not being activated in the CodeRabbit dashboard, or permission issues with the GitHub App installation.

Interacting with CodeRabbit comments

CodeRabbit comments are not one-way notifications - they are the start of a conversation. You can reply to any comment to ask for clarification, request an alternative approach, or explain why the suggestion does not apply to your codebase:

• Ask why: “Can you explain why this is a security risk? We validate this input in the middleware layer.”
• Request alternatives: “This approach would break our caching layer. What is another way to handle this?”
• Trigger actions: Comment @coderabbitai review on the PR to trigger a full re-review, or @coderabbitai resolve to dismiss a specific comment

Every interaction teaches CodeRabbit about your preferences. When you dismiss a comment with an explanation, CodeRabbit stores that as a learning and adjusts future reviews accordingly. Teams that actively reply during the first two weeks of adoption see significantly fewer false positives by the end of the first month.

Step 5 - Customize with .coderabbit.yaml

The .coderabbit.yaml file is where you tailor CodeRabbit’s GitHub integration to match your team’s workflow. While CodeRabbit works out of the box with sensible defaults, the configuration file gives you fine-grained control over what gets reviewed, how strictly, and with what focus areas.

Create a file named .coderabbit.yaml in the root of your repository and commit it to your default branch (usually main):

# .coderabbit.yaml
language: en-US

reviews:
  profile: chill
  request_changes_workflow: false
  high_level_summary: true
  poem: false
  review_status: true
  collapse_walkthrough: false
  sequence_diagrams: true
  changed_files_summary: true
  path_filters:
    - "!**/*.lock"
    - "!**/*.generated.*"
    - "!**/dist/**"
    - "!**/node_modules/**"
    - "!**/coverage/**"
    - "!**/__snapshots__/**"

chat:
  auto_reply: true

knowledge_base:
  opt_out: false
  learnings:
    scope: auto

CodeRabbit reads this configuration on every PR and applies your settings immediately - no restart, reinstallation, or dashboard change is required. Each repository can have its own .coderabbit.yaml with different settings, which is especially useful for organizations that have repositories with different languages, frameworks, or review standards.

Review profiles explained

The profile setting controls how verbose and strict CodeRabbit’s reviews are:

• chill - Focuses only on significant issues like bugs, security vulnerabilities, and logic errors. Produces fewer comments and is the best starting point for teams new to AI code review. Most teams find this strikes the right balance between catching real issues and avoiding noise.
• assertive - Reviews more comprehensively, covering style, naming, documentation, performance, and best practices in addition to bugs and security. Produces more comments and is best for teams that want thorough feedback on every PR.
• followup - Similar to assertive but also checks whether previous review comments were addressed in subsequent commits. This is the strictest mode and is best for teams that want to ensure review feedback is acted on.

Start with chill and switch to assertive after your team is comfortable with the tool - typically after two to four weeks.

Path filters for excluding files

The path_filters section controls which files CodeRabbit analyzes. Use negation patterns (prefixed with !) to exclude files that do not benefit from AI review:

reviews:
  path_filters:
    - "!**/*.lock"           # Package lock files
    - "!**/*.min.js"         # Minified JavaScript
    - "!**/dist/**"          # Build output
    - "!**/vendor/**"        # Vendored dependencies
    - "!**/*.generated.*"    # Auto-generated code
    - "!**/migrations/**"    # Database migrations (optional)
    - "!**/*.snap"           # Test snapshots

Excluding these files reduces noise and speeds up reviews because CodeRabbit does not spend time analyzing files where its feedback would not be actionable.

Advanced configuration

Once you have the basic .coderabbit.yaml working, these advanced settings let you get more value from the CodeRabbit GitHub integration.

Review instructions for specific paths

The path_instructions feature is one of CodeRabbit’s most powerful capabilities. It lets you provide natural language instructions that CodeRabbit follows when reviewing files matching specific patterns:

reviews:
  path_instructions:
    - path: "src/api/**"
      instructions: |
        Review all API endpoints for:
        - Input validation on all request parameters
        - Proper error handling with appropriate HTTP status codes
        - Authentication and authorization checks
        - Rate limiting considerations
    - path: "src/db/**"
      instructions: |
        Review database code for:
        - SQL injection prevention using parameterized queries
        - Proper connection handling and cleanup
        - Transaction usage for multi-step writes
    - path: "**/*.test.*"
      instructions: |
        For test files, focus on:
        - Edge case coverage
        - Proper assertion usage
        - Mock cleanup and test isolation

This means your API code gets reviewed for authentication gaps, your database code gets checked for SQL injection, and your tests get evaluated for missing edge cases - all automatically based on the file path.

Global review instructions

Add a top-level instructions field to guide CodeRabbit’s behavior across all files in the repository:

reviews:
  profile: assertive
  instructions: |
    This is a TypeScript backend service using Express and PostgreSQL.
    Our conventions:
    - All async functions must use try/catch with proper error logging
    - Database queries must use parameterized statements
    - API responses follow the format: { data, error, meta }
    - Do not comment on import ordering (handled by ESLint)
    - Do not comment on line length (handled by Prettier)
    - Focus on bugs, security issues, and logic errors

Global instructions are especially useful for preventing false positives. If your linter already handles import ordering and your formatter handles line length, telling CodeRabbit to skip those categories eliminates a common source of noise.

Auto-review settings

Control whether CodeRabbit reviews PRs automatically or only when requested:

reviews:
  auto_review:
    enabled: true
    drafts: false
    base_branches:
      - main
      - develop

Setting drafts: false means CodeRabbit skips draft PRs, which is the default behavior. The base_branches setting limits auto-review to PRs targeting specific branches - useful if you only want CodeRabbit to review PRs going into your main branches and not PRs between feature branches.

Path filters for monorepos

If your repository is a monorepo with multiple services, combine path instructions with path filters to apply different review criteria to each service:

reviews:
  path_instructions:
    - path: "services/auth/**"
      instructions: |
        Authentication service - focus on token validation,
        password hashing (bcrypt only), and OWASP compliance
    - path: "services/payments/**"
      instructions: |
        Payment service - focus on PCI DSS patterns,
        idempotency of operations, and decimal precision
    - path: "packages/shared/**"
      instructions: |
        Shared library - focus on backward compatibility,
        type safety, and performance implications

Each service gets reviewed with context-specific criteria, which dramatically improves review quality compared to generic instructions applied uniformly across a monorepo.

Integrating with issue trackers

CodeRabbit can read linked Jira or Linear issues to understand the context behind a PR. When it knows the ticket description and acceptance criteria, it can validate whether the code changes actually address the requirements:

integrations:
  jira:
    enabled: true
    project_keys:
      - "BACKEND"
      - "FRONTEND"
  linear:
    enabled: true

Troubleshooting the CodeRabbit GitHub integration

If the integration is not working as expected, work through these issues in order.

CodeRabbit is not reviewing PRs

1. Check the GitHub App installation. Go to your GitHub organization settings, then Applications, then Installed GitHub Apps. Verify that CodeRabbit is listed and has access to the repository. If you chose “Only select repositories” during installation, the repository might not be included.
2. Check repository activation. Log in to app.coderabbit.ai and verify that the repository is toggled on in the Repositories tab.
3. Check if the PR is a draft. CodeRabbit skips draft PRs by default. Mark the PR as ready for review, or add drafts: true under auto_review in your .coderabbit.yaml.
4. Check path filters. If your .coderabbit.yaml excludes all the paths that changed in the PR, CodeRabbit will have nothing to review.
5. Check rate limits. On the free tier, you are limited to 4 PR reviews per hour and 200 files per hour. If you have hit these limits, reviews are queued until capacity is available.
6. Check webhook delivery. In your GitHub repository settings, navigate to Webhooks and inspect recent deliveries for the CodeRabbit webhook. Failed deliveries indicate a connectivity issue.

YAML configuration is not taking effect

1. Verify the file name is exactly .coderabbit.yaml - not .coderabbit.yml and not coderabbit.yaml
2. Verify the file is in the repository root, not in a subdirectory
3. Verify the file is on the default branch (usually main), not on a feature branch
4. Validate the YAML syntax using an online YAML validator - indentation errors are the most common cause
5. Comment @coderabbitai review on a PR to force CodeRabbit to re-read the configuration

Permission errors

1. For personal accounts: Only the account owner can install GitHub Apps. Verify you own the account.
2. For organizations: App installations require organization owner approval. If you see “Request” instead of “Install,” the request is pending approval from your org owner.
3. For repositories with access restrictions: Some organizations use GitHub App policies to restrict which apps can access specific repositories. Check your organization settings under Third-party access.

Too many or irrelevant comments

1. Switch the review profile from assertive to chill
2. Add path filters to exclude generated files, lock files, and build artifacts
3. Add global instructions telling CodeRabbit what not to comment on
4. Reply to irrelevant comments with explanations - CodeRabbit learns from your feedback
5. Enable the knowledge base so CodeRabbit builds repository-specific context over time

Alternative tools for GitHub code review

If CodeRabbit does not fit your needs, several alternatives provide AI-powered code review for GitHub repositories.

CodeAnt AI ($24-40/user/month) is a Y Combinator-backed platform that combines AI PR reviews with SAST scanning, secret detection, IaC security, and DORA metrics in a single tool. The Basic plan at $24/user/month covers AI PR reviews with line-by-line feedback across 30+ languages. The Premium plan at $40/user/month adds security scanning, compliance reporting (SOC 2, HIPAA), and engineering dashboards. CodeAnt AI is a strong alternative for teams that want to consolidate multiple security and review tools into one platform rather than running CodeRabbit alongside separate SAST tools.

GitHub Copilot code review is built directly into the GitHub PR interface and requires no additional app installation for teams already on Copilot Business or Enterprise plans. It provides AI-powered review comments but offers less configuration depth than CodeRabbit - there is no equivalent to .coderabbit.yaml path instructions or review profiles.

PR-Agent by Qodo is an open-source option that runs as a GitHub Action. It gives you full control over the LLM provider and can be self-hosted for teams with strict data residency requirements. You pay for your own LLM API keys rather than a per-user subscription.

For a comprehensive comparison of all available options, see our guide on CodeRabbit alternatives. If you are specifically interested in using GitHub Actions for code review automation, our AI code review in GitHub Actions guide covers multiple tools with production-ready workflow configurations.

Conclusion

The CodeRabbit GitHub integration gives your team instant AI-powered code review on every pull request with a setup process that takes under 10 minutes. Install the GitHub App, select your repositories, open a PR, and CodeRabbit starts posting review comments - no CI/CD configuration, no workflow files, no API keys.

The real value comes from customization. A .coderabbit.yaml file with review instructions tailored to your codebase structure, coding conventions, and security requirements turns CodeRabbit from a generic code reviewer into a context-aware team member that knows your API routes need authentication checks and your database code needs parameterized queries.

Start with the chill review profile on one or two repositories. Let your team interact with CodeRabbit’s comments for two weeks. Then tune the configuration based on real feedback - add path instructions for your most critical directories, exclude files that generate noise, and expand to additional repositories as confidence grows.

For next steps, explore our CodeRabbit setup guide for additional onboarding tips, our CodeRabbit pricing guide to understand when it makes sense to upgrade from the free tier, and our AI code review in GitHub Actions guide to see how CodeRabbit fits alongside other tools in your review pipeline.