Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt

Use this file to discover all available pages before exploring further.

CodeRabbit works out of the box with sensible defaults, but configuration lets you customize reviews for your team’s specific needs. Choose from multiple configuration approaches based on your workflow preferences.

​
Configuration approaches

​
File-based

YAML file (recommended)

Version-controlled configuration committed to your repository

Central configuration

Organization-wide configuration from a dedicated repository

​
Web Interface-based

Repository settings

Configure individual repositories with specific needs

Organization settings

Apply the same configuration to all repositories in your organization
Create a .coderabbit.yaml file in your repository root for version-controlled configuration. This approach gives you the benefits of infrastructure-as-code: configuration changes go through code review, maintain history, and deploy with your application. Best for: Teams that prefer GitOps workflows and want configuration changes tracked in version control. See the configuration reference for all available options and sample configurations for language-specific recommendations.

​
Central configuration

Create a dedicated coderabbit repository in your organization with a .coderabbit.yaml file. This configuration automatically applies to any repository that doesn’t have its own settings, giving you organization-wide defaults with the flexibility of repository-specific overrides. Best for: Organizations wanting centralized configuration management without requiring individual repository setup. See Central configuration for setup instructions and platform support.

​
Repository settings

Use repository settings when different projects need different CodeRabbit configurations. Configure each repository individually through the web UI or with a local .coderabbit.yaml file. Best for: Organizations with diverse projects requiring specific review approaches. See Repository settings.

​
Organization settings

Use organization settings when you want consistent CodeRabbit behavior across all your repositories. Configure once in the web UI and all repositories inherit the same settings. The web interface offers three view modes: Concise for the most common settings, All Settings for full control, and YAML Editor for direct YAML editing. Concise and All Settings modes include a live Preview panel. Best for: Teams with standardized coding practices across projects. See Organization settings.

​
Understanding configuration priority

Configuration sources don’t merge by default. When you use multiple configuration methods, CodeRabbit follows a strict priority hierarchy:
PrioritySourceLocation
0 (Highest)Global overridesCodeRabbit UI - Organization Settings - Global Overrides
1Repository file.coderabbit.yaml in the repository
2Central repository.coderabbit.yaml in coderabbit repository
3Repository settingsCodeRabbit UI - Repository Settings
4Organization settingsCodeRabbit UI - Organization Settings
5 (Lowest)Default settingsCodeRabbit schema defaults
You can enable configuration inheritance to let CodeRabbit merge configuration from parent levels instead of using only the highest-priority source.
Example: If you set a custom timeout in organization settings and central configuration but have a local .coderabbit.yaml that doesn’t mention timeouts and configuration inheritance is disabled, CodeRabbit uses the default timeout value, not your organization or central configuration settings.

​
Global overrides

Global overrides let organization administrators enforce settings across every repository and PR review in the organization, regardless of what individual repositories configure in their .coderabbit.yaml files or repository-level UI settings. Best for: Enforcing compliance policies, mandatory review profiles, or required path instructions that no repository can opt out of.
Global overrides take precedence over all other configuration sources, including repository .coderabbit.yaml files. Use them for policies that must be enforced organization-wide (for example, compliance-driven review profiles or required path instructions) rather than for general defaults.

​
Who can configure global overrides

Only organization admins can view and edit global overrides.

​
How to set global overrides

  1. In the CodeRabbit UI, open your Organization Settings page.
  2. In the settings mode switcher, select Global Overrides.
  3. Edit the YAML using the same schema as .coderabbit.yaml (schema.v2.json). Only include the keys you want to enforce - leave everything else out.
  4. Save. The overrides take effect on subsequent PR reviews across the organization.
Example - enforce an assertive review profile and a required path instruction on every repository: 
# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
reviews:
  profile: assertive
  path_instructions:
    - path: "**/*.sql"
      instructions: "Flag any statements that drop or truncate tables."

​
Override behavior

Global overrides are applied on top of the fully-resolved configuration using these rules:
TypeBehavior
ObjectsMerged recursively - override properties replace matching properties at each nesting level
ArraysCombined by key - override entries take priority when keys match (e.g., matching path in path_instructions); unique entries from other sources are kept
ScalarsSimple override - the override value wins
Arrays in global overrides follow the same merge logic as configuration inheritance - entries are merged by a stable key (for example, path for path_instructions). Override entries take priority when keys match, while unique entries from other sources are kept.

​
Adaptive configuration

Besides manual configuration, CodeRabbit automatically builds learnings about your team’s review preferences based on your interactions with review comments over time. This creates a dynamic, self-improving configuration layer. Learnings capture patterns like:
  • Which types of suggestions your team typically accepts or rejects
  • Coding standards specific to your repositories
  • Review focus areas that matter most to your workflow

Learnings

How learnings work and how to manage them