Skip to main content
CodeRabbit can pull context from other repositories in the same organization when reviewing pull requests. When a code change touches a shared API, type definition, or database schema, CodeRabbit’s research agent automatically explores linked repositories and surfaces downstream impact — without you having to manually check each affected codebase.

​
Use cases

Multi-repo analysis is most valuable when your codebase is split across several repositories that share contracts or dependencies:
  • 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.
  • API contracts — When a backend API changes, frontend or mobile repositories may need coordinated updates.
  • 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.
1

Open the repository's Knowledge Base settings

In the CodeRabbit app, navigate to the specific repository you want to configure (for example, your frontend repo), then go to Knowledge Base > Linked Repositories.
2

Add a linked repository

Click Add and enter the repository in org/repo format (for example, acme/backend-api).
3

Add a description (optional)

Optionally provide a description and guidance on what this repository contains so CodeRabbit knows where to focus its search. For example: “Contains REST API endpoints and database models.”

​
Configuration fields

FieldRequiredDescription
repositoryYesRepository in org/repo format (GitHub) or group/subgroup/repo format (GitLab)
instructionsNoDescription and guidance on what the repository contains (max 2,000 characters)
Each repository configuration supports one linked repository. Support for multiple linked repositories is planned.

​
Platform requirements

The CodeRabbit bot must have read access to all linked repositories.
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 one entry, with the repository-level entry 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 one entry in a single .coderabbit.yaml file, schema validation will reject the configuration.

​
Limitations

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

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