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.
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, enablereview_details in your configuration:
.coderabbit.yaml
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.
- YAML Configuration
- Web Interface
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
Configuration fields
| Field | Required | Description |
|---|---|---|
repository | Yes | Repository in org/repo format (GitHub and Bitbucket), project/repo format (Azure DevOps), or group/subgroup/repo format (GitLab) |
instructions | No | Description 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.| Platform | Requirement |
|---|---|
| GitHub | The CodeRabbit GitHub App must be installed on all linked repositories. Inaccessible repositories are skipped, and a warning appears in the review summary. |
| GitLab | The bot token must have read access. Tokens are typically scoped to the group or instance. |
| Bitbucket Cloud | The bot token must have read access. Tokens are scoped to the workspace. |
| Azure DevOps | The 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-levellinked_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.
Troubleshooting
If cross-repository context is not appearing in reviews, work through these checks in order:Linked repositories not configured?
Linked repositories not configured?
Check your
.coderabbit.yaml or the Settings UI for a linked_repositories section. The feature requires explicit configuration — it is not enabled by default.Linked repository is the same as the current repo?
Linked repository is the same as the current repo?
Multi-repo analysis filters out the repository currently being reviewed. Make sure you have linked a different repository.
Bot does not have access?
Bot does not have access?
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.
Pull request has no cross-repo impact?
Pull request has no cross-repo impact?
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