Configuration overview

Configure CodeRabbit to fit your organization and repositories using multiple approaches with clear priority rules.

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

YAML file (recommended)

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 sample configurations for language-specific recommendations and configuration reference for all available options.

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:

Priority	Source	Location
0 (Highest)	Workspace global overrides	CodeRabbit UI - Workspace Settings - Global Overrides (Enterprise workspace customers)
1	Organization global overrides	CodeRabbit UI - Organization Settings - Global Overrides
2	Repository file	.coderabbit.yaml in the repository
3	Central repository	.coderabbit.yaml in coderabbit repository
4	Repository settings	CodeRabbit UI - Repository Settings
5	Organization settings	CodeRabbit UI - Organization Settings
6	Workspace settings	CodeRabbit UI - Workspace Settings (Enterprise workspace customers)
7 (Lowest)	Default settings	CodeRabbit 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 is disabled, CodeRabbit uses the default timeout value, not your organization or central configuration settings.

To see exactly which layer each setting came from, run @coderabbitai configuration on any pull request. The resolved YAML is annotated with sources (repository YAML, central configuration, UI settings, defaults, etc.) so you can diagnose priority conflicts without guessing.

Global overrides

Global overrides let administrators enforce settings across every repository and PR review, 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 across a workspace or organization (for example, compliance-driven review profiles or required path instructions) rather than for general defaults.

Enterprise workspace admins can also configure workspace-level global overrides. These are applied after organization global overrides and take precedence when both levels set the same key.

If a setting is not behaving as expected, run @coderabbitai configuration on any pull request. The resolved YAML is annotated with the source that supplied each value, making it easy to identify when a global override is silently winning above your repository or organization configuration. Possible sources are:

• Repository YAML — .coderabbit.yaml in the repository
• Central YAML — .coderabbit.yaml in the coderabbit repository
• Environment YAML — YAML_CONFIG environment variable (self-hosted only)
• Repository UI — CodeRabbit UI repository settings
• Organization UI — CodeRabbit UI organization settings
• Workspace UI — CodeRabbit UI workspace settings (enterprise only)
• Defaults — CodeRabbit schema defaults
• Global overrides — organization or workspace overrides (enterprise only)

Who can configure global overrides

Workspace admins can view and edit workspace global overrides. Organization admins can view and edit organization global overrides.

How to set global overrides

1. In the CodeRabbit UI, open Workspace Settings or 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 workspace or organization.

Example - enforce an assertive review profile and a required path instruction on every repository:

.coderabbit.yaml

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:

Type	Behavior
Objects	Merged recursively - override properties replace matching properties at each nesting level
Arrays	Combined by key - override entries take priority when keys match (e.g., matching path in path_instructions); unique entries from other sources are kept
Scalars	Simple 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.

Enforcing inheritance

Setting inheritance: true in a global override enforces configuration inheritance across the entire organization or workspace. Every repository and PR review merges the full inheritance chain - including repositories that set inheritance: false (or omit it) in their own .coderabbit.yaml or UI settings. The override’s inheritance flag is evaluated before the inheritance walk and takes precedence over each level’s own flag, so no repository can opt out. This lets administrators turn on inheritance everywhere from a single place, instead of adding inheritance: true to every configuration source.

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 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