CodeRabbit Release Notes

CodeRabbit API and hosted MCP server

The CodeRabbit API now covers what people do in the CodeRabbit app, not only exports and user management. More than 150 product operations let your scripts, services, and AI agents:

• Read pull requests with their checks and review threads, read review status, summaries, and Change Stack, and request a review.
• Create coding tasks, follow their turns, answer the agent's questions, approve plans, deliver patches, and manage coding environments.
• Read Triage changes, set a change's priority, and manage Triage rules.
• Start security scans, read findings, dependencies, SBOMs, and secrets, and request AI fixes.
• Manage Learnings and connected knowledge repositories.
• Create and run CodeRabbit Agent automations and reports.
• Read and change organization and repository settings, and manage connections.
• Read usage, credits, and budgets.

Hosted MCP server. The same operations are tools on the hosted MCP server at https://mcp.coderabbit.ai/. Add it to Claude, Claude Code, Codex, or another MCP client, sign in, and approve access for one organization. The agent then acts with your permissions. The MCP server is available in the US region.

CLI and workspace API tokens. coderabbit api request calls any operation from a shell or CI job. In an Enterprise SSO workspace, workspace API tokens work with product operations too: pass org_name or org_id to choose the organization.

Each operation follows the access rules of its feature in the app, so the API never grants more than the app does.

Learn more in Get started with the CodeRabbit API, Connect an MCP client, and the API reference.

CodeRabbit for JetBrains IDEs

CodeRabbit now reviews your code inside IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains IDEs, so you can catch issues before you push, without leaving the IDE you already work in. Findings show up in a CodeRabbit tool window and in the editor gutter, right next to the code they're about.

Review the edits you haven't committed, the commits on your branch, or both, or let CodeRabbit check each commit as you make it.

Apply a suggested fix as one edit you can undo, or hand the finding to Claude Code, Codex CLI, or opencode in the IDE terminal.

Working on a remote machine? The plugin supports JetBrains Remote Development, with Git and reviews running on the host.

The beta runs in JetBrains IDEs 2025.3 or later and installs from the JetBrains Marketplace beta channel. Get started.

GitLab group webhook migration

The webhook migration script's --group option now updates an existing matching group webhook, verifies its URL and visible settings, then removes matching project webhooks within the selected scope. Groups without a matching group hook are left unchanged; the script does not create one. Migration previews changes by default. For different group secrets, use group:ID keys in the secret map. Group hooks require GitLab Premium or Ultimate and group Owner or instance administrator permission.

See the webhook migration guide for preview, verification and recovery steps.

Testing a suspected vulnerability requires more than sending a request and checking the response. The application needs to be ready, and the request needs to reach the code being investigated.

Consider an endpoint that appears to let one user fetch another user’s document. To test it, you need two authenticated users, a document owned by one of them, and a running application. If the request fails before reaching the endpoint, it tells you little about whether the application properly restricts access to that document.

We built Runtime Verification in CodeRabbit Secure to help developers test Deep Scan findings and inspect what happened.

What we set out to build

We wanted developers to understand the proposed test before running it. They needed to know:

• What setup it required
• Which steps to follow
• What observations would support or challenge the finding

We built the workflow around a Reproducer Guide that brings those details together.

Developers can follow it in their own test environment or use Runtime Analysis to run it in a prepared CodeRabbit coding environment. A Runtime Analysis result includes supporting evidence and indicators of whether the application was ready and the intended code path was exercised.

Turning a finding into a Reproducer Guide

Deep Scan findings provide context about the suspected issue and its location. Because the code may have changed since the finding was reported, CodeRabbit rechecks whether the issue is still present before generating a guide. If the issue is no longer present or the recheck is inconclusive, guide generation stops.

For a finding that remains present, the guide connects the suspected behavior to prerequisites, steps, and expected observations. When you run the guide with Runtime Analysis, it uses the revision pinned in the published guide. Clicking Run does not recheck the finding or automatically test the latest source.

For the document endpoint example, the guide needs to establish which user owns the document and how the other user will attempt to retrieve it. The expected result must distinguish access to another user’s document from a request that fails before reaching the endpoint.

The guide needs to make its assumptions explicit so developers can check them against their own environment. If it cannot establish a required value or setup detail, it should identify what is missing and what the developer must supply before testing.

Unless a team has turned on automatic verification, generating the guide does not start the test. Developers can inspect it first, then decide where and how to run it.

Getting the experiment running

To run the guide with Runtime Analysis, the repository needs a prepared CodeRabbit coding environment with the dependencies, configuration, and startup instructions required to run the application.

Teams can also turn on automatic verification, which generates guides for newly detected findings at a chosen severity after each Deep Scan and runs them in the repository’s prepared default environment.

Starting the application’s process does not establish that it is ready for the test. A service may be listening while a required dependency is unavailable, or an authentication problem may prevent the request from reaching the intended endpoint. Runtime Analysis needs to account for those conditions when assessing the result.

The result includes Application ready and Target exercised indicators alongside the assessment and supporting evidence. These show whether CodeRabbit established that the application was ready and the relevant code path was exercised.

Use a dedicated test environment and avoid production credentials. The agent can read variables configured for the selected environment, including secrets. Avoid printing those values in test scripts or commands because the output may be retained as evidence.

Making sense of the outcome

Runtime Analysis reports one of three verification states:

• Reproduced: The run produced evidence supporting the finding under the tested conditions.
• Not reproduced: The run did not reproduce the finding under those conditions and other inputs or configurations may behave differently.
• Inconclusive: The run could not establish a supported conclusion. The result explains the reason and limitations.

Each result applies to the tested code revision and environment. A successful reproduction does not establish how every deployed version behaves.

In the document-access example, a 403 is meaningful only if the request reached the ownership check; a rejection caused by a missing session does not test that protection.

Likewise, “not reproduced” is narrower than “safe.” If setup problems prevented a meaningful test, the outcome should remain inconclusive rather than suggest the vulnerability is absent.

The decisions behind the workflow

The workflow separates the test plan, the execution, and the assessment so developers can inspect how the result was reached.

When developers generate a guide themselves, publishing it separately gives them a chance to inspect the proposed test before execution. They can check its assumptions and run it in their own environment. It also makes the distinction between expected results and observed behavior explicit.

What runtime evidence changes

A runtime test is useful only when the team can establish what it actually tested. That is why the guide, execution details, and supporting evidence remain available alongside the conclusion.

Set up Runtime Verification to test a Deep Scan finding in your own environment or with Runtime Analysis.

Run a Deep Scan on your own code. Start with a free sample scan.