Skip to main content
This feature is available exclusively as part of the Pro plan. Please refer to our pricing page for more information about our plans and features.
Many projects are built from multiple interdependent subprojects, for example: a backend service, a frontend app, a mobile client — that share APIs, type definitions, or database schemas. When they’re in separate repositories, a change in one can silently break another. To enable CodeRabbit to detect these cross-repository impacts during code review, configure linked repositories for the repositories that depend on each other.

Use cases

Multi-repo analysis is most valuable when your codebase is split across several repositories that share contracts or dependencies:
  • API contracts — When a backend API changes, frontend or mobile repositories may need coordinated updates.
  • Microservices architectures — A change to a service’s REST API may break consumers in other repositories.
  • Shared libraries — Modifications to a shared utility or type definition can have ripple effects across multiple repositories.
  • Database schemas — Schema changes can affect all services that query the same data model.

How it works during reviews

When you submit a pull request, CodeRabbit inspects the changes and determines whether they may affect the linked repositories. If the research agent finds relevant cross-repository impact, it includes those findings in the review. If the changes are self-contained and have no cross-repo effect, the agent does not produce findings — this is expected behavior and does not indicate a misconfiguration.

Where findings appear

Cross-repository findings appear in the pull request review summary comment under Review details > Additional context used, grouped by linked repository name. Findings also surface in inline review comments and comment replies when relevant. To see the Review details section, enable review_details in your configuration:
.coderabbit.yaml
reviews:
  review_details: true

Setting it up

Linked repositories are configured through the CodeRabbit web interface or via your .coderabbit.yaml file. In most cases, you want to configure this at the repository level — for example, linking your frontend repository to your backend, or your client repository to your server. Configuring linked repositories at the organization level applies the same linked repository to every repository in your organization, which is rarely what you want. If you need to share a default linked repository across repos while still allowing per-repo overrides, see configuration inheritance.
Add a linked_repositories section under knowledge_base in your .coderabbit.yaml file inside the repository you want to configure (for example, your frontend repo):
.coderabbit.yaml
# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
knowledge_base:
  linked_repositories:
    - repository: "myorg/backend-api"
      instructions: "Contains REST API endpoints and database models"

Configuration fields

FieldRequiredDescription
repositoryYesRepository in org/repo format (GitHub and Bitbucket), project/repo format (Azure DevOps), or group/subgroup/repo format (GitLab)
instructionsNoDescription and guidance on what the repository contains (max 2,000 characters)
Each repository configuration supports up to two linked repositories.

Platform requirements

The CodeRabbit bot must have read access to all linked repositories. Same platform only: All linked repositories must be on the same platform as the pull request under review. You cannot link a GitHub repository to a GitLab repository, because access tokens are platform-specific.
PlatformRequirement
GitHubThe CodeRabbit GitHub App must be installed on all linked repositories. Inaccessible repositories are skipped, and a warning appears in the review summary.
GitLabThe bot token must have read access. Tokens are typically scoped to the group or instance.
Bitbucket CloudThe bot token must have read access. Tokens are scoped to the workspace.
Azure DevOpsThe PAT must have read access. Tokens are scoped to the organization.
On GitHub, linked repositories can span multiple organizations as long as the CodeRabbit GitHub App is installed in each organization. Other platforms scope access tokens to the group, workspace, or organization.

Configuration inheritance

When configuration inheritance is enabled, organization-level and repository-level linked_repositories settings are merged. Repository-level entries take priority: if both levels define the same repository, the repository-level instructions are used. After merging, the list is truncated to two entries, with repository-level entries preserved. If any repositories are dropped during this process, a warning appears in the review summary showing which repositories were kept and which were skipped.
If you define more than two entries in a single .coderabbit.yaml file, schema validation will reject the configuration.

Troubleshooting

If cross-repository context is not appearing in reviews, work through these checks in order:
Check your .coderabbit.yaml or the Settings UI for a linked_repositories section. The feature requires explicit configuration — it is not enabled by default.
Multi-repo analysis filters out the repository currently being reviewed. Make sure you have linked a different repository.
On GitHub, the CodeRabbit App must be installed on the linked repository. On other platforms, the bot token must have read access. If a linked repository is inaccessible, a warning appears in the review summary identifying the repository and the specific error.
If the changes in the pull request are self-contained, the research agent will not produce cross-repository findings. This is expected — the absence of findings does not mean the feature is broken.

What’s next

Knowledge Base overview

Return to the Knowledge Base overview for all adaptive review features

CodeRabbit Learnings

Use learnings to train CodeRabbit on your team’s specific preferences

Model Context Protocol

Extend CodeRabbit’s understanding with external tools via the MCP