CodeRabbit Documentation - AI code reviews on pull requests, IDE, and CLI

CodeRabbit scans your repository for well-known AI coding assistant configuration files and uses their content as review criteria. If your team already writes instructions for tools like Cursor, Claude, or Windsurf, CodeRabbit picks those up automatically and enforces the same standards during code review.

Supported files

The following file patterns are detected by default:

File pattern	Associated tool
`**/AGENTS.md`	AI agent instructions
`**/.cursorrules`	Cursor
`.github/copilot-instructions.md`	GitHub Copilot
`.github/instructions/*.instructions.md`	GitHub Copilot (scoped instructions)
`**/CLAUDE.md`	Claude Code
`**/GEMINI.md`	Gemini CLI
`*/.cursor/rules/`	Cursor (rules directory)
`**/.windsurfrules`	Windsurf
`*/.clinerules/`	Cline
`*/.rules/`	Generic team rules
`**/AGENT.md`	AI agent instructions

File names are case-sensitive. A file named claude.md is not matched by the **/CLAUDE.md pattern.

How scoping works

By default, a guideline file applies to the directory it lives in and all of its subdirectories. CodeRabbit does not apply guidelines from one part of your repository tree to unrelated paths unless you explicitly map the guideline to source-file patterns with applyTo in a filePatterns object entry. Examples:

CLAUDE.md at the repository root → applies to all files
src/frontend/CLAUDE.md → applies only to files under src/frontend/
src/backend/.cursorrules → applies only to files under src/backend/

This directory-scoped behavior means you can maintain separate, purpose-fit guidelines for different areas of a monorepo without them interfering with each other. When directory placement does not match the files a guideline should govern, use the object form of filePatterns to define the mapping explicitly.

Without an explicit applyTo mapping, guidelines in a documentation or tooling directory will not affect code review unless the reviewed files live inside that same directory tree.

A common mistake is adding guideline file names (for example CLAUDE.md) to path_instructions. This tells CodeRabbit to review those files as changed code, not to use them as guidelines. Use filePatterns instead (see below), or rely on auto-detection.

Managing applied guidelines

The CodeRabbit UI shows the applied coding guidelines for a repository. Repository admins with write access can view applied guidelines and disable them. Select one or more applied guideline rows and click Trash selected to stop those rendered guidelines from being applied in future reviews. Trashing a guideline does not delete the source guideline file from your repository. It suppresses the rendered path pattern and instruction text that CodeRabbit applied for that repository. If the source guideline changes enough to render as a different instruction, it can appear again as a new applied guideline. To turn off code guidelines entirely for a repository, set knowledge_base.code_guidelines.enabled to false.

Adding custom file patterns

If your team stores coding standards in files that are not in the default list, you can extend the detected patterns by setting knowledge_base.code_guidelines.filePatterns in your .coderabbit.yaml. Each entry can be either a glob string or an object with files and applyTo fields. A string entry locates guideline files and scopes each matched file to its containing directory and subdirectories. An object entry uses files to locate the guideline document or documents and applyTo to define the source-file glob or globs they govern. This explicit mapping lets you store guidelines outside a source tree and apply them to any matching files. Custom patterns are added on top of the defaults—they do not replace them.

.coderabbit.yaml

knowledge_base:
  code_guidelines:
    filePatterns:
      - "**/CODING_STANDARDS.md"
      - files: "docs/guidelines/frontend.md"
        applyTo: "src/frontend/**/*.{js,jsx,ts,tsx}"

Glob patterns follow the same syntax used elsewhere in CodeRabbit configuration. The ** wildcard matches any number of path segments. In the configuration editor, the Files and Apply To fields correspond to the files and applyTo properties in an object entry.

Guidelines from another repository

| A string entry can name another repository as the source of your guideline files. Write it as repo:path to reuse the reviewed repository’s organization, or as owner/repo:path to name the organization explicitly. On GitHub, the source and reviewed repositories must be in the same organization; on GitLab, they must be in the same top-level group; on Bitbucket Cloud, they must be in the same workspace. The path can be an exact file path or a glob, and it can be mixed freely with unqualified entries that locate files in the repository being reviewed. Entries that name no repository keep selecting files from the reviewed repository, exactly as before, following the directory-based scoping described above.

Using configuration file
Using web interface

.coderabbit.yaml

knowledge_base:
  code_guidelines:
    filePatterns:
      - "**/CODING_STANDARDS.md"
      - "engineering-standards:frontend/react.md"
      - "engineering-standards:guidelines/**/*.md"
      - "api-contracts:contracts/billing.md"

Add the same entries to the File Patterns field under Knowledge Base > Code Guidelines, one per row, for example engineering-standards:frontend/react.md.

At review time, CodeRabbit reads matching files from the source repository’s default branch. Cross-repository guideline content is not pinned to a per-file revision, so later reviews can use updated content from that branch. Object entries support cross-repository sources too: a files value may use the same repo:path or owner/repo:path form, and the entry’s applyTo scopes the resulting guidance to matching paths in the repository being reviewed. This lets a centralized standards repository declare which files each guideline document governs — for example, a Python style guide that applies only to **/*.py in every consuming repository:

Using configuration file
Using web interface

.coderabbit.yaml

knowledge_base:
  code_guidelines:
    filePatterns:
      - files: "engineering-standards:python/**/*.md"
        applyTo: "**/*.py"

Under Knowledge Base > Code Guidelines, add a File Patterns row with the qualified reference in the Files field, for example engineering-standards:python/**/*.md, and the source-file patterns it governs in the Apply To field, for example **/*.py.

Guidelines selected from another repository through string entries apply globally to the reviewed repository as review instructions; an object entry’s declared applyTo narrows that guidance to the paths it names. CodeRabbit does not treat cross-repository guidelines as repository-specific learnings. Both entry forms apply when set through committed configuration files, the web interface, or central configuration. Pull request description overrides do not yet honor object-form entries for guideline selection — use string entries there.

Eligibility and access

Installation read access is required. The CodeRabbit installation must be able to read the source repository so it can resolve and load matching files.
Administrator-approved sources skip per-user checks. Sources set through trusted organization, central configuration, or target-branch configuration apply to every review, including for authors who cannot read the source repository directly.
Not available on self-hosted CodeRabbit. This feature requires CodeRabbit Cloud. That requirement is independent of whether your GitHub or GitLab instance itself is self-managed.

GitHub

Same organization only. The source and reviewed repositories must belong to the same organization. CodeRabbit rejects references to another organization, and ignores an entry that names the reviewed repository itself because local discovery already covers it.
Author and pusher access is checked. When a source is introduced through configuration on a collaborator’s pull request branch, or through a pull request description override, CodeRabbit confirms the pull request author can read the source repository and, if someone other than the author pushed to the branch, that they can read it too.

GitLab

Same top-level group only. The source and reviewed repositories must belong to the same top-level group. CodeRabbit rejects references outside that group and ignores an entry that names the reviewed repository itself because local discovery already covers it.
Reporter-or-higher membership is required. The merge request author and any distinct human account that triggers the review must have effective Reporter, Developer, Maintainer, or Owner membership in the source project. Guest membership does not qualify. Effective membership includes access inherited from a group or subgroup.
Usernames must match exactly. CodeRabbit resolves the exact GitLab username for an access check; prefixes and near matches do not qualify.
Separate actor checks apply only when needed. CodeRabbit skips the separate triggering-account check when the merge request author triggers the review or when CodeRabbit starts an automatic or command-triggered review.
Project visibility does not replace membership. Public or internal visibility without effective membership does not grant access to the source project for this feature.

Access checks fail closed. If CodeRabbit cannot confirm an identity or the required access on either provider, it omits that source and continues the review with the remaining guideline context instead of failing the review.

Limits and validation

Entries. You can configure at most 50 entries that name another repository.
Expanded files. CodeRabbit reads at most 50 files per review after those entries’ globs expand, counted across all source repositories.
Entry length. Each entry that names a repository can be at most 512 characters.

CodeRabbit rejects absolute paths, parent-directory traversal, backslashes, malformed repository names, and entries with extra colons. Only text and documentation files are read. A file is eligible when it has no extension, is a dotfile such as .cursorrules, or uses one of these extensions: .md, .mdc, .txt, .rst, .json, .yaml, .yml, .csv, .log, .conf, .cfg, .ini, .toml, .xml, .html, .tsv, .ndjson, .jsonl, .adoc, .tex, .asc. Source files such as .ts are skipped even though they are plain text.

Data retention

Local guideline discovery is stateless. Cross-repository guideline sourcing stores content-derived guideline digests and is excluded for organizations that set knowledge_base.opt_out. See Opt out of data retention.

Adding guidelines to a single pull request

Guideline sources can also be selected per pull request, which is useful when the standards that matter depend on what a pull request changes. Add a configuration override to the pull request description: the @coderabbitai configuration override line as plain text, immediately followed by a fenced YAML block.

@coderabbitai configuration override

```yaml
knowledge_base:
  code_guidelines:
    filePatterns:
      - "platform-standards:security/**.md"
```

Guidelines added this way apply only to that pull request, and only in addition to the guidelines your configuration already defines. They cannot replace or disable the configured set, so your organization’s standards always still apply. Because the selection lives in the pull request description, it can be written by hand or set programmatically. Tooling that opens or updates pull requests can choose the guideline documents that match the area of the codebase being changed, keeping the committed configuration to the standards that apply everywhere. This requires a pull request from a branch in the repository itself, opened by a repository collaborator, member, or owner. Guideline entries are not accepted from a fork’s description: CodeRabbit rejects the block that contains them and notes it in the pull request. Access to entries added this way is checked the same way as other collaborator-introduced sources — see Eligibility and access above. For the full set of settings a description override accepts, see configuration override.

Guideline status in the review summary

The review summary reports the guidelines a review used separately from the problems CodeRabbit ran into. Applied guidelines get their own 🧰 Additional context used entry at the top of the summary, and a source CodeRabbit could not use is reported as a warning in the note just above it.

Guidelines that were applied

At the top of the review summary, below any note, expand 🧰 Additional context used and open 📚 Code guidelines (N). It lists the guideline files that reached this review’s prompt, one per line, plus any cross-repository sources added by the pull request description (see below). This block holds only the code guidelines. It is separate from the 🧰 Additional context used section in the review details, which holds 📓 Path-based instructions and the review’s other context, and it appears even when review details are turned off (reviews.review_details is false by default). Each repository file is labelled with where it came from:

configured: the file matches one of your code_guidelines.filePatterns. This label takes precedence, so a file your patterns match is labelled configured even when CodeRabbit would also find it by name or as an Agent Skill.
auto-discovered: CodeRabbit found the file by its name, for example AGENTS.md, CLAUDE.md or .cursorrules.
Agent Skill: the file is a SKILL.md in a skill directory at the repository root, either skills/<name>/SKILL.md or the same path under .agents/, .claude/, .codex/, .cursor/, .gemini/ or .github/, for example .agents/skills/review/SKILL.md. The <name> directory uses only lowercase letters, digits and hyphens. A SKILL.md at another path that your filePatterns match, such as docs/review/SKILL.md, is labelled configured.

Cross-repository sources appear in the same entry and the same count, whether they were configured for the organization or repository through .coderabbit.yaml, the web interface, or central configuration, or added by this pull request’s description. A configured source that CodeRabbit collected but then left out of the prompt is not listed. For example, the review’s guideline budget can leave a source out. Sources added by this pull request’s description are listed as CodeRabbit collected them, without that check, so one of them can appear in the entry even when the guideline budget left it out of the prompt.

📚 Code guidelines (5)
AGENTS.md — auto-discovered
.agents/skills/review/SKILL.md — Agent Skill
docs/guidelines.md — configured
acme/standards:security/auth.md
acme/standards:backend/api.md

On a public repository, a cross-repository source name could reveal a private repository in the same organization, so those are counted instead of listed. The repository’s own guideline files are already public, so they are still named:

📚 Code guidelines (5)
AGENTS.md — auto-discovered
.agents/skills/review/SKILL.md — Agent Skill
docs/guidelines.md — configured
2 cross-repository guideline sources

This entry describes the review that wrote the summary. If a later review of the same pull request applies no guidelines, the entry does not appear, the same way the path-based instructions in the review details describe only the files that review looked at.

Sources CodeRabbit could not use

A note at the top of the summary appears only when something needs your attention, and lists Skipped guideline sources (N) with the reason next to each one, along with any configuration parse errors or warnings. CodeRabbit continues the review with local guidelines and other reachable sources, so a skipped source does not block the review. When every source was usable, the note does not appear at all.

Skipped guideline sources (1)
acme/standards:missing/**/*.md — no matching files were found in its default branch

On a public repository this block keeps the reason next to each source, but sources from your configuration appear as a configured source instead of by name. Sources named in the pull request description are listed as written.

To see which guidelines are configured for a repository, visit the Code Guidelines page in the CodeRabbit UI.

Configuration reference

.coderabbit.yaml

knowledge_base:
  code_guidelines:
    enabled: true
    filePatterns:
      - "**/CODING_STANDARDS.md"

Field	Type	Default	Description
`enabled`	boolean	`true`	Apply coding guideline files as review criteria. Set to `false` to disable auto-detection entirely.
`filePatterns`	array of strings or `{ files, applyTo }` objects	`[]`	Additional guideline mappings. String entries use directory-based scoping, or `repo:path` / `owner/repo:path` to source guidelines from another repository in the same organization; object entries map guideline files to explicit source-file patterns, and their `files` values may also use the `repo:path` / `owner/repo:path` forms to source the documents from another repository. Supplements the built-in defaults; does not replace them. File names are case-sensitive.

Setting filePatterns to an empty list ([]) keeps the default patterns active. To disable code guidelines entirely, set enabled: false.

What’s next

Knowledge base overview

Learn about all knowledge base capabilities: learnings, code guidelines, and linked repositories.

Learnings

Teach CodeRabbit your team’s review preferences through natural conversation.

Configuration reference

Full reference for all knowledge_base configuration options.

Platform

Getting Started

Triage

Pull Request Reviews

Change Stack

Available actions

Pre-Merge Checks

Post-Merge Actions

Finishing touches

Knowledge Base

CodeRabbit Security

Configuration

Tools

CodeRabbit Plan

Issue Management

Resources

Code Guidelines

Supported files

How scoping works

Managing applied guidelines

Adding custom file patterns

Guidelines from another repository

Eligibility and access

GitHub

GitLab

Limits and validation

Data retention

Adding guidelines to a single pull request

Guideline status in the review summary

Guidelines that were applied

Sources CodeRabbit could not use

Configuration reference

What’s next

Knowledge base overview

Learnings

Configuration reference

​Supported files

​How scoping works

​Managing applied guidelines

​Adding custom file patterns

​Guidelines from another repository

​Eligibility and access

​GitHub

​GitLab

​Limits and validation

​Data retention

​Adding guidelines to a single pull request

​Guideline status in the review summary

​Guidelines that were applied

​Sources CodeRabbit could not use

​Configuration reference

​What’s next

Knowledge base overview

Learnings

Configuration reference

Supported files

How scoping works

Managing applied guidelines

Adding custom file patterns

Guidelines from another repository

Eligibility and access

GitHub

GitLab

Limits and validation

Data retention

Adding guidelines to a single pull request

Guideline status in the review summary

Guidelines that were applied

Sources CodeRabbit could not use

Configuration reference

What’s next