Connections

Connections give CodeRabbit Agent for Slack access to external tools like issue trackers, documentation, observability dashboards, MCP servers and custom APIs. Repository-provider credentials separately give the Agent access to repositories on supported providers. You configure both at the workspace level and assign them to the that need them. All signed-in users can open the Connections page from Slack Settings in the web app. Creating, editing, reconnecting, or deleting a connection requires either workspace admin access or assigned scope-admin access.

​

How connections are organized

Each service type (Jira, Linear, Notion, Sentry, Google Drive, etc.) is a connector. A connection is a specific account or credential under that connector. You can create multiple connections for the same connector if different teams need separate accounts or permissions. Repository-provider credentials are distinct from these third-party SaaS connections. They authorize repository access for a supported provider and are assigned to scopes alongside the repositories that the Agent can use.

​

Repository-provider credentials

Add repository-provider credentials from the Connections page, then assign them to the Base Scope or another scope. CodeRabbit validates each credential before it can be used for repository access. You can manage a provider credential throughout its lifecycle:

​

Supported connection categories

CodeRabbit Agent groups connections by category in the connection catalog: The exact catalog is product-defined and evolving. The important model is that connections are created once at the workspace level and then selected where needed.

​

Add a connection

​

Connector-specific notes

Some connectors require additional fields during setup:

​

How connections work with scopes

Creating a connection or provider credential does not grant CodeRabbit Agent access on its own. A connection only becomes available when a scope explicitly includes it, and a provider credential must be assigned to a scope before the Agent can use that provider’s repositories. This means you can configure access at the workspace level and then decide, scope by scope, which teams or channels should be able to use it. For most service types, a scope can include one connection per service. MCP connections are the exception: they are additive, so a scope’s MCP servers stack on top of those already included in the Base Scope. The Connections list shows a Scopes column so admins can see where each connection is currently assigned. Linked scopes appear by name, and unassigned connections show No scopes. Search also matches linked scope names, which helps you find all connections used by a specific team, channel, or workflow.

​

Who can do what

​

Reusing existing integrations and creating new ones

If your team already uses CodeRabbit for pull request reviews, you may already have integrations configured for services like Jira or Linear. CodeRabbit Agent can reuse those existing integrations as connections, so you do not need to set them up again from scratch. An older Linear connection that was authorized by a person may prompt you to Reconnect Linear as CodeRabbit rather than use the standard connect action when you save or edit it. This is expected and does not require setting up the connection again from scratch. Reconnecting grants the connection read/write access, which CodeRabbit requires to publish automation comments and final results to Linear; without it, automation output can fail or remain attributed to the person who originally authorized the connection. After you reconnect, actions such as comments on Linear issues are attributed to the CodeRabbit application instead of the person who originally authorized the connection, while existing connections keep their current action attribution until they are reconnected. To create a Linear authorization for managed webhooks, enable Manage Linear webhooks for automations during setup and edit the connection name if needed. CodeRabbit rejects an incomplete OAuth grant that is missing read, write, or admin access and asks you to reconnect. A complete authorization remains valid for Linear trigger administration but is excluded from automation destination choices. Create a separate eligible Linear destination connection when an automation must post results to Linear. Managed PagerDuty webhooks require a PagerDuty REST connection with an API key. When an Automation needs PagerDuty webhook access, a user with permission to manage workspace integrations is directed to the Connections page to enter a read/write General Access API key or a User Token whose user can manage webhook subscriptions. Existing PagerDuty OAuth and MCP connections cannot be used for managed webhook administration. Create a separate connection when the existing one does not fit: for example, when a different team needs its own account for the same service, when you want a stricter permission mode (read-only instead of read-write), or when a specific scope should only see a subset of a service’s data.

​

What’s next