# Auto-generate user names Source: https://docs.qodo.ai/account-management/auto-generate-user-names Configure how Qodo automatically generates user names from email addresses for use in third-party systems. This setting is available only on Enterprise plans and can be managed by organization admins. Control how Qodo generates user names for users in your organization. When **Auto-generate user name** is enabled, Qodo automatically generates a user name from the user's email address. For example, `john.smith@company.com` becomes `john.smith`. Qodo uses user names to identify users in third-party systems, such as Git providers. ## Enable or disable auto-generated user names In the Qodo portal, go to **Account Management**. Select **Settings**. Select **Access & permissions**. Turn the **Auto-generate user name** toggle on or off. When enabled, Qodo automatically generates user names based on users' email addresses. ## Additional resources * [Manage users in the Qodo portal](/account-management/users) * [Delegate edit permissions](/account-management/delegate-edit-permissions) * [Restrict reviews to registered users](/account-management/restrict-reviews-to-registered-users) # Delegate edit permissions Source: https://docs.qodo.ai/account-management/delegate-edit-permissions Requires Organization admin role. The **Grant edit permissions** configuration grants edit access to the Configuration, Review standards, Integrations, and Repositories pages to the selected role and any higher-privileged role. For example, selecting Members grants access to members, team owners, and organization admins alike. Applies to the entire organization. | Setting | Users with edit access | | - | - | | Organization admin (default) | Organization admins | | Team owner | Organization admins and Team owners | | Members | Organization admins, Team owners, and Members | Setting **Grant edit permissions** to **Members** allows all account users to edit the Repositories and Configurations pages, including installing and managing Git integrations. ## Grant edit permissions Log in to the Qodo portal. Navigate to **Account Management** > **Settings** section. From **Grant edit permissions** list, select the required permission level. Grant edit permissions Click **Save**. ## Additional resources * [Manage users in the Qodo portal](/account-management/users) * [Auto-generate user names](/account-management/auto-generate-user-names) * [Restrict reviews to registered users](/account-management/restrict-reviews-to-registered-users) # Restrict organization sign-up to invited users Source: https://docs.qodo.ai/account-management/invite-only-access Restrict organization sign-up, allowing users to join only using admin-approved invitations. This setting controls who can join your organization. It's different from **invite-only access**, which controls who receives Qodo's review feedback on pull requests. This setting is available to organization admins. When **Invite-only access** is enabled, only users who have been invited to the organization can register or sign in. Users who have not been invited are blocked from accessing the organization, and an access request is sent to an organization admin for approval. ## Enable or disable invite-only access In the Qodo portal, go to **Account Management**. Select **Settings**. Select **Access & permissions**. Enable the **Invite-only access** toggle. Click **Save**. This change applies instantly. ## Sign up with an invitation To join an invite-only organization using an invitation: Open the invitation email and follow the link. Complete sign-up with the invited email address. See [Quickstart: From sign-up to your first code review](/get-started#step-1-create-your-account). ## Sign up without an invitation When invite-only access is enabled and a user signs up with a company email domain but doesn't have an invitation: The user signs up with a company email domain but isn't automatically added to the organization. An access request is sent to an organization admin. The user cannot access the organization until it is approved. The admin approves the request and the user is invited to join. # Manage API keys in the Qodo portal Source: https://docs.qodo.ai/account-management/manage-api-keys Generate and manage personal API keys in the Qodo portal for authenticating requests to Qodo services and integrations.
Multi-tenant Single-tenant
You can generate and manage personal API keys in the Qodo portal. Each API key is assigned to the user who creates it and can authenticate requests to Qodo services and integrations, including features like Skills. ## API key rules and limitations * API keys can only be copied during generation. They will not be shown again afterward. * API keys can be configured with an expiration period when they are created. * An expired API key can no longer be used for authentication. ## Create an API key Log in to the Qodo portal. Open the user menu in the bottom-left corner and select **API Keys**. The **API Keys** page opens. Click **Create API Key**.
API key creation dialog in the Qodo portal
Under **API Key Name**, enter a descriptive name to help identify the key later. Under **Expiration**, select when the API key should expire: * **Long-lived**: The key never expires. This is the default. * **Expires in 90 days**: The key expires 90 days after it is created. * **Custom**: Set a specific number of days until the key expires. The maximum is 365. Click **Create**. The **API Key Created** dialog opens, displaying the API key (masked with asterisks). API Key Created dialog Copy the API key and store it securely for future use. Click **Done**. The key is now added to the API key list. ## Revoke an API key Revoking an API key immediately disables all services and integrations using it. Use revocation if a key is compromised, no longer needed, or requires rotation. Once revoked, the API key can no longer be used for authentication. In the **API Keys** table, locate the relevant key. Open the three-dot menu at the end of the row.
API key revoke button in the Qodo portal
Click **Revoke**. The **Revoke API Key** dialog opens.
Revoke API Key confirmation dialog in the Qodo portal
Click **Revoke**. The API key is removed from the list. # Account management Source: https://docs.qodo.ai/account-management/manage-your-qodo-account Manage your Qodo account, authentication, access, permissions, and API keys from the Qodo portal. Manage your Qodo account and organization settings from the Qodo portal. Use the pages in this section to configure authentication, manage access and permissions, and manage API keys. For a broader overview of the Qodo portal, including configuring and managing code reviews, see [Qodo portal quick tour](/qodo-portal-quick-tour). ## Authentication Configure how users authenticate to Qodo and how your organization manages access. * [Single sign-on (SSO)](/account-management/single-sign-on-sso): Configure SSO to let users authenticate to Qodo through your organization's identity provider. ## Access and permissions Manage who can access Qodo and what they can do within your organization. * **Manage your Qodo account**\ Manage your account and organization settings in the Qodo portal. * [Roles and permissions in Qodo](/account-management/roles-and-permissions) Learn about the roles available in Qodo and the permissions associated with each role. * **Restrict code reviews**\ Control which users, teams, or repositories can use Qodo code reviews. ## API key management Manage API keys used to authenticate requests to Qodo services and integrations. * [API key management](/account-management/manage-api-keys)\ Generate and manage API keys, configure expiration, and revoke keys when they are no longer needed. ## Additional settings Access additional account-level settings and tools from the menu in the bottom-left corner of the Qodo portal. * [Link your Git Provider account](/install-qodo/install)\ Connect your Git provider account to access repositories and enable Qodo features that integrate with your development workflow. For more information, see Install Qodo in your Git provider. * Link to official [Qodo documentation](https://docs.qodo.ai/) * Sign out\ Sign out of your Qodo account. ## Related resources * [Qodo Portal Quick tour](/qodo-portal-quick-tour) # Restrict reviews to registered users Source: https://docs.qodo.ai/account-management/restrict-reviews-to-registered-users Restrict Qodo review feedback to registered users at the organization level. The **Restrict reviews to registered users** setting controls who receives Qodo's review feedback on pull requests. When enabled, only registered users receive Qodo's review feedback on their pull requests. Reviews for other users are silently skipped. This setting applies at the organization level and is useful for staged rollouts. ## Enable restrict reviews to registered users Organization admins can enable this setting at any time: Sign in to the Qodo portal. Navigate to **Account Management** > **Settings**. Navigate to the **Access & Permissions** section. Enable the **Restrict reviews to registered users** toggle. Click **Save**. ## Manage permissions Organization admins can always modify **Restrict reviews to registered users**. Team owners and members can also modify the setting based on the **Grant edit permissions** configuration: * **Team owner**: Team owners can modify the setting. * **Members**: Team owners and members can modify the setting. ## Additional resources * [Manage users in the Qodo portal](/account-management/users) * [Auto-generate user names](/account-management/auto-generate-user-names) * [Delegate edit permissions](/account-management/delegate-edit-permissions) # Roles and permissions in Qodo Source: https://docs.qodo.ai/account-management/roles-and-permissions Understand Qodo roles, administrative permissions, and how access is managed across your Qodo account. Roles determine what users can manage and access in your Qodo account. Account management is handled through the Qodo Portal, where users can manage settings, permissions, and other administrative features based on their assigned role. The roles available in Qodo depend on your subscription plan. Enterprise accounts include organization-level roles, while Pro Team accounts are managed at the team level. When a new Qodo account is created, the first user is automatically assigned the highest available role for the subscription plan. ## Roles by subscription plan | Plan | Role | Scope | | - | - | - | | Pro Team | Team owner | Team | | | Team member | Team | | Enterprise | Organization admin | Organization | | | Organization member | Organization | | | Team owner | Team | | | Team member | Team | ## Supported roles ### Organization admin **Available on:** Enterprise Organization admins manage the Qodo organization and have full administrative access. They can: * Manage organization settings. * Create and manage teams. * Invite and remove users. * Assign Organization admin and Team owner roles. * Configure authentication, including SSO and API keys. * Manage organization-wide code review settings. * Grant access to the Software map. ### Organization member Members are standard users in a Qodo account. They can: * Access the Qodo portal features available to their team. * View and manage the repositories available to their team, based on their assigned permissions. * Repository access for automated code review is determined by the Git integration and repository installation, not by Qodo account membership. ### Team owner **Available on:** Enterprise Team owners help manage users and settings within their assigned team. They can: * Add and remove users from their team. * Manage team-related settings delegated by an Organization admin. They can invite external users to their own team and by that to the organization. * Grant access to the Software map the team members. ### Team member Team Members belong to the team assigned by the Team owner. They can: * Access the Qodo portal features available to their team. * View and manage the repositories available to their team, based on their assigned permissions. ## Related resources * [Manage your Qodo account](/account-management/manage-your-qodo-account) * [Manage users](/account-management/users) * [Delegate edit permissions](/account-management/delegate-edit-permissions) * [Manage teams](/account-management/teams) * [Account-related configurations in the Qodo portal](/configuration/portal-configuration) # Configure Single sign-on (SSO) Source: https://docs.qodo.ai/account-management/single-sign-on-sso Configure single sign-on for your Qodo organization, including identity provider setup, SP-initiated and IdP-initiated login, and enforcement. Enterprise Also available on paid plans for an additional cost. [Contact Qodo](https://www.qodo.ai/contact/) for more information. This guide explains how to configure Single Sign-On (SSO) for your Qodo organization. By enabling SSO, you simplify authentication, reduce the need to manage multiple user accounts and passwords, and centralize access across your organization. This improves security while providing users with a seamless sign-in experience using a single set of credentials. ## Prerequisites Before configuring SSO, make sure you have: * A Qodo user account with **admin** privileges. * An **Enterprise license** for Qodo. * **Administrator access** to your identity provider. * **Qodo avatar**: Download if your identity provider requires an app logo during setup. Download ↓ ## Step 1: Initiate SSO configuration Log in to your Qodo account as an administrator. Navigate to the **Account Management** > **Settings**. Under the **Authentication** section, click **Configure**. ## Step 2: Select your identity provider Select one of the supported identity providers. * **ADP OpenID Connect**: Workforce identity and HR-integrated authentication * **Auth0 SAML**: Flexible authentication and identity platform * **CAS SAML**: Central Authentication Service for single sign-on * **ClassLink SAML**: Education-focused SSO platform * **Clever OpenID Connect**: Identity platform for education organizations * **Cloudflare SAML**: Zero Trust access and identity integration * **CyberArk SAML**: Privileged access and identity security * **Duo SAML**: Multi-factor authentication and access security * **Entra ID (Azure AD) OpenID Connect**: Microsoft identity platform using OIDC * **Entra ID (Azure AD) SAML**: Microsoft’s cloud-based identity service * **Google OpenID Connect**: Google Workspace authentication using OIDC * **Google SAML**: Google Workspace SAML-based SSO * **JumpCloud SAML**: Cloud directory and device management * **Keycloak SAML**: Open-source identity and access management * **LastPass SAML**: Identity and password management SSO * **Login.gov OpenID Connect**: U.S. government identity provider * **Microsoft AD FS**: On-premises Active Directory Federation Services * **miniOrange SAML**: Identity and access management platform * **NetIQ SAML**: Enterprise identity and access management * **Okta OpenID Connect**: Okta authentication using OIDC * **Okta SAML**: Enterprise identity and access management * **OneLogin**: Cloud-based identity and access management * **Oracle**: Oracle Identity and Access Management SSO * **PingFederate**: Enterprise federation and SSO solution * **PingOne**: Cloud identity platform by Ping Identity * **Rippling**: Workforce management with integrated SSO * **Salesforce**: CRM-based identity provider and SSO * **Shibboleth**: Open-source federated identity solution * **Shibboleth Generic SAML**: Generic SAML configuration for Shibboleth * **SimpleSAMLphp SAML**: PHP-based SAML identity provider * **VMware Workspace ONE**: Unified endpoint and identity management * **Custom SAML**: Generic SAML 2.0 configuration for unsupported providers SSO identity provider selection screen showing Okta, Google, Entra ID and other providers After you select an identity provider, Qodo opens the WorkOS Admin Portal, which Qodo uses to manage SSO provider connections. Follow the provider-specific instructions to configure the connection. ## Step 3: Complete the identity provider configuration The WorkOS Admin Portal provides step-by-step instructions for configuring your selected identity provider. Follow the prompts to establish the trust relationship between Qodo and your identity provider. After you complete the configuration, return to the Qodo portal to continue the SSO setup. ## Step 4: Set the login method After selecting your identity provider, choose how users will authenticate with Qodo. * **SP-initiated login** Users begin authentication from the Qodo login page (app.qodo.ai). Qodo redirects them to the configured identity provider for authentication before returning them to Qodo. * **IdP-initiated login** Users begin authentication from their identity provider portal by launching the Qodo application (for example, selecting the Qodo application tile in Okta or Microsoft Entra ID). Follow the provider-specific instructions to configure IdP-initiated login. Once SSO is configured for your organization, it is enforced by default. After enforcement, users must authenticate using the configured identity provider, and other authentication methods (such as Google sign-in) cannot be used in parallel. ## Example: Configure Entra ID (Azure AD) This section provides an example of connecting Qodo to Azure AD. Follow the **in-product instructions** for complete and up-to-date steps. As part of the WorkOS Admin Portal configuration in Step 4, you'll create and configure an enterprise application in Entra ID to establish the connection with Qodo. Follow the in-product prompts to complete this setup. **Required Access**: You must have administrator access to your Microsoft Entra admin center to complete these steps. Entra ID SAML configuration step 1 in the Qodo SSO setup wizard After completing the provider-specific setup: * **Test the connection**: Verify SSO using a test user * **Assign users**: Add team members to the SSO application * **Confirm enforcement**: SSO is automatically enforced and becomes the only supported authentication method for the organization ## Troubleshooting If you encounter issues, check the following: * **Configuration**: Ensure all URLs and endpoints are correctly configured in both Qodo and your identity provider. * **User mapping**: Verify that user email addresses match between Qodo and your identity provider. * **Token/SAML assertions**: Confirm that the SAML assertion or OIDC token contains the required user attributes. * **User access**: Verify that users are assigned to the Qodo application in your identity provider. * **SP-initiated login**: If SP-initiated login fails, verify that users are starting authentication from the Qodo login page. * **IdP-initiated login**: If IdP-initiated login fails, verify that the Qodo application is correctly configured in your identity provider and that users are launching the application from their identity provider portal. ## Support If issues persist: * Review the provider-specific documentation. * Contact your identity provider's support team for provider-side issues. * Reach out to Qodo support for application-specific questions. # Manage teams in the Qodo portal Source: https://docs.qodo.ai/account-management/teams View and manage teams in your account. The Teams page is used to organize users into teams and manage team-level settings. ## Who can access this page? * **Enterprise** * Organization admins can view and manage all teams. * Team admins can manage their own teams. * **Team and Free plans** * Team admins can manage the single available team. * Team members can view team information only. Teams list in the Qodo portal showing team name, owner, and members Teams table parameters | Parameteres | Description | | - | - | | Team | The team name. | | Created on | Date the team was created. | | Owner | Email address of the team admin. | | Members | Number of users in the team. | | Actions | Available team actions. | ## Create a team Open the **Teams** page. Select **Create team**. Enter a **team name** and select a **team owner** (search by user email). Click **Create team** to finish. The new team appears in the teams list and can be managed immediately. ## Manage teams Select the three-dot menu at the end of a team row to open the available team management actions. ### View team members From the team’s Actions menu, select **View team members** to see all users assigned to the team. ### Rename a team Team owners and organization admins can perform this action. From the team’s Actions menu, select **Rename team**. Enter the new team name. Click **Save.** ### Delete a team This action cannot be undone. Open the team’s **Actions** menu. Select **Delete team**. Confirm the action. **What happens when a team is deleted?** The result depends on the account type: **Team in an Enterprise plan** * Team members are removed from the team. * They remain in the organization. * Removed members can still be found on the **Users** page. * Other teams and subscriptions are not affected. **Team in a Teams plan** * Deleting the team terminates the active Teams subscription immediately. * No refund is issued. * Removes the user account from the database. If a user wants to stop renewing but keep access until the end of the billing cycle, they should use **Cancel subscription** instead. This keeps the plan active until the billing period ends, after which the account is downgraded to free. ## Additional resources * [Account management overview](/account-management/manage-your-qodo-account) * [Manage users in the Qodo portal](/account-management/users) # Set up the User management API Source: https://docs.qodo.ai/account-management/user-management-api Enable the User management API, create an API key, and send your first authenticated request. Single-tenant Research Preview The User management API lets organization owners list, invite, update, and remove organization members programmatically. Requests are scoped to the organization and workspace associated with the API key owner. ## Prerequisites Before you begin, make sure you have: * An eligible Qodo single-tenant organization. * User management API access enabled for your organization. Contact [Qodo Support](/qodo-support) to confirm access. * The organization owner role. For more information, see [Roles and permissions](/account-management/roles-and-permissions). * Your Qodo tenant subdomain. Qodo provides this value when API access is enabled. The `v1` segment in `/platform/v1` identifies the API contract version. It is independent of the Qodo product documentation version. ## Quickstart ### Create an API key The API uses a personal `sk-` API key that belongs to an organization owner. Log in to the Qodo portal as an organization owner. Navigate to your Account settings in the bottom-left corner. Click **Create API Key**. Enter a descriptive name and select an expiration period. Use an expiring key when your integration supports rotation. Click **Create**, copy the key, and store it in your organization's secret manager. Qodo does not display the complete key again. For more information, see [API key management](/account-management/manage-api-keys). ### Configure your API client Use your single-tenant Platform host as the API base URL: ```text theme={null} https://qodo-platform..st.qodo.ai ``` All API requests use this base URL. Authenticate requests by sending your API key in the `Authorization` header: ```http theme={null} Authorization: Bearer ``` Do not commit the key to source control or include it in logs. Load it from a secret manager or another protected runtime configuration. ### Send your first request List the members in your organization: ```bash theme={null} curl --request GET \ --url "https://qodo-platform..st.qodo.ai/platform/v1/admin/users?page=1&page_size=50" \ --header "Authorization: Bearer " ``` A successful request returns a paginated response: ```json theme={null} { "items": [], "total": 0, "page": 1, "size": 50, "pages": 0 } ``` Replace the placeholders before sending the request. Never paste a real API key into a shared script, ticket, or documentation page. ## Use the API playground 1. In the documentation navigation, open Account management > API. 2. Select an endpoint and click **Try it**. 3. Replace `your-tenant` with your tenant subdomain. 4. Enter your API key in the **Bearer** field. 5. Review the target host, then click **Send**. Treat values entered in the playground as secrets. Verify the tenant host before sending a request, and do not forward a key automatically to a host returned in an error response. ## Troubleshoot authentication and access | Status | Cause | Resolution | | - | - | - | | `401` | The credential or authenticated identity is invalid. | Create a new key and verify that the complete value was copied. | | `403` | The key owner is not an organization owner, or API access is not enabled. | Use an organization owner's key and confirm API access with Qodo Support. | | `409` | The single-tenant identity flow returned another Qodo host. | Verify `detail.redirectTo` and confirm the expected tenant host before retrying. Do not forward credentials automatically. | | `501` | The deployment does not support the User management API. | Use an eligible single-tenant deployment. | | `503` | API access or authorization could not be verified. | Retry later. Contact Qodo Support if the error continues. | ## Removal and offboarding limitations Removing a member does not currently revoke that member's personal API keys. Do not use the remove-member endpoint as the only step in an automated offboarding workflow until Qodo confirms that API-key revocation is enabled for your deployment. In an organization that allows domain-based sign-up, a removed user can join again at the next sign-in. Configure [invite-only access](/account-management/invite-only-access) when membership must require an invitation. ## Next steps * [List organization members](/api-reference/user-management/list-organization-members): Send your first authenticated User management API request. * [API key management](/account-management/manage-api-keys): Rotate or revoke personal API keys. * [Roles and permissions](/account-management/roles-and-permissions): Review organization and team roles. # Manage users in the Qodo portal Source: https://docs.qodo.ai/account-management/users View and manage users in your account. The **Users** page lists everyone with access to your Qodo account, including their role, team, and status. You can filter by team, search by name or email, and use the actions menu to manage individual users. Available information and actions depend on your plan and role. #### Who can access this page? * **Enterprise** * Organization admins can view and manage all users. * Team owners can view and manage users within their teams. * **Pro Team plan** * Team owners can view and manage users. * Team members and standalone users can view only their own information. Users table in the Qodo portal showing email, status, and team columns User related parameters | Field | Description | | - | - | | Email | The user’s login email address. | | User name | The user’s unique identifier. | | Last login | The last time the user logged in to Qodo. | | Status | Indicates whether the user has completed registration. | | Linked Git accounts | Shows whether a Git provider is connected. | | Team name | The team the user belongs to, or **No team**. | | Team role | Team owner or member. | | Actions | Available actions based on your permissions. | #### View user details Selecting **View** from a user’s Actions menu opens a details panel displaying information about the selected user. #### Export to CSV From the three-dot menu in the top-right corner of the Users page, select **Export CSV** to download the users list as a CSV file. #### Invite team members Available to team owners and organization admins. To invite users to a team: Navigate to the **Users** page. In the top-right corner of the page, click **Invite members**. Enter one or more email addresses. (Optional) Upload a file to invite users in bulk. Click **Invite** to send the invitation. A user can belong to only one team. #### Remove team members Removing members requires [invite-only sign-up](/account-management/invite-only-access) to be enabled. Click the **Actions** menu (three vertical dots) next to the user you wish to remove. Select the **Delete** (trash can) icon to remove the member. #### Edit user roles and assignments Depending on your role, you can update: * Organization role (Enterprise only). * Team assignment * Team role A user can belong to only one team. **To edit a user:** Within the user details page, update any of the editable parameters (user name, organization role, team name, or team role). Click **Update** to save your changes. #### Who can remove users? You can remove users from the account based on your permissions. * Organization admins can remove any user. * Team owners can remove users from their team. ## Additional resources * [Auto-generate user names](/account-management/auto-generate-user-names) * [Delegate edit permissions](/account-management/delegate-edit-permissions) * [Restrict reviews to registered users](/account-management/restrict-reviews-to-registered-users) # The Qodo Agentic Toolbox Source: https://docs.qodo.ai/agentic-toolbox A CLI-powered Quality counterpart for coding agents The Qodo Agentic Toolbox gives your coding agent access to Qodo's code understanding, coding standards, and review capabilities. Use it to understand your codebase, apply your team's rules, review changes before pull requests, and resolve findings. ### Start using the Agentic Toolbox Read the [overview](/agentic-toolbox/agentic-toolbox-overview) to learn how the Agentic Toolbox works, then choose whether to install it locally with the CLI or use it as an MCP server.

Install locally with CLI

Run the command locally, then follow the prompts to sign in to Qodo. See CLI. For on-premises deployments, install from your Qodo portal.

```bash theme={null} curl -fsSL https://get.qodo.ai | sh ``` ```powershell theme={null} powershell -ExecutionPolicy Bypass -Command "irm https://get.qodo.ai/install.ps1 | iex" ```

Download the plugin

Add the Agentic Toolbox to a supported coding agent.

Use as an MCP server

Connect any MCP-compatible client or coding agent to Qodo's Agentic Toolbox using the MCP server.

  1. Create an API key in the Qodo portal.
  2. Add the MCP server URL to your MCP client.
  3. Restart your MCP client.
 ### Add Agentic Toolbox instructions to your agent Copy the following to your agent instruction file, such as `AGENTS.md` or `CLAUDE.md`. [Learn more](/agentic-toolbox/agentic-toolbox-overview#configure-coding-agent-instructions) ``` Read the [Default template](/agentic-toolbox/agentic-toolbox-overview#default-template) before using the Agentic Toolbox. Add the template's instructions to the appropriate agent instruction file, then follow those instructions throughout your workflow. ``` ### Qodo tools Skills use Qodo tools to give your coding agent the capabilities it needs throughout your workflow. See [Qodo tools](/agentic-toolbox/qodo-tools-overview). ### What you can do Give your coding agent the context, standards, and review capabilities it needs to work effectively with your codebase.

Review

Review changes before opening a pull request Provide context a forge reviewer cannot see Scope reviews to specific files or directories Learn more →

Resolve findings

Resolve review findings Control the scope of resolution Understand skipped findings Learn more →

Codebase wisdom

Understand your architecture Analyze the impact of a change Learn from previous implementations Learn more →

Manage standards

Capture a convention as a rule Edit or change the lifecycle of a rule Triage pending suggestions and run bulk hygiene Learn more →

Get rules (Opt-in skill)

Apply rules before writing code Apply organization-wide standards Follow repository-specific conventions Learn more → # Agentic Toolbox: Reviewer skill Source: https://docs.qodo.ai/agentic-toolbox/agentic-toolbox-codebase-review-skill Review local code changes with Qodo's review engine before creating a pull request. Reviewer is one of the skills in the [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview). It enables your coding agent to review local changes before a pull request exists, using the same engine as Qodo Review. Reviewer enables AI agents to review local, committed, and uncommitted changes while they work on code. Your agent sends the working-tree diff to Qodo's review engine and receives structured findings in the same session, allowing it to identify and fix issues in a continuous loop and produce higher-quality code. Reviewer combines your local diff, new untracked files, and the coding-session context you provide, including a summary of intent, key decisions, and links to the ticket, spec, or design that drove the change. This gives the review engine context that a forge-based reviewer typically does not have access to. The agent uses these findings as part of its development workflow, similar to how it would use post-pull request review comments, but while it is still authoring the code. This helps teams resolve issues during development and open cleaner pull requests. The Review skill uses Qodo tools to access this information. The tools provide the underlying capabilities that let your agent search repositories, inspect files and Git history, explore pull requests, and understand relationships between repositories. See [Qodo tools](/agentic-toolbox/qodo-tools-overview/) for an overview of the tools available to your agent. ## Supported interfaces | Interface | Description | | - | - | | [CLI](/agentic-toolbox/cli) | Run `qodo review` from the command line or scripts to review local changes before opening a pull request. | | [MCP](/agentic-toolbox/mcp) | Integrate Reviewer with any MCP-compatible client or agent. | | [Claude plugin](/agentic-toolbox/claude-code-plugin) | Access Reviewer from Claude Code through the bundled pre-pr-review skill. | | [Codex plugin](/agentic-toolbox/codex-plugin) | Access Reviewer directly from Codex. | | [Kiro Power](/agentic-toolbox/kiro-power) | Access Reviewer directly from Kiro. | ## What you can do With Reviewer, you can: * Review local, uncommitted changes before a pull request exists. * Include new, untracked files in the review automatically. * Attach coding-session context, such as a summary, decisions, and ticket, spec, or design links. * Scope a review to specific files or directories using git pathspecs. * Choose a fast single-pass review or a deeper review per run. * Get machine-readable findings for use in automated or looping workflows. ## Common use cases ### Review changes before opening a pull request Catch issues in your working tree while you are still editing, before a pull request reviewer sees the diff. Use it to: * Review your working tree against a base branch before pushing. * Catch issues while the change is still fresh in context. * Fix findings immediately instead of after a pull request review. * Confirm a diff is clean before opening a pull request. **Example questions** * Review my changes before I open a pull request. * What issues would a reviewer flag in this diff? * Check this before I push. **Example workflow** ```text theme={null} qodo review Reviewing acme/widgets @ a1b2c3d4e, 3.2KB of local changes Correctness/action_required → Off-by-one in pagination cursor (src/api/list.ts) Security/action_required → Unescaped input in a shell command (src/jobs/run.ts) 2 finding(s), fixed before any pull request exists ``` ### Provide context a forge reviewer cannot see Give the review engine the intent and decisions behind a change, not just the diff. Use it to: * Attach a summary of what changed and why. * Record deliberate decisions so the reviewer does not re-flag them as issues. * Link the ticket, spec, or design the change is based on. * Reduce false positives caused by missing intent. **Example questions** * Attach my reasoning to this review. * Include the linked ticket in the review context. * Why would the reviewer flag something I did on purpose? ### Scope reviews to specific files or directories Limit a review to the part of the change that matters right now. Use it to: * Limit the review to a subset of the diff using git pathspecs. * Focus on hand-written code and skip generated files. * Review a large branch incrementally, directory by directory. * Combine path scoping with a specific base branch. **Example questions** * Review only the changes under `src/api`. * Check just this directory before I commit the rest. * Review everything except the generated files. ### Choose the right review depth Match review thoroughness to how risky the change is. Use it to: * Run a fast, single-pass review during a tight edit loop. * Run a deeper review before a significant pull request. * Let the reviewer choose automatically when depth does not matter. * Balance thoroughness against latency and cost. **Example questions** * Give this a quick check before I commit. * Run the most thorough review you can before I open this pull request. * What depth should I use for a small fix? ## Frequently asked questions Reviewer uses your local Git diff, including new untracked files, plus any coding-session context you provide, such as a summary, decisions, and ticket, spec, or design links, to generate findings. No. Only the base commit you are comparing against needs to be pushed, since the review engine clones it from your Git provider. Your local changes can remain uncommitted and unpushed. No. Reviewer helps catch issues before a pull request exists. Pull request review continues to validate the final, pushed changes and catch anything introduced afterward. No. Reviewer returns findings for the agent to evaluate and act on. Applying a fix remains part of the agent's editing workflow. Yes. Reviewer is in Beta, available to everyone. It's a newer capability that continues to improve based on usage and feedback. ## Related resources * [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview): Learn about the available skills, supported interfaces, and installation. * [Qodo tools overview](/agentic-toolbox/qodo-tools-overview): A high-level summary of tool groups and suggested workflows. * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows): Common workflows for using the Agentic Toolbox skills together. # Agentic Toolbox: Codebase Wisdom skill Source: https://docs.qodo.ai/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill Give your coding agent codebase context, repository relationships, and Git history to understand changes and make informed decisions. Codebase Wisdom is one of the skills in the [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview). It gives AI agents a deep understanding of your codebase and Git history. Instead of manually searching repositories, pull requests, or Git history, you can ask questions in natural language and receive answers grounded in your organization's codebase. Codebase Wisdom combines information from your repositories, repository relationships, pull request history, and current Git state to help you understand your architecture, assess the impact of changes, investigate issues, and build context quickly. The Codebase Wisdom skill uses Qodo tools to access this information. The tools provide the underlying capabilities that let your agent search repositories, inspect files and Git history, explore pull requests, and understand relationships between repositories. See [Qodo tools](/agentic-toolbox/qodo-tools-overview/) for an overview of the tools available to your agent. The same capability is available through multiple interfaces, allowing you to use it wherever you work. ## Supported interfaces | Interface | Description | | - | - | | [CLI](/agentic-toolbox/cli) | Query Codebase Wisdom from the command line or scripts. | | [MCP](/agentic-toolbox/mcp) | Integrate Codebase Wisdom with any MCP-compatible client or agent. | | [Claude plugin](/agentic-toolbox/claude-code-plugin) | Use Codebase Wisdom within Claude Code. | | [Codex plugin](/agentic-toolbox/codex-plugin) | Access Codebase Wisdom directly from Codex. | | [Kiro Power](/agentic-toolbox/kiro-power) | Access Codebase Wisdom directly from Kiro. | ## What you can do With Codebase Wisdom, you can: * Understand relationships between repositories, services, and components. * Analyze the impact of proposed changes before writing code. * Explore previous pull requests and implementation history. * Inspect the current state of branches, commits, and pull requests. * Investigate regressions and identify the changes that introduced them. * Build context quickly when working in an unfamiliar part of the codebase. ## Common use cases ### Understand your architecture Explore how repositories, services, and components relate to one another without manually tracing code. Use it to: * Identify which services call a specific API. * Understand dependencies between repositories. * Discover how data flows through your system. * Learn how an unfamiliar feature is implemented. **Example questions** * How does authentication work in the payments service? * Which services depend on the billing API? * How does a checkout request flow through the system? ### Analyze the impact of a change Before modifying code, understand what the change could affect across your organization. Use it to: * Identify dependent repositories. * Evaluate the scope of a change. * Reduce the risk of introducing breaking changes. * Plan work across multiple repositories. **Example questions** * What would break if I changed this interface? * Which repositories depend on this library? * What services would be affected by changing this API? ### Learn from previous implementations Discover how similar problems were solved in the past by searching your pull request history. Use it to: * Find previous implementations. * Understand design decisions. * Reuse existing patterns. * Avoid duplicating work. **Example questions** * How did we implement rate limiting? * When was OAuth added? * Who introduced this feature? ### Understand current development Get visibility into your current development activity without leaving your workflow. Use it to: * Review open pull requests. * Check active branches. * See recent commits. * Determine whether work is already in progress. **Example questions** * What pull requests are currently open? * Has anyone started implementing feature flags? * What recently changed in the billing service? ### Investigate regressions Quickly identify the changes that may have introduced a bug or unexpected behavior. Use it to: * Trace regressions to recent changes. * Understand what changed before an issue appeared. * Correlate Git history with affected components. * Speed up root cause analysis. **Example questions** * Why did the checkout start failing last week? * Which recent changes affected authentication? * What changed before this test began failing? ### Onboard to a new codebase Build context quickly when joining a new project or working in an unfamiliar area. Use it to: * Understand how repositories fit together. * Learn the architecture of a service. * Explore historical development. * Find relevant implementation examples. **Example questions** * Explain the payments architecture. * How are these repositories connected? * Where should I start if I'm working on authentication? ## Frequently asked questions Codebase Wisdom combines information from your codebase, repository relationships, pull request history, and your current Git state to answer questions with relevant context. Yes. Codebase Wisdom understands relationships across repositories and can answer questions that span multiple services or projects. No. In addition to historical pull request data, Codebase Wisdom can use your current Git state to answer questions about active branches, open pull requests, and work currently in progress. ## Related resources * [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview) * [Qodo tools overview](/agentic-toolbox/qodo-tools-overview): A high-level summary of tool groups and suggested workflows. * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows): Common workflows for using the Agentic Toolbox skills together. # Agentic Toolbox: Get Rules skill Source: https://docs.qodo.ai/agentic-toolbox/agentic-toolbox-get-rules-skill Provide your coding agent with the rules and guardrails that apply to a task before implementation begins. Research Preview Get Rules is one of the skills in the [Qodo Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview). It enables your coding agent to retrieve the coding rules and guardrails that apply to a task before implementation begins. Instead of discovering standards during code review, your agent loads the relevant rules upfront and uses them while generating code. Get Rules combines global rules, repository-specific rules, and contextual guidance to provide your agent with the standards required for the current task. The agent uses these rules as guardrails from the first line of code, helping teams enforce engineering standards during authoring rather than after changes are completed. The Get Rules skill uses Qodo tools to access this information. The tools provide the underlying capabilities that let your agent search repositories, inspect files and Git history, explore pull requests, and understand relationships between repositories. See [Qodo tools](/agentic-toolbox/qodo-tools-overview/) for an overview of the tools available to your agent. ## Supported interfaces | Interface | Description | | - | - | | [CLI](/agentic-toolbox/cli) | Retrieve applicable rules from the command line or scripts. | | [MCP](/agentic-toolbox/mcp) | Integrate Get Rules with any MCP-compatible client or agent. | | [Claude plugin](/agentic-toolbox/claude-code-plugin) | Access Get Rules within Claude Code. | | [Codex plugin](/agentic-toolbox/codex-plugin) | Access Get Rules directly from Codex. | | [Kiro Power](/agentic-toolbox/kiro-power) | Access Get Rules directly from Kiro. | ## What you can do With Get Rules, you can: * Provide agents with the rules that apply to the current task. * Include global standards alongside repository-specific guidance. * Apply engineering conventions before code is written. * Reduce review findings caused by missing standards. * Keep implementation aligned with team requirements. * Ensure agents follow the same guardrails used across projects. ## Common use cases ### Apply rules before writing code Give your agent the relevant standards before implementation starts. Use it to: * Load applicable rules for a task. * Understand required conventions before making changes. * Guide implementation decisions from the beginning. * Avoid introducing issues that would later be caught during review. **Example questions** * What rules apply to this task? * Load the relevant guidelines before implementing this change. * What standards should I follow for this feature? **Example workflow** ```text theme={null} get-rules task: add retries to the payments client Global → Error handling: no silent catches Payments → Idempotency keys on every write Repo → Structured logging conventions Loaded before the first line is written ``` ### Apply organization-wide standards Ensure agents follow global engineering requirements across repositories. Use it to: * Apply shared coding standards. * Enforce organization-level practices. * Keep implementations consistent across teams. * Avoid relying only on repository-local instructions. **Example questions** * What global rules apply here? * Which organization standards should I follow? * Are there any required practices for this change? ### Follow repository-specific conventions Use repository context to apply local implementation requirements. Use it to: * Load repository-specific rules. * Follow existing project conventions. * Match patterns already used in the codebase. * Reduce inconsistency between changes. **Example questions** * What rules apply to this repository? * What conventions should I follow for this service? * Load the repository guidelines before making this change. ### Build with context-specific guardrails Ensure the agent receives rules that match the current task. Use it to: * Combine multiple rule sources. * Apply only relevant guidance. * Adapt implementation based on the task context. * Keep standards available during development. **Example questions** * Which rules apply to adding this API endpoint? * What guardrails should I consider for database changes? * What standards apply to this component? ## Frequently asked questions Get Rules uses the available rule sources, including global rules, repository rules, and task-specific context, to provide the agent with applicable guidance. No. Get Rules includes applicable global rules in addition to repository-specific rules, ensuring that organization-wide standards are applied. Rules are loaded before implementation begins, allowing the agent to use them while generating code rather than discovering issues during review. No. Get Rules helps prevent issues by guiding implementation. Code review continues to validate changes and identify additional concerns. No. Get Rules provides the agent with applicable guidance. The agent uses this context when performing the requested task. ## Related resources * [Qodo Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview): Learn about the available skills, supported interfaces, and installation. * [Qodo tools overview](/agentic-toolbox/qodo-tools-overview): A high-level summary of tool groups and suggested workflows. * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows): Common workflows for using the Agentic Toolbox skills together. # Agentic Toolbox overview Source: https://docs.qodo.ai/agentic-toolbox/agentic-toolbox-overview The Agentic Toolbox provides Qodo capabilities to your coding agent throughout the development workflow. The Qodo Agentic Toolbox brings Qodo's code understanding, coding standards, and review capabilities into your existing coding agent. It does not replace your coding agent or require you to interact with Qodo directly; it extends your agent with Qodo capabilities that support key stages of your agentic workflow. After you install the Agentic Toolbox, continue working with your coding agent as usual. The Agentic Toolbox enables your agent to automatically apply Qodo capabilities for understanding your codebase, applying team standards, reviewing changes, and resolving findings. The Agentic Toolbox is a separate product from the deprecated Qodo Command CLI (`@qodo/command`) and Qodo Gen CLI. When you install the Agentic Toolbox, it makes a best effort to remove an existing Qodo Command installation. In some cases, the old installation may not be detected and removed, for example if it was installed under a different Node.js version or through a symlink. If the old installation remains, remove it manually before using the Agentic Toolbox. ## Qodo tools powering the Agentic Toolbox The Agentic Toolbox skills use Qodo tools to access the capabilities they need to complete their workflows. The tools are organized into groups based on the type of work they support: * **Codebase**: Understand and search your repositories and code. * **Cross-repo**: Understand relationships and dependencies across repositories. * **Pull request**: Learn from previous pull requests and code review history. * **PR review**: View and manage findings from Qodo code reviews. * **Skills**: Use skills that guide your agent’s work. * **Rules**: Find coding rules that apply to your task. See [Qodo tools](/agentic-toolbox/qodo-tools-overview) for an overview of the available tools and how to access them. For the full list of tools and commands, see the [Qodo tools reference](/agentic-toolbox/qodo-tools-reference). The Agentic Toolbox extends Qodo Code Review into your local development workflow. After you open a pull request, Qodo Code Review continues to provide automated review and collaboration directly in your pull request workflow. ## Supported interfaces The Agentic Toolbox is available through the following interfaces. | Interface | Description | | - | - | | [CLI](/agentic-toolbox/cli) | Use Qodo tools from the command line and scripts. | | [MCP](/agentic-toolbox/MCP) | Connect any MCP-compatible client or coding agent. | | Claude Code plugin | Access Qodo tools directly from Claude Code. | | Codex plugin | Access Qodo tools directly from Codex. | | Kiro Power | Access Qodo tools directly from Kiro. | ## Agentic Toolbox skills The Agentic Toolbox provides skills for different stages of your agentic workflow. Your coding agent accesses these skills through agent skills. | Tool | Stage | Description | | - | - | - | | **Review** | **Review** | Runs Qodo Review on local changes using the same review engine used for pull request reviews. | | **Review Resolver** | **Resolve** | Retrieves and resolves Qodo Review findings directly from the agent workflow. | | **Codebase Wisdom** | **Understand** | Provides your agent with codebase context to understand dependencies, impact, and recent changes before implementation. | | **Manage Standards** | **Govern** | Lets you manage your organization's Review Standards, including creating, updating, retiring, re-scoping, and triaging rule suggestions. | | **Get Rules** (Optional) | **Write** | Retrieves the rules that apply to the current task before code is generated. | ## How Agentic Toolbox skills stay up to date Agentic Toolbox skills are included with your Agentic Toolbox installation. During interactive use, the Agentic Toolbox periodically checks for updates and installs a newer version in the background when one is available. The updated version is used the next time you run a `qodo` command. After the Agentic Toolbox updates, the next `qodo` command refreshes installed, Qodo-managed skills from the skill set included with the installed version. You can also run `qodo update` to check for and install an update manually. By default, the Agentic Toolbox also adds newly released recommended skills to coding agent environments where you already installed Qodo skills. It does not add skills to environments where you have not installed any Qodo skills, and it does not overwrite skills that you own or have customized. ## Configure coding agent instructions Coding agents can use the Agentic Toolbox more effectively when its instructions are included in their agent instruction file. Add the Qodo Agentic Toolbox instructions below to your agent instruction file, such as AGENTS.md or CLAUDE.md, to help the agent use the Toolbox effectively throughout its workflow. ### For coding agents ``` Read the [Default template](/agentic-toolbox/agentic-toolbox-overview#default-template) before using the Agentic Toolbox. Add the template's instructions to the appropriate agent instruction file, then follow those instructions throughout your workflow. ``` ### Default template Copy the following into your agent instruction file: ``` Read the [Default template](/agentic-toolbox/agentic-toolbox-overview#default-template) before using the Agentic Toolbox. Add the template's instructions to the appropriate agent instruction file, then follow those instructions throughout your workflow. ``` ## Qodo Agentic Toolbox * Use the installed Qodo skills whenever they are relevant or can provide useful context; let the skill choose the current Qodo commands and flags. * For coding or code-review tasks, load relevant Qodo Review Standards when they can affect the work. Apply the rules that fit this repository and stack, and do not fetch them again in the same session if already loaded. * When an answer depends on unfamiliar code, debugging or regression analysis, historical precedent, cross-repository impact, or technical documentation that describes real behavior, do not guess—check using Qodo's codebase and pull-request knowledge. Cite the repository, file/line, pull request, or commit behind important claims; distinguish verified facts from inference. * Before opening a pull request, run Qodo's local pre-PR review with context describing what changed, why, key decisions, and links to the ticket or design. Evaluate every finding against the code and intent; fix only findings that are sound and in scope. * After a pull request exists, use Qodo's structured PR review findings rather than scraping rendered review comments. Confirm the review is complete and covers the relevant commit, then apply the findings in the context of the code, task intent, and user direction. Explain what you fix and anything you deliberately leave unchanged. * Perform one review-and-fix pass by default. Continue with another round when it is useful to validate meaningful fixes or when the user requests it, within an agreed limit. Finish when the applicable findings are addressed or another round would not produce meaningful progress, and report what remains. * Use read-only Qodo discovery autonomously when relevant. When the work reveals a durable convention, offer to contribute it as a Qodo Review Standard; non-admin contributions become pending suggestions for admin review. Ask before creating a suggestion, administering standards, or performing forge mutations. * On authentication errors, run `qodo whoami` to diagnose the current identity/session and run `qodo login` when authentication is missing or invalid. If Qodo remains unavailable, gated, or rate-limited, report that clearly and continue with local evidence when safe; do not retry in a loop. ``` ## Get started Choose the installation method that fits your setup: - [CLI](/agentic-toolbox/cli) - [MCP](/agentic-toolbox/mcp) - [Claude](/agentic-toolbox/claude-code-plugin) - [Codex](/agentic-toolbox/codex-plugin) - [Kiro Power](/agentic-toolbox/kiro-power) Then proceed to using the Agentic Toolbox with these skills and workflows: - [Review](/agentic-toolbox/agentic-toolbox-codebase-review-skill): Reviews your local changes using the same Qodo Review capabilities used for pull request reviews. - [Review Resolver](/agentic-toolbox/agentic-toolbox-review-resolver-skill): Retrieves and resolves Qodo Review findings from your agent workflow. - [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows): See example workflows for building features, debugging issues, and combining Agentic Toolbox capabilities into a repeatable development process. - [Codebase Wisdom](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill): Gives your agent context about your codebase, including dependencies, cross-repository relationships, and recent changes. - [Get Rules](/agentic-toolbox/agentic-toolbox-get-rules-skill): Retrieves the coding rules and standards that apply to the current task. - [Manage Standards](/agentic-toolbox/manage-standards-skill): Lets authorized users manage review standards and rule suggestions directly from their agent. ``` # Agentic Toolbox: Review Resolver skill Source: https://docs.qodo.ai/agentic-toolbox/agentic-toolbox-review-resolver-skill Retrieve and resolve Qodo Review findings directly from your coding agent. Review Resolver is one of the skills in the [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview). It enables your coding agent to retrieve and resolve Qodo Review findings directly from the agent workflow. After Qodo reviews an open pull request and posts findings, your agent can retrieve those findings, understand their context, and resolve them without leaving the development flow. Review Resolver combines Qodo Review findings with repository context to help investigate issues, apply fixes, and track the resolution status of every finding. The agent follows your instruction as a scope filter over the findings. It resolves only the findings you request, whether based on severity, category, a specific finding, or report-only mode. Every finding has an explicit outcome: * **Fixed** with an applied change. * **Skipped** with a reason. * **Reported** without changes. Review Resolver does not blindly apply fixes. It operates within the scope of your request and ensures that findings are never silently ignored. The Review Resolver skill uses Qodo tools to access this information. The tools provide the underlying capabilities that let your agent search repositories, inspect files and Git history, explore pull requests, and understand relationships between repositories. See [Qodo tools](/agentic-toolbox/qodo-tools-overview/) for an overview of the tools available to your agent. ## Supported interfaces | Interface | Description | | - | - | | [CLI](/agentic-toolbox/cli) | Resolve findings from the command line or scripts. | | [MCP](/agentic-toolbox/mcp) | Integrate Review Resolver with any MCP-compatible client or agent. | | [Claude plugin](/agentic-toolbox/claude-code-plugin) | Resolve Qodo Review findings within Claude Code. | | [Codex plugin](/agentic-toolbox/codex-plugin) | Resolve Qodo Review findings directly from Codex. | | [Kiro Power](/agentic-toolbox/kiro-power) | Resolve Qodo Review findings directly from Kiro. | ## What you can do With Review Resolver, you can: * Retrieve Qodo Review findings from an open pull request. * Resolve findings directly from your coding agent workflow. * Scope which findings should be addressed. * Apply fixes based on the finding context. * Track which findings were fixed, skipped, or reported. * Avoid manually switching between review results and your code editor. * Keep control over which findings are modified. ## Common use cases ### Resolve review findings Resolve issues identified by Qodo Review after a pull request is opened. Use it to: * Retrieve findings from the current pull request. * Understand the reported issue. * Apply the required code changes. * Verify the resolution. **Example questions** * Resolve the security findings from my pull request. * Fix all high-severity findings. * Resolve this specific finding. **Example workflow** ```text theme={null} finding-resolver · PR #482 > resolve the security findings from my PR SQL injection in query builder → Fix applied Unsanitized header in auth proxy → Fix applied Missing structured log fields → Skipped · out of scope ``` ### Control the scope of resolution Specify exactly which findings the agent should address. Use it to: * Filter findings by category. * Select a specific finding. * Limit changes to a requested scope. * Run in report-only mode. **Example questions** * Resolve only security findings. * Fix this finding only. * Review findings but do not apply changes. * Report findings without modifying code. ### Understand skipped findings See why findings were not changed. Use it to: * Understand skipped findings. * Confirm that no findings were silently ignored. * Review whether additional action is needed. **Example questions** * Why was this finding skipped? * Show me unresolved findings. * Which findings are outside the requested scope? ### Keep the pull request clean Continue resolving findings until the pull request meets the required quality level. Use it to: * Address remaining review feedback. * Re-run resolution after changes. * Ensure findings are either resolved or explicitly handled. **Example questions** * Resolve the remaining findings. * Check if my pull request is clean. * Fix all reported issues that are in scope. ## Frequently asked questions Review Resolver uses Qodo Review findings together with repository context to understand issues and apply appropriate fixes. No. Review Resolver only acts on findings that match your instruction. It does not widen the scope of the request. Every finding has an explicit outcome. A finding is either fixed, skipped with a reason, or reported without changes. No. Review Resolver uses the finding context and your requested scope to determine which changes to make. Yes. You can scope resolution by severity, category, individual finding, or report-only mode. ## Related resources * [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview) * [Qodo tools overview](/agentic-toolbox/qodo-tools-overview): A high-level summary of tool groups and suggested workflows. * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows): Common workflows for using the Agentic Toolbox skills together. # Suggested workflows for Agentic Toolbox Source: https://docs.qodo.ai/agentic-toolbox/agentic-toolbox-suggested-workflows Use Qodo Agentic Toolbox to guide your coding agent through development, review, and debugging workflows. Qodo Agentic Toolbox gives your coding agent capabilities for understanding your codebase, applying project rules, reviewing changes, and resolving review findings. You can use these capabilities independently or combine them into a workflow that fits how you work. The workflows below are examples you can use as a starting point and adapt to your development process. ## Build a feature Use the toolbox to guide your agent from exploring the codebase through reviewing the final changes. ### 1. Explore the codebase Before making changes, ask your agent to understand the relevant parts of the codebase. Use [Codebase Wisdom](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill) to explore: * How the existing implementation works * Related components and dependencies * Existing patterns and conventions * Potential edge cases * The impact of changing shared interfaces For example: > Explore how the checkout flow currently works. Identify the relevant components, dependencies, existing patterns, and potential edge cases. Don't make any changes yet. ### 2. Plan the implementation Ask your agent to propose an implementation plan before writing code. The plan should consider: * The relevant code and existing patterns * Project rules and available skills * Potential edge cases and regression risks * Tests that should be added or updated Review the plan and adjust it before asking the agent to implement it. ### 3. Implement using project guidance Ask your agent to check the rules and skills available for the task and apply any that are relevant. For example: > Before implementing, check the available project rules and skills. Use any that are relevant to this feature. Keep the implementation focused on the approved plan and existing project conventions. ### 4. Review local changes After implementation, use [Review](/agentic-toolbox/agentic-toolbox-codebase-review-skill) to review the local changes before creating a pull request. You can run the review as a loop: > Review the current changes. Focus on correctness, error handling, and regression risks. Fix the issues you find, then run the review again. You can limit the number of review iterations if you want to control how long the agent spends reviewing. You can also give the agent specific areas to focus on based on issues your team has encountered before: > Review these changes with particular attention to retry behavior. Similar changes in this area have caused duplicate requests in the past. ### 5. Create the pull request Once the local changes meet your requirements, create the pull request using your normal workflow. ### 6. Review and resolve findings After Qodo reviews the pull request, use [Review Resolver](/agentic-toolbox/agentic-toolbox-review-resolver-skill) to have your agent evaluate and resolve Qodo's findings before merging. Give the agent guidance about which findings to prioritize: > Review Qodo's findings. Prioritize correctness and security issues. For each finding, determine whether it is valid before making a change. Ignore findings that are intentional based on the existing architecture. ## Debug an issue You can use a similar workflow when investigating and fixing a bug. ### 1. Investigate the issue Ask your agent to trace the relevant code path and identify the likely root cause. For example: > Investigate this bug. Trace the relevant code path, identify the likely root cause, and look for similar implementations or previous fixes. Don't make changes yet. Use [Codebase Wisdom](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill) to help your agent understand the codebase and its history. ### 2. Plan the fix Ask the agent to explain the root cause and propose a focused fix. Have it consider: * Why the current behavior occurs * Which code needs to change * Potential edge cases * Regression risks * Tests needed to verify the fix Review the proposed fix before asking the agent to implement it. ### 3. Implement and review Ask the agent to implement the fix using the relevant project rules and skills. Then use [Review](/agentic-toolbox/agentic-toolbox-codebase-review-skill) to review the local changes. Ask the agent to focus on regression risks and related code paths. For example: > Review this bug fix with particular attention to regression risks and other code paths that could be affected. Fix valid issues and run the review again. Repeat the review until the changes meet your requirements, or set a maximum number of review iterations. ### 4. Verify the fix Run the relevant tests and verify that the original problem is resolved. Ask the agent to confirm that the fix addresses the root cause rather than only the observed symptom. ### 5. Resolve pull request findings After creating the pull request, use [Review Resolver](/agentic-toolbox/agentic-toolbox-review-resolver-skill) to review Qodo's findings before merging. Give the agent additional context about the bug when deciding which findings require changes. ## Customize your workflow The workflows above are starting points, not required processes. Adapt them to your development process and the capabilities available in your coding agent. You can: * Add steps that are specific to your team's development process. * Give your agent specific review areas based on previous issues. * Set a maximum number of review iterations. * Change which Qodo capabilities your agent uses at each stage. * Add your preferred workflow instructions to your agent's `AGENTS.md` or equivalent configuration. For example, you might create a workflow that always asks your agent to: 1. Explore the relevant code before making changes. 2. Propose a plan and identify edge cases. 3. Check applicable rules and skills. 4. Implement the change. 5. Run a local review and resolve valid findings. 6. Create the pull request. 7. Use Review Resolver to evaluate Qodo's findings before merging. The goal is to give your agent a repeatable process that combines its existing capabilities with Qodo's code understanding, rules, review, and finding-resolution capabilities. ## Related resources * [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview): Learn about the Agentic Toolbox, its skills, supported interfaces, and installation. * [Codebase Wisdom](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill): Help your agent understand your codebase and its history. * [Review](/agentic-toolbox/agentic-toolbox-codebase-review-skill): Review local changes before creating a pull request. * [Review Resolver](/agentic-toolbox/agentic-toolbox-review-resolver-skill): Evaluate and resolve Qodo review findings. # Install Qodo with Claude Source: https://docs.qodo.ai/agentic-toolbox/claude-code-plugin Install Qodo to use Qodo code review capabilities with Claude. Use Qodo with Claude to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review findings. For an overview of the available skills and supported interfaces, see [Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview/). Install Qodo to use Qodo code review capabilities with Claude. ## Prerequisites You need a Qodo account to use the Agentic Toolbox skills. ## Install Qodo with Claude 1. Go to [Claude plugins](https://claude.com/plugins). Claude plugins main page 2. Navigate to **Browse Plugins**. Browse Claude plugins 3. Type **Qodo** in the search field. The Qodo plugin main page opens. Qodo Claude Code page 4. Click the **Copy icon** to copy the installation command. 5. Follow the instructions to install the Qodo plugin in Claude Code. Once installed, you can use Qodo with Claude Code. ## Next steps * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows) * [Review skill](/agentic-toolbox/agentic-toolbox-codebase-review-skill) * [Review Resolver skill](/agentic-toolbox/agentic-toolbox-review-resolver-skill) * [Codebase Wisdom skill](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill) * [Manage Standards skill](/agentic-toolbox/manage-standards-skill) * [Get Rules skill (Optional)](/agentic-toolbox/agentic-toolbox-get-rules-skill) # Install Qodo Agentic Toolbox with the CLI Source: https://docs.qodo.ai/agentic-toolbox/cli Install the Qodo Agentic Toolbox locally to use Qodo-managed skills with your coding agent. Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally. For remote or custom agents, workflows, or applications, use [MCP](../mcp). With the CLI, your coding agent can use Qodo's code understanding and review capabilities as part of your local development workflow. For example, you can: * Review changes before opening a pull request. * Retrieve and resolve review findings. * Understand your codebase, including dependencies, relationships, and recent changes. * Retrieve the rules and standards that apply to a task. * Access and manage Review Standards. You install the Qodo Agentic Toolbox locally to make Qodo-managed skills available to your agent. You can install the Agentic Toolbox without a Qodo account, but you need to sign in to Qodo to use its managed skills. For more information about choosing between the CLI and MCP, see [Agentic Toolbox overview](./agentic-toolbox-overview). The Agentic Toolbox is a separate product from the deprecated Qodo Command CLI (`@qodo/command`) and Qodo Gen CLI. If you have an existing Qodo Command installation, installing the Agentic Toolbox replaces it automatically. You don't need to uninstall it separately. ## Prerequisites Before you install, make sure you have: * Node.js 20 or later. ## Install the Agentic Toolbox The installation command below is for Qodo single-tenant and multi-tenant deployments. If you use Qodo on-premises, get the installation command for your deployment from the Home page in your Qodo portal. ### macOS and Linux This includes Git Bash and WSL. ```bash theme={null} curl -fsSL https://get.qodo.ai | sh ``` ### Windows PowerShell Administrator privileges are not required. ```powershell theme={null} powershell -ExecutionPolicy Bypass -Command "irm https://get.qodo.ai/install.ps1 | iex" ``` The installer installs the Qodo Agentic Toolbox and configures the available Qodo skills for supported agent environments. You can install the Agentic Toolbox without a Qodo account. To use Qodo skills, sign up or log in to Qodo when prompted by your agent. ## Troubleshooting Make sure you are using Node.js 20 or later and that your operating system meets the requirements for the installation command you are using. If the installation still fails, run the installation command again and check the error message for details. Make sure your coding agent is supported and restart or reload the agent after installing the Agentic Toolbox. If the skills still do not appear, verify that you are signed in to Qodo and have access to the required workspace and repositories. Make sure you are signed in to Qodo and that your account has access to the repositories you want to work with. If your access has changed, sign in again and restart your coding agent. ## Next steps * [Agentic Toolbox overview](./agentic-toolbox-overview): Learn about Qodo Agentic Toolbox managed skills and when to use the CLI or MCP. * [Suggested workflows](./agentic-toolbox-suggested-workflows): Guide your coding agent through development, review, and debugging workflows. # Install Qodo with the Codex agent Source: https://docs.qodo.ai/agentic-toolbox/codex-plugin Install the Qodo plugin to use Qodo code review capabilities with the Codex agent. Use the Qodo plugin with the Codex agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review findings. For an overview of the available skills and supported interfaces, see [Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview/). Install the Qodo plugin to use Qodo code review capabilities with the Codex agent. ## Prerequisites You need a Qodo account to use the Agentic Toolbox skills. ## Install the Qodo plugin 1. Open **ChatGPT on Desktop**, and select **Codex**. 2. click **Plugins** in the left navigation bar. The **Plugins** page opens. Codex main plugin page 3. Type **Qodo** in the search field. The Qodo plugin appears in the search results. Codex plugin install 4. Click **+** next to Qodo to install the plugin. Once installed, you can use Qodo with your Codex agent. ## Next steps * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows) * [Review skill](/agentic-toolbox/agentic-toolbox-codebase-review-skill) * [Review Resolver skill](/agentic-toolbox/agentic-toolbox-review-resolver-skill) * [Codebase Wisdom skill](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill) * [Manage Standards skill](/agentic-toolbox/manage-standards-skill) * [Get Rules skill (Optional)](/agentic-toolbox/agentic-toolbox-get-rules-skill) # Install Qodo with Kiro Source: https://docs.qodo.ai/agentic-toolbox/kiro-power Install Qodo to use Qodo code review capabilities with the Kiro agent. Use Qodo with the Kiro agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review findings. For an overview of the available skills and supported interfaces, see [Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview/). Install Qodo to use Qodo code review capabilities with the Kiro agent. ## Prerequisites You need a Qodo account to use the Agentic Toolbox skills. ## Install Qodo in Kiro 1. Go to [Kiro Powers](https://kiro.dev/powers/). 2. Scroll down to **Browse Powers**. 3. Type **Qodo** in the search field. The Qodo Power page opens. Kiro Powers main page 4. Click **Open in Kiro**. 5. Follow the prompts in Kiro to complete the installation. Installing Qodo in Kiro Once installed, you can use Qodo with your Kiro agent. ## Next steps * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows) * [Review skill](/agentic-toolbox/agentic-toolbox-codebase-review-skill) * [Review Resolver skill](/agentic-toolbox/agentic-toolbox-review-resolver-skill) * [Codebase Wisdom skill](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill) * [Manage Standards skill](/agentic-toolbox/manage-standards-skill) * [Get Rules skill (Optional)](/agentic-toolbox/agentic-toolbox-get-rules-skill) # Manage access to the Agentic Toolbox Source: https://docs.qodo.ai/agentic-toolbox/manage-access-in-qodo-portal Control which users in your workspace can access the Qodo Agentic Toolbox in the Qodo portal. Workspace admins can control which users have access to the Qodo Agentic Toolbox. By default, the Agentic Toolbox is enabled for everyone in the workspace. ## Set access in the Qodo portal 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Agentic Toolbox**. Agentic toolbox tab of the Configurations page showing the Access setting 3. Select an access option: * **Everyone**: All users in the workspace can access the Agentic Toolbox. * **No one**: No users in the workspace can access the Agentic Toolbox. * **Only specific people**: Only the users you select can access the Agentic Toolbox. Select **Add users** to choose which users have access. * **Everyone except specific people**: All users in the workspace can access the Agentic Toolbox except the users you select. 4. Click **Save changes**. ## Related resources * [Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview) # Agentic Toolbox: Manage Standards skill Source: https://docs.qodo.ai/agentic-toolbox/manage-standards-skill Let your coding agent administer your organization's Review Standards, capture conventions as new rules, edit or retire existing ones, and triage pending suggestions. Manage Standards is an opt-in skill (`recommended: false`), so it isn't enabled for all users by default because every command writes to your workspace's standards. You'll also need the Agentic Toolbox installed and authenticated (`qodo whoami`). Let your coding agent administer your organization's Review Standards, capture a convention as a new rule, edit or retire an existing one, re-scope it to a repository, and triage pending suggestions, all from the conversation. Manage Standards is one of the skills in the [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview). Review Standards is Qodo's umbrella term for the rules and pending suggestions that govern code quality and consistency across your repositories. Where `qodo-get-rules` is the read path, fetching relevant rules so your agent writes compliant code from the start, Manage Standards is the write path. Every command it runs changes workspace state, so it confirms with you before acting and runs bulk or destructive operations as a dry run first. The Manage Standards skill uses Qodo tools to access this information. The tools provide the underlying capabilities that let your agent search repositories, inspect files and Git history, explore pull requests, and understand relationships between repositories. See [Qodo tools](/agentic-toolbox/qodo-tools-overview/) for an overview of the tools available to your agent. ## Supported interfaces The Agentic Toolbox is available through the following interfaces. | Interface | Description | | - | - | | [CLI](/agentic-toolbox/cli) | Administer Qodo Review Standards from the command line or scripts. | | [MCP](/agentic-toolbox/mcp) | Connect any MCP-compatible client or coding agent. | | [Claude plugin](/agentic-toolbox/claude-code-plugin) | Administer Qodo Review Standards within Claude Code. | | [Codex plugin](/agentic-toolbox/codex-plugin) | Access Manage Standards directly from Codex. | | [Kiro Power](/agentic-toolbox/kiro-power) | Access Manage Standards directly from Kiro. | ## What you can do With Manage Standards, you can: * Capture a convention you just agreed on in conversation as a new rule. * Edit an existing rule's category, severity, or content. * Activate, deactivate, or re-scope one or more rules for specific repositories. * Triage the pending suggestions queue by accepting and activating suggestions or rejecting them. * Run bulk operations (activate, deactivate, re-scope, accept, reject) across multiple rules, with a dry run first. Whether a change takes effect immediately or becomes a pending suggestion depends on your permissions. Changes made by admins become active immediately, while rule changes created by other users are submitted as pending suggestions for approval. The skill tells you exactly what happened instead of assuming the change was successful. ## Common use cases ### Capture a convention as a rule The strongest signal here is mid-conversation agreement where you and your agent just settled on a convention and want it enforced going forward. Use it to: * Turn a design discussion into an enforceable rule with a name, category, and severity. * Set the right severity for how strict the rule should be: **error** (must comply), **warning** (comply by default), or **recommendation** (apply when appropriate). * Scope the new rule to the current repository, or leave it universal if it should apply workspace-wide. **Example prompts** * "Make this a rule." * "Make a rule for this repo that all new API endpoints must validate input with our schema library." * "We just agreed no more raw SQL string concatenation. That should be an error-level rule." ### Edit or change the lifecycle of a rule Once a rule exists, its content, severity, or state often needs to shift as the codebase and team do. Use it to: * Change what a rule checks for, or its category. * Change the X rule to an error (or downgrade it to a warning or recommendation). * Deactivate or disable a rule that's become noise. * Re-scope a rule to a specific repository, or apply it more broadly. **Example prompts** * "Deactivate the tabs-vs-spaces rule, it's noise." * "Change the console.log rule to an error." * "Re-scope the error-format rule to this repo too." ### Triage pending suggestions and run bulk hygiene Suggestions accumulate for someone to review; hygiene work, such as retiring rules tied to an archived repo, is naturally a batch operation. Use it to: * List and review suggestions waiting for approval. * Accept and activate a suggestion, or reject it. * Bulk deactivate, re-scope, activate, or reject across many rules at once. All bulk operations are previewed with a dry run before they run for real. **Example prompts** * "Show pending suggestions." * "Let's triage suggestions." * "Accept this suggestion." / "Reject this suggestion." * "Bulk deactivate everything scoped to the archived repo." ## Frequently asked questions Manage Standards is an opt-in skill (`recommended: false`), so it isn't enabled for all users by default because every command writes to your workspace's standards. You'll also need the Agentic Toolbox installed and authenticated (`qodo whoami`). You can still create rules, but they're submitted as pending suggestions instead of becoming active rules. This is expected platform behavior, not an error. An admin must approve the suggestion before it's enforced. Other write operations, such as editing, deactivating, re-scoping, or triaging existing rules, require admin permissions. If you don't have the required permissions, the operation is declined. No. Rejecting a suggestion permanently deletes it. Before rejecting a suggestion or running any bulk operation, the skill performs a dry run and shows a summary of the affected rules before making changes. When your intent is ambiguous, it defaults to the reversible option, such as deactivating a rule instead of deleting it. `qodo-get-rules` is read-only. It retrieves and applies the rules relevant to your current task. Manage Standards is the write counterpart. It lets you create, edit, activate, deactivate, re-scope, and triage rules and pending suggestions. ## Related resources * [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview) * [Qodo tools overview](/agentic-toolbox/qodo-tools-overview): A high-level summary of tool groups and suggested workflows. * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows): Common workflows for using the Agentic Toolbox skills together. # Connect Qodo Agentic Toolbox with MCP Source: https://docs.qodo.ai/agentic-toolbox/mcp Connect Qodo Agentic Toolbox managed skills to an MCP-compatible client. Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application. For local development, [Install Qodo Agentic Toolbox with the CLI](/agentic-toolbox/cli). With MCP, your agent can use Qodo's code understanding and review capabilities as part of its workflow. For example, you can: * Understand your codebase, including dependencies, relationships, and recent changes. * Retrieve the rules and standards that apply to a task. * Review changes before opening a pull request. * Retrieve and resolve review findings. * Access and manage Review Standards. You connect your MCP-compatible client to Qodo's MCP server using an API key to make Qodo Agentic Toolbox managed skills available to your agent. You don't need to install the Qodo Agentic Toolbox to use its managed skills through MCP. For more information about choosing between MCP and the CLI, see the [Agentic Toolbox overview](./agentic-toolbox-overview). ## Prerequisites Before you connect, make sure you have: * An MCP-compatible client that supports Streamable HTTP and custom request headers. * Access to the repositories you want to work with in Qodo. * Access to your MCP client's configuration or secure secret management. ## Connect your MCP client ### 1. Create an API key Create a personal API key in the Qodo portal. Follow [Manage API keys in the Qodo portal](/account-management/manage-api-keys) for instructions. ### 2. Add the Qodo MCP server When configuring the Qodo MCP server, use the URL that matches your deployment type: * **SaaS**: `https://sdk.qodo.ai/v1/tools/mcp/` * **Single-tenant (ST) and on-premises**: Get the MCP server URL from the Qodo portal. The URL must include the trailing slash (`/`). Without it, the server returns a 307 redirect. Most MCP clients do not follow this redirect, which causes the connection to fail. If your client accepts an `mcpServers` JSON object and supports custom request headers, use the following configuration: ```json theme={null} { "mcpServers": { "qodo-managed-tools": { "type": "http", "url": "", "headers": { "Authorization": "Bearer ${QODO_API_KEY}" } } } } ``` If your client uses a different configuration format, use these values: | Field | Value | | - | - | | Name | `qodo-managed-tools` | | URL | Your Qodo MCP server URL | | Transport | Streamable HTTP | | Header | `Authorization: Bearer ` | ### 3. Reload your MCP client Restart or reload your MCP client after adding the server configuration. Once connected, verify that Qodo Agentic Toolbox managed skills appear in your client's available skills or tools. The skills available to you depend on your Qodo workspace access and permissions. ## Authentication MCP authenticates requests to Qodo using the API key you created in the Qodo portal. The key is sent in the Authorization header: ``` Authorization: Bearer ``` Keep your API key secure. Do not commit it to source control or include it directly in configuration files that are shared with others. If your MCP client supports secure credentials or secret management, use it to store your API key. ## Use Qodo Agentic Toolbox managed skills After the connection is established, your agent can discover and call the Qodo Agentic Toolbox managed skills available to your workspace. Your agent decides when and how to use the available skills based on the task and the instructions you provide. ## Troubleshooting If the managed skills do not appear after you configure the server: * Confirm that your API key is valid and available to the MCP client. * Confirm that the Authorization header is configured correctly. * Verify that your client supports Streamable HTTP and custom request headers. * Reload or restart the MCP client. * Confirm that you have access to the required repositories in Qodo. API keys can have an expiration period. If your key has expired or been revoked, create a new API key in the Qodo portal and update your MCP configuration. See [Manage API keys in the Qodo portal](/account-management/manage-api-keys). ## Next steps * [Agentic Toolbox overview](./agentic-toolbox-overview): Learn more about Qodo Agentic Toolbox managed skills and when to use MCP or the CLI. # Qodo tools overview Source: https://docs.qodo.ai/agentic-toolbox/qodo-tools-overview Explore the Qodo tools available through the Agentic Toolbox and how to access them from the terminal. The Agentic Toolbox gives your coding agent access to Qodo tools that help it understand your codebase, learn from previous work, review changes, and apply coding standards. The tools are organized into groups based on the type of work they support: | Tool group | What it helps you do | | - | - | | **Codebase** | Understand and search your repositories and code. | | **Cross-repo** | Understand relationships between repositories. | | **Pull request** | Learn from previous pull requests and code review history. | | **PR review** | View and manage findings from Qodo code reviews. | | **Skills** | Use skills that guide your agent's work. | | **Rules** | Find coding rules that apply to your task. | Your agent can combine these tools to understand a task, implement a change, review the result, and resolve review findings. ## Access Qodo tools from the terminal You can view the Qodo tools available in your environment from the terminal: ```bash theme={null} qodo tools ``` This displays the available tool groups and their tools. For example: ``` [READ] qodo codebase find [READ] qodo codebase grep [READ] qodo codebase read-file [READ] qodo cross-repo overview [READ] qodo pull-request similar [READ] qodo pr-review-session findings [READ] qodo rules search ``` You don't need to run this command to use the tools. Your coding agent can access the available Qodo tools as part of its workflow. The tools available to you depend on your Qodo permissions, workspace configuration, and deployment. ## Suggested workflows The tools work together across the development process. * **Understand**: Use Codebase and Cross-repo tools to understand the relevant code and dependencies. * **Implement**: Use Codebase context, Pull request history, Skills, and Rules to guide the implementation. * **Review**: Use Qodo review capabilities and PR review tools to identify issues in your changes. * **Resolve**: Use PR review tools to track findings after making fixes, or dismiss findings that do not require a code change. ## Related resources * [Tools reference](/agentic-toolbox/qodo-tools-reference): A complete list of Qodo tools and their commands. * [Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview): Learn how the Agentic Toolbox works and when to use the CLI or MCP. * [Suggested workflows](/agentic-toolbox/agentic-toolbox-suggested-workflows): Guide your coding agent through development, review, and debugging workflows. # Qodo tools reference Source: https://docs.qodo.ai/agentic-toolbox/qodo-tools-reference A complete list of Qodo tools available through the Agentic Toolbox and their commands. ## Codebase tools The Codebase tools help your agent understand and search your repositories. | Tool | Description | | - | - | | `find` | Find files and directories that match a pattern. | | `ls` | List files and directories at a specific path. | | `read-file` | Read the contents of a file. | | `grep` | Search repository files for matching text or regular expressions. | | `blame` | View the commit, author, and timestamp associated with each line of a file. | | `get-commit` | Get details about a specific commit. | | `list-commits` | List commits filtered by path, reference, or date range. | | `list-branches` | List branches and their head commit SHAs. | | `list-tags` | List tags and their commit SHAs. | | `search-repos` | Find repositories that you have access to. | | `get-issue` | Get an issue and its metadata. | | `list-issues` | List issues filtered by state, labels, or date. | | `search-issues` | Search issues across repositories. | | `get-pr` | Get the contents of a pull request, including metadata, diffs, and review comments. | | `list-prs` | List pull requests filtered by state, base branch, or date. | ## Cross-repo tools The Cross-repo tools help your agent understand relationships between repositories. | Tool | Description | | - | - | | `overview` | Show the relationships between repositories in the workspace. | | `relations` | Show the repositories related to a specific repository and explain the relationships. | | `pair` | Explain the relationship between two specific repositories. | ## Pull request tools The Pull request tools give your agent access to knowledge from previous pull requests and code reviews. | Tool | Description | | - | - | | `details` | Get details about a merged pull request, including its description, files, and review suggestions. | | `patch` | Get the changes made to a specific file in a merged pull request. | | `by-file` | Find merged pull requests that changed a specific file. | | `similar` | Find merged pull requests that are similar to a change or question. | | `review-history` | Find previous code review suggestions for a file or directory and see whether they were accepted. | | `similar-suggestions` | Find previous review suggestions that are similar to a description or code change. | ## PR review tools The PR review tools let your agent inspect and manage findings from Qodo code reviews. | Tool | Description | | - | - | | `findings` | Get the latest review status and current findings for a pull request. | | `mark-implemented` | Mark a finding as implemented after the corresponding fix has been made. | | `dismiss` | Dismiss a finding when no code change is required. | ## Skills tools The Skills tools provide access to skills that guide your agent's work. | Tool | Description | | - | - | | `list` | List the skills available in the workspace. | | `get` | Get details about a specific skill. | | `insights` | View skill usage metrics for the workspace. | Skills provide reusable instructions that help your agent follow your team's established practices. ## Rules tools The Rules tools help your agent find and use coding standards that apply to a task. | Tool | Description | | - | - | | `search` | Find coding rules that are relevant to a coding task. | | `list` | List coding rules available in the workspace. | | `get` | Get details about a specific coding rule. | Before making or reviewing a change, your agent can search for rules that apply to the task and use them to guide its work. ## Related resources * [Tools overview](/agentic-toolbox/qodo-tools-overview): A high-level summary of tool groups and suggested workflows. * [Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview): Learn how the Agentic Toolbox works and when to use the CLI or MCP. * [Reviewer](/agentic-toolbox/agentic-toolbox-codebase-review-skill): Review local changes before opening a pull request. * [Codebase Wisdom](/agentic-toolbox/agentic-toolbox-codebase-wisdom-skill): Understand your codebase, dependencies, and recent changes. * [Get Rules](/agentic-toolbox/agentic-toolbox-get-rules-skill): Retrieve the coding rules that apply to a task before implementation begins. * [Review Resolver](/agentic-toolbox/agentic-toolbox-review-resolver-skill): Retrieve and resolve Qodo Review findings from your agent workflow. # Get a single member Source: https://docs.qodo.ai/api-reference/api-reference/get-a-single-member /openapi/admin-users.json get /platform/v1/admin/users/{member_id} Returns a registered user or pending invitation in the caller's workspace. # Invite users to the organization Source: https://docs.qodo.ai/api-reference/api-reference/invite-users-to-the-organization /openapi/admin-users.json post /platform/v1/admin/invites Creates one or more organization invitations. Each email domain must be registered to the organization. If you provide a team ID, the team must belong to the caller's workspace. Requests with more than two email addresses are processed in the background. # List organization members Source: https://docs.qodo.ai/api-reference/api-reference/list-organization-members /openapi/admin-users.json get /platform/v1/admin/users Lists registered users and pending invitations in the caller's workspace. # Remove a member Source: https://docs.qodo.ai/api-reference/api-reference/remove-a-member /openapi/admin-users.json delete /platform/v1/admin/users/{member_id} Removes a registered user or pending invitation from the caller's workspace. In organizations that allow domain-based sign-up, a removed user can join again at the next sign-in. API-key revocation is not yet part of this operation. Do not use this endpoint as the only step in an automated offboarding workflow until Qodo confirms that API-key revocation is enabled for your deployment. # Update a member's role or team Source: https://docs.qodo.ai/api-reference/api-reference/update-a-members-role-or-team /openapi/admin-users.json patch /platform/v1/admin/users/{member_id} Updates a registered member's organization role, team role, or team. Send at least one field. Send `organization_permission` and `team_id` in separate requests. A team must belong to the caller's workspace, and a pending invitation cannot be updated. The last organization owner cannot be demoted. # Changelog Source: https://docs.qodo.ai/changelog Chronological record of Qodo releases, covering new features, improvements, and bug fixes across all versions. This changelog provides a chronological record of changes to Qodo, including new features, improvements, and bug fixes. Each version is grouped first by release number and then by release date so developers, teams, and stakeholders can easily see what has changed. For a quick overview of key updates and highlights, see our [What’s New](/qodo-documentation/whats-new) page. ### Highlights * **Troubleshoot background processes from the Background activity panel**: Admins can now use the improved Background activity panel to check the status of repository sync, pull request indexing, cross-repo discovery, and rules and skills import. When a process needs attention, the panel shows which actions can be taken and links to the page where the issue can be resolved. [Learn more](https://docs.qodo.ai/governance/troubleshooting-using-background-activity) ### Feature enhancements * **Search settings across configurations**: Find any setting on the Configurations page without browsing each tab. Select Search settings or press `⌘K` (`Ctrl+K` on Windows and Linux), then go straight to the setting. Each setting has its own URL, which you can share. [Learn more](https://docs.qodo.ai/configuration/portal-configuration#search-settings-across-configurations) * **Configure all repositories in a Git organization at once**: Apply settings to a whole Git organization, without setting up each repository individually. The Configurations page now has a Git organization level, alongside the workspace and repository levels. [Learn more](https://docs.qodo.ai/configuration/portal-configuration#configuration-levels-workspace-git-organization-and-repository) ### Highlights * **Manage pull request bottlenecks with PR Triage (Research Preview)**: See your organization's open pull requests across repositories and Git providers in one shared queue, with a default triage policy applied automatically. Customize how pull requests are prioritized using SLA, priority, and blast radius, and apply policies at the workspace, Git organization, or repository level. [Learn more](https://docs.qodo.ai/governance/pr-triage) * **Code review analytics dashboard (Beta)**: The new Analytics dashboard in the Qodo portal shows how your team responds to Qodo findings across pull requests, repositories, and PR authors. Explore finding activity and acceptance through Impact, By repository, and By PR author views. Filter by date range, repository, PR author, severity, category, and finding type, and export findings to CSV. [Learn more](https://docs.qodo.ai/governance/code-review-analytics) * **Set up Qodo end to end with the new onboarding wizard**: Organization admins set up Qodo in one guided flow that connects a Git provider, tailors code review with a Review preset matched to the team's priorities and workflow, and brings the Agentic Toolbox to developers. [Learn more](https://docs.qodo.ai/onboarding-wizard) * **Gerrit integration across all deployment types**: Qodo now fully supports Gerrit across multi-tenant, single-tenant, and on-premises deployments, enabling AI-powered code reviews and findings directly in your Gerrit changes. Connect your Gerrit instance to Qodo to automatically analyze changes, publish findings, and control code review at the project level. [Learn more](https://docs.qodo.ai/install-qodo/gerrit) * **View and dismiss findings from your pull request (Beta)**: Use the Dismiss and View links on each open finding to dismiss the finding with a reason, or to open it in the Qodo portal. You can also dismiss findings from the Findings page. [Learn more](https://docs.qodo.ai/code-review/dismiss-a-finding) ### Feature enhancements * **Use out-of-the-box Review presets to tailor your code reviews**: Apply a ready-made Review preset from the Configurations page to set finding types, workflow, context, remediation, and display settings in one step. The Display tab's presets are now called Display modes. [Learn more](https://docs.qodo.ai/configuration/review-presets) * **Reduce noise by choosing which rules and skills you import**: Select the Git organizations or repositories Qodo imports rules and skills from, and manage them on the revamped Rules page, with new ways to view your rules and easier control over turning them on and off across repositories. [Learn more](https://docs.qodo.ai/governance/rule-enforcement/building-review-standards#importing-rules-and-skills) * **Choose which finding types Qodo raises**: A new Finding types tab on the Configurations page lets you turn each type of finding on or off, including Bugs and correctness, Rule enforcement, Skill insights, Cross-repo impact, Spec gaps, and Design gaps. [Learn more](https://docs.qodo.ai/configuration/finding-types) * **Customize what inline findings show**: Choose which parts of a finding, such as the description, code, evidence, and agent prompt, appear in the inline comment attached to the code line, separately from the summary comment. In Bitbucket and Gerrit, you can also link each summary finding's title to its inline comment. [Learn more](https://docs.qodo.ai/configuration/display#findings) * **Keep the focus on findings that still need action**: Choose how resolved findings appear in the review comment. Keep them struck through in their original group, move them to a separate section after the open findings, or leave them out of the comment entirely. [Learn more](https://docs.qodo.ai/code-review/track-resolved-findings) * **Manual setup in the Bitbucket Data Center installation wizard (on-premises)**: Along with Automatic setup, the wizard now offers Manual setup, where your Bitbucket admin creates the Qodo account and webhook themselves. [Learn more](https://docs.qodo.ai/on-prem/git-integration/install/bitbucket-data-center) * **Open the relationship behind a cross-repo conflict**: Cross-repo conflict findings now link to the relationship behind them, from both the Evidence and Context sources sections. The link opens the relationship directly in the Relationships tab. [Learn more](https://docs.qodo.ai/code-review/view-cross-repo-conflicts-in-findings#cross-repository-conflict-details) * **Fix the rule or relationship behind a finding from the chat**: When you tell Qodo in a finding thread that the rule or cross-repo relationship behind the finding is incorrect, Qodo replies with a link to that rule or relationship in the Qodo portal. Update, disable, or delete it there to keep future reviews from raising the same finding. [Learn more](https://docs.qodo.ai/code-review/chat-with-qodo-in-your-pull-requests#fix-the-source-of-a-finding-in-the-portal) ### Highlights * **View your Software Map across repositories (Beta)**: Get a live view of your software system across repositories, with dependencies, connections, service relationships, contracts, and blast radius mapped automatically and updated with every pull request. [Learn more](/governance/repositories/gain-insight-with-software-map) * **Automatic cross-repo discovery across your organization (Beta)**: Qodo automatically discovers cross-repository relationships across your entire organization instead of one repository at a time. [Learn more](/governance/cross-repo-code-review/repository-relationships#automatic-discovery-across-your-organization) * **See how your configuration displays for each provider**: Select a Git provider icon on the Configurations page to view settings and the Display live preview exactly as they render for that provider. Unsupported settings appear disabled, and a tooltip explains any that behave differently. The preview also adds a light/dark mode toggle and a Summary/Inline view. [Learn more](/configuration/portal-configuration) ### Feature enhancements * **Ignore PRs and Ignore Files**: Skip code review and PR summary generation for pull requests matching a title, author, label, or branch, or exclude specific files from the review diff by path. [Learn more](/configuration/workflow#ignore-prs) ### Heads up: Sunsetting legacy Qodo v1 commands Qodo is sunsetting selected legacy v1 commands in two batches. Starting September 1, 2026, these commands are deprecated and will be permanently removed on October 1, 2026. If you use any of these commands, review the available alternatives and update your workflows before they are removed. For more information, see [Sunsetting legacy v1 commands](/sunsetting-legacy-v1-commands). ### Highlights * **Get Agentic Toolbox from leading marketplaces**: Agentic Toolbox is now generally available (GA) through verified plugins and a Power in the leading marketplaces for [Claude plugin](/agentic-toolbox/claude-code-plugin), [Codex plugin](/agentic-toolbox/codex-plugin), and [Kiro Power](/agentic-toolbox/kiro-power). * **Bitbucket Data Center installation wizard (on-premises)**: A guided installation wizard connects a self-hosted Bitbucket Data Center server to Qodo.\ For more information, see [Install the Bitbucket Data Center integration for Qodo on-premises](/on-prem/git-integration/install/bitbucket-data-center). - **Blast radius (Research Preview)**: Qodo classifies a code change's risk and publishes it as a native pull request label (a tag on Azure DevOps), helping triage which pull requests need the closest review.\ For more information, see [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius). - **Code review configuration presets**: Choose a ready-made preset, Minimal, Standard, Comprehensive, or Custom, instead of setting each Display option individually.\ For more information, see [Configure Qodo using the portal](/configuration/display#display-modes). - **Enhanced cross-repo relationship map (Beta)**: Graph view adds a **Map** mode for exploring repository connections and a new **Monitor** view (Alpha) for reviewing findings across related repositories.\ For more information, see [View cross-repository relationships](/governance/repositories/relationships). - **Monitor background activity**: A new **Background activity** panel, in the top navigation on every page, shows the status of repository sync, PR history indexing, cross-repo discovery, and rules import.\ For more information, see [Qodo portal quick tour](/qodo-portal-quick-tour#monitor-background-activity). ### Feature enhancements * **Draft PR code review trigger**: Set Code review trigger to Draft and published PRs to run reviews when a PR is opened as a draft, and again when it's published (GitHub, GitLab, Azure DevOps).\ For more information, see [Configure Qodo using the portal](/configuration/workflow#code-review). * **Rule Miner default behavior change**: Generated rules activate automatically by default for organizations that started using Qodo since September 1, 2026. Organizations onboarded before that date keep the existing suggestions-first default.\ For more information, see [How rules are activated after generation](/governance/rule-enforcement/rule-miner#how-rules-are-activated-after-generation). * **Configuration improvements in the Qodo portal**: * **Notification comments**: Persistent comment notification, in-progress comment, and image/animation settings moved to the Display tab's Notification comments section. * **Dismiss button**: A new Dismiss button discards unsaved changes and reverts to the last saved settings. It appears next to Reset, which restores the configuration to its defaults. For more information, see [Configure Qodo using the portal](/configuration/display#notification-comments). * **Review effort mode moves to Beta**: Review effort mode has moved from Public Preview to Beta. Auto is the default for customers who have not explicitly selected a review effort mode. Auto dynamically adjusts review depth to balance review quality and speed. Existing mode preferences are preserved.\ For more information, see [Optimize AI effort with Review effort mode](/code-review/use-qodo-in-prs/control-review-effort). * **Repositories tab revamp**: The Repositories tab has a cleaner look and feel, and is easier to navigate, with each repository's provider and connection health visible at a glance next to its name.\ For more information, see [Monitor and manage repositories](/governance/repositories/manage-repositories#repositories-tab-reference). ### Feature enhancements #### Improved visibility into previous review results Introduced a redesigned **Previous reviews** section, controlled from the **Display** tab in the Qodo portal, to provide improved visibility into how a review evolved across commits. * The section is now collapsible and styled like the rest of the review comment, with a linked "Review updated until commit" line, one entry per reviewed commit tagged with its review mode, and resolved findings shown struck through. * A new **Show previous reviews** toggle controls it per workspace. * The "Context used" panel is renamed to **Context sources** and now shows the review's inline/summary routing counts. * The self-review checkbox moved directly under the findings. * Disabling divider lines now keeps a single blank line between comment parts.\ For more information, see [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#previous-reviews-formerly-audit-trail). ### Highlights * **Qodo Agentic Toolbox (Beta)**: Extend your coding agent with four Qodo skills: Codebase Wisdom, Get Rules, Review, and Finding Resolver. Use Qodo capabilities to understand your codebase, apply relevant rules, review local changes, and resolve findings directly from your agent workflow. For more information, see [Qodo's Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview). * **Gerrit integration for on-premises**: Qodo on-premises now supports Gerrit, enabling AI-powered code reviews and findings directly in your Gerrit changes. Connect your Gerrit instance to Qodo and automatically analyze changes, publish findings, and control code review at the project level. For more information, see [Install the Gerrit integration for Qodo on-premises](/on-prem/git-integration/install/gerrit). * **Web search (Research Preview)**: Qodo Review can now use web search to enrich review context with up-to-date information about third-party dependencies. This helps ground findings in the latest official documentation, specifications, and release notes, providing more accurate and relevant reviews. For more information, see [Enrich context with up-to-date dependencies](/code-review/use-qodo-in-prs/third-party-dependencies-context). * **Advanced Git configurations**: The **Configurations** page is regrouped by what each setting affects instead of by feature area. * **New tab layout**: Tabs changed from Code review, Display preferences, Remediation, Custom instructions, and Account, to Display, Workflow, Context, Remediation, and Prompts. * **Granular display configuration** (GitHub, GitLab, Azure DevOps): The Display tab replaces the previous Verbosity settings with focused sections for counters, labels, grouping, ordering, overflow, finding content, and comment structure, each independently configurable with a live preview. * **Configurable severity terminology**: Choose how severity tiers are labeled in review comments: High/Medium/Low, Critical/Warning/Informational, Required/Recommended/Optional, or P0/P1/P2. For more information, see [Configure Qodo using the portal](/configuration/portal-configuration). * **Live sync visibility for Git installations**: A new **Syncing** status on the Installations tab shows when an installation's initial sync is running. For GitHub and GitLab, the repository count updates as repositories are found.\ For more information, see [Monitor code review across your organization](/governance/repositories/installations#connection-states). * **Daily tips in pull requests**: Discover more Qodo features and configurations directly from your pull requests with a rotating daily tip. Each tip links to relevant documentation and configuration pages, making it easier to find and use capabilities you may not know about.\ For more information, see [Qodo's daily tips](/tips-and-tricks). * **Higher manual cross-repository relationship limit (Beta)**: The number of relationships you can add manually per repository increases from 10 to 100.\ For more information, see [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships#add-relationships-manually). ### Feature enhancements #### Multi-source mined patterns (Beta) When Rule Miner finds the same pattern across multiple pull requests, the rule's Source field shows the pull request count instead of a single link, and lists each contributing pull request.\ For more information, see [Generate rules from pull request history with Rule Miner](/governance/rule-enforcement/rule-miner#view-the-source-pull-request-for-each-rule). #### Account management enhancements Account settings are now consolidated in a single **Settings** page within Account Management in the Qodo portal, bringing settings that were previously scattered across four different areas of the portal into one place. The new settings hub makes account management easier to navigate and restores the Delete my account action. For more information, see [Manage your Qodo account](/account-management/manage-your-qodo-account). #### Manual PR history indexing Organization admins can now trigger a repository's PR history indexing directly from the Repositories page. New **Start indexing**, **Retry**, and **Update** buttons start a first run, recover from one that failed, or pull in the latest pull requests early, keeping the history that powers Rule Miner and Relevance current.\ For more information, see [Monitor and manage repositories](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status). ### API token enhancements You can now set an expiration for API tokens when creating them. This enhancement gives you more flexibility and control over token lifecycle management.\ For more information, see [Create an API key](/account-management/manage-api-keys#create-an-api-key). ### Highlights * **PR history indexing**: See indexing progress for each repository's pull request history, and which learning features it has unlocked, from the Repositories page and its repository sidebar. The PR history indexing powers [Rule Miner](/governance/rule-enforcement/rule-miner) and [Relevance](/code-review/relevance).\ For more information, see [Monitor and manage repositories](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status). ### Feature enhancements * **GitLab installation wizard improvements**: Installing Qodo on GitLab is now a more seamless experience, connecting all your groups and projects in one step and automatically matching access token instructions to your GitLab Server version.\ For more information, see [Install Qodo on GitLab](/install-qodo/gitlab/install-qodo-on-gitlab). * **Bulk actions for repositories**: Enable or disable code review for multiple repositories at once, directly from the Repositories page.\ For more information, see [Monitor and manage repositories](/governance/repositories/manage-repositories#manage-code-review-in-bulk). * **Outdated finding state**: A new **Outdated** label now surfaces next to a finding that's no longer relevant because the underlying code changed.\ For more information, see [View all findings in your organization](/governance/view-all-findings-in-organization#finding-states). ### Research Preview * **Review effort mode**: Automatically matches review depth to the risk of each change, reducing review time for low-risk updates while applying deeper scrutiny to higher-impact changes. You can also configure a fixed review mode for a repository. For more information, see [Optimize AI effort with Review effort mode](/code-review/use-qodo-in-prs/control-review-effort). ### Highlights * **Support for IdP-initiated SSO login**: Added support for IdP-initiated login, letting users launch Qodo directly from their identity provider portal (such as Microsoft Entra ID or Okta), without visiting the Qodo sign-in page first.\ For more information, see [Configure Single Sign-on (SSO)](/account-management/single-sign-on-sso). * **Grant edit permissions**: Extended edit access beyond organization admins to team owners or members, for more granular control over who can edit the Configuration, Review standards, Integrations, and Repositories pages. For more information, see [Configure Qodo using the portal](/configuration/portal-configuration#account). ### Feature enhancements * **Bulk actions for skills, rules, and suggestions**: Added bulk actions for skills, rules, and suggestions, enabling you to activate, deactivate, accept, or dismiss them all at once, or define scope for skills and rules in bulk.\ For more information, see [Manage skills across repositories](/governance/manage-skills-across-repositories#manage-skills-in-bulk) and [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules#manage-rules-in-bulk). * **Native PR review time estimate label**: Publish the PR summary's estimated review time (for example, "10-20 Minutes") as a native label on the pull request, visible in your Git provider's pull request list.\ For more information, see [Generate a PR summary](/code-review/pr-summary). * **Edit rule and skill scope from the side panel**: Enhanced the rule experience, allowing you now to edit rule and skill scope directly from the side panel, choosing Global or Specific repositories for a single rule or skill.\ For more information, see [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules#anatomy-of-a-rule) and [Manage skills across repositories](/governance/manage-skills-across-repositories#manage-repository-assignments). * **PR history support extended to multi-tenant**: PR history uses past pull requests to help evaluate whether a code review finding is likely relevant, now available for multi-tenant customers too (GitHub and GitLab).\ See [PR history](/core-concepts/pr-history). * **Save button in the Configurations page**: Configurations page changes now require an explicit **Save**, with **Reset** alongside it, replacing the previous autosave behavior.\ For more information, see [Configure Qodo using the portal](/configuration/portal-configuration). * **CSV export from the Findings page**: The Export CSV option has been removed from the Findings page. ### Research Preview * **REVIEW\.md instructions**: Customize code reviews by defining repository-specific guidelines in a `REVIEW.md` file. Qodo uses these instructions to tailor review feedback, prioritize findings, and reduce noise across pull requests. For more information, see [Apply REVIEW.md instructions to code review](/governance/use-review-md). ### Highlights * **Automatic cross-repository discovery (Beta)**: Qodo now discovers the relationships between your repositories automatically, so cross-repository review works without mapping dependencies by hand.\ For more information, see [Cross-repository code review](/governance/cross-repo-code-review). ### Feature enhancements This release includes improved and additional configurations that give you more control over how reviews run and how findings are presented, all from the Configurations page in the Qodo portal. #### Code review experience enhancements * **Control review verbosity**: New Verbosity settings on the Display preferences tab control how findings are surfaced: * **View more**: Controls how findings in lower action levels collapse in the summary comment. * **Action level routing mode**: Sets where findings appear for all action levels at once, or select **Custom** to configure each action level individually. * **Per-action-level routing**: In **Custom** mode, routes each action level (Action Required, Review Recommended, and Informational) to inline, the summary, both, or dropped. For more information, see [Control review verbosity](/code-review/review-verbosity). * **Per-finding verbosity**: For each part of a finding (description, code, recommendation, evidence, and agent prompt), select whether it's hidden, shown collapsed, or shown expanded in the pull request comment. This replaces the earlier Finding expansion setting. * **Comment location for the PR summary**: Determine where Qodo publishes the PR summary, as a standalone comment, in the native pull request description, or dynamically. * **Show images and animations**: A new global setting to enable or disable Qodo's illustrations and animations in the loading and empty state review comments. #### Account management permissions enhancements * **Invite-only mode**: When enabled, only invited users receive Qodo's review feedback on their pull requests, so other users are silently skipped. Useful for staged rollouts. * **Team owner edit permissions**: Organization admins can grant team owners org-admin-level access to the Configuration, Review standards, Integrations, and Repositories pages, so they can manage their team's review governance without being full organization admins. For more information, see [Configure using the Qodo portal](/configuration/portal-configuration). ### Research Preview * **Spec agents**: Reviews pull requests against linked specification documents to verify that implementation matches documented requirements. Identifies missing requirements, incomplete implementations, and deviations from the intended design before code is merged. For more information, see [View requirement gaps in findings](/code-review/view-requirement-gaps-in-findings). * **Design review agent**: Reviews pull requests against linked Figma designs and design system components to verify that UI implementations match approved designs. Identifies UX deviations, missing design requirements, and design system inconsistencies before code is merged. For more information, see [View UX deviations in findings](/code-review/view-ux-deviations-in-findings). ### Highlights * **Cross-repository code review (Beta) (Multi-tenant, Single-tenant)**: Detect breaking changes across repository boundaries before they reach production. Relationships between repositories are defined manually, and Qodo automatically reviews every relevant pull request for cross-repository impact, across Git providers.\ For more information, see [Cross-repository code review](/governance/cross-repo-code-review). * **Rule Miner: generate rules from pull request history (Beta) (Multi-tenant, Single-tenant)**: Rule Miner automatically discovers recurring review patterns from your organization's pull request history and generates rules from them, turning repeated feedback into enforceable standards.\ For more information, see [Generate rules from pull request history](/governance/rule-enforcement/rule-miner). * **Centrally manage rule-related skills across repositories (Beta)**: Administrators can centrally manage rule-related skills across repositories from the **Skills** page in the Qodo portal. The experience provides visibility into discovered review standards, repository coverage, rule activity, and detected violations, helping teams enforce coding, security, compliance, and architectural standards at scale.\ For more information, see [Manage skills across repositories](/governance/manage-skills-across-repositories). * **Enhanced Conversational Chat in pull requests (Beta)**: Have contextual, natural-language conversations with Qodo anywhere in a pull request by addressing it with the keyword `qodo` (or `@qodo` / `/qodo`) to explain findings, dismiss them, and discuss suggestions.\ For more information, see [Conversational chat](/code-review/chat-with-qodo-in-your-pull-requests). * **Introducing the Research Preview program**: A program intended for exploring features that are under active development. These features let you try new capabilities and share feedback before broader release, and are clearly identified throughout the documentation. Features leave the program once they advance to Beta or General Availability.\ For more information, see [Qodo Research Preview program](/preview-research-program). ### Feature enhancements * **Redesigned Configurations page in the Qodo portal**: The Configurations page is reorganized into five tabs, Code review, Display preferences, Remediation, Custom instructions, and Account, making settings easier to navigate and manage.\ For more information, see [Configure using the Qodo portal](/configuration/portal-configuration). * **Repository-level configuration in the Qodo portal**: Configure review settings at the repository level directly from the Configurations page. Organization defaults apply unless overridden at the repository level.\ For more information, see [Configure using the Qodo portal](/configuration/portal-configuration). ### Research Preview * **Remediation agent**: Automatically applies fixes for review findings that match your configured severity threshold, creates a new branch, and opens a separate remediation pull request with the proposed changes. For more information, see [Remediate findings in your pull request](/code-review/remediate-findings-in-prs). ### Feature enhancement * **Improved PR summary with full-codebase context** Qodo now analyzes the full codebase to generate a structured PR summary automatically when a pull request is opened. The summary includes PR tags, estimated review time, an architecture diagram, and a high-level assessment, giving reviewers full context before they look at a single line of code. See [Generate a PR summary](/code-review/pr-summary). ### Feature enhancements * **New centralized Repositories page (Beta)** Added the **Repositories** page allowing you to view and manage your Git installations and repository connections from a central location. For more information, see [Manage code review across repositories](/governance/repositories). * **Extended wizards for seamless Qodo installation on Git providers** As part of Qodo's initiative to simplify onboarding and bring feature parity across Git providers, Qodo continues to expand its series of guided installation wizards. * [GitLab Cloud: multi-tenant](/install-qodo/gitlab/install-qodo-on-gitlab) - [GitHub Cloud: multi-tenant](/install-qodo/github/qodo-multi-tenant) - [GitHub: single-tenant and Enterprise Server](/install-qodo/github/qodo-single-tenant) * Added `/agentic_describe` to the PR summarization commands that automatically generates a structured summary of the pull request. ### Feature enhancement * **Added **Conversational Chat** to pull requests (Alpha) (GitLab, GitHub, Azure DevOps)**: You can now interact with Qodo directly inside your pull requests.\ For more information, see [Conversational chat](/code-review/chat-with-qodo-in-your-pull-requests). ### Feature enhancement * **Added a **Live Preview** pane to the **Configuration page** in the Qodo portal (Beta)**: This view provides a real-time visual of how their review comments will appear in the target Git provider.\ For more information, see [Live Preview Pane](/configuration/display#display-live-preview). ### Highlights * **Added the **Findings page** to the Qodo portal (Beta)**: A centralized view of all PR findings across repositories. Team leads and engineering managers can browse, filter, and track findings across all pull requests and monitor code quality trends with 30-day analytics.\ For more information, see [View and analyze cross-organization PR findings](/governance/view-all-findings-in-organization). #### Feature enhancements **Rules page in the Qodo portal** * Added Source filtering, allowing rules to be filtered by origin. * Added a sticky Rule name column to keep rule names visible while scrolling. * Improved table usability for a smoother experience when working with rules. For more information, see [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules). **Rule System** * Added support for scanning all files in the Skills directories (e.g. `skills//SKILL.md`) and in the `.cursor/rules/` directory (including `.cursorrules` and `.mdc` files) for automatic rule discovery and import. For more information, see [Rule enforcement](/governance/rule-enforcement/onboarding#supported-file-names-and-types). ### Feature enhancement #### Introducing wizards for seamless Qodo installation on Git providers As part of Qodo's initiative to simplify onboarding and bring feature parity across Git providers, Qodo continues to expand its series of guided installation wizards. * **Bitbucket Cloud installation wizard**: A guided installation wizard is now available for Bitbucket Cloud, supporting multi-tenant and single-tenant deployments. For more information, see [Install Qodo on Bitbucket Cloud](/code-review/get-started/install/bitbucket/bitbucket-cloud). * **Azure DevOps installation wizard**: A guided installation wizard is now available for Azure DevOps, supporting multi-tenant and single-tenant deployments. For more information, see [Install Qodo on Azure DevOps](/code-review/get-started/install/azure-devops). #### New features * **PR history–based relevance section** (GitHub, Enterprise, Single-tenant deployments, Beta): Added a Relevance section to code review findings that links to similar past PRs and indicates whether issues are likely relevant based on how similar findings were handled previously. * **GitHub installation wizard** (single-tenant deployments): Introduced a new guided GitHub installation wizard to streamline setup and deliver a more frictionless onboarding experience for single-tenant deployments. * **Qodo portal configuration page**: Added a new Configuration page in the Qodo portal for managing organization-wide review settings. * **Self-review acknowledgment for PR reviews** (GitHub): Added support for author self-review in PRs, allowing authors to acknowledge Qodo findings via a checkbox and optionally add Qodo as a reviewer to enable merging. #### Improvements **Rules page in the Qodo portal** * Added Passed, Detected violations, and Merged violations insights directly in the Rules table, with support for sorting by these metrics. * Added a Source column to display the origin of each rule directly in the table. * Added a Scope column showing where the rule is applied, with hover support to view the full list of organizations and repositories. * Added scope filtering, allowing rules to be filtered by selected repositories. **IDE Extension** * Code review experience for committed and uncommitted changes. * New welcome screen introducing the review-first experience and setup guidance. * Integration with external CLI-based coding agents: Claude Code, Codex, Cursor CLI, and custom CLI-based agents. * Ability to resolve review findings directly using connected CLI agents. **Updated:** Qodo is transitioning from a code generation tool to a code review agent. This change is now applied to Free users. Teams users will transition to a review-only experience by the end of March 2026. #### **Rule System** (Beta, currently supported for GitHub single and multi-tenant only.) * Rule System for centralized standards management and enforcement * Automatic conversion of existing rule files into structured standards * Rule generation from natural language * Automatic rule discovery from codebase and PR history * Scoped enforcement at organization and repository levels * Rule health management including duplicate and conflict detection * Rule adoption and violation metrics * In context rule enforcement during pull request review #### Azure DevOps Integration * Native Azure DevOps integration for Enterprise customers * AI powered pull request reviews inside Azure DevOps * Ticket compliance checks using Azure Boards work items * Repository and project level configuration #### **Agentic code review** This feature is generally available (GA). * Next generation agentic PR review with multi agent architecture * Full repository context and PR history analysis * Prioritized findings with structured remediation guidance * Higher precision and recall * Review experience focused on critical issues over noise ## Qodo 1.x ≤ * **New:** Local Review – review your local changes before commit with categorized insights and quick fixes * **Removed:** Standard Mode (deprecated) * **Updated:** New Welcome Screen with quick access to top workflows * Bug fixes and performance improvements * Add new custom MCP to all workflows by default * Bug fixes and performance improvements * Custom MCPs are now added to all modes * Fixed quota usage display issues * Added `agent.md` support #### Bug Fixes * Fix Qodo Aware issue in Custom Modes * Fix missing workflows in Windows * Fix close modal on logout * Improved error handling in new login flow #### New Feature * **File and Image Attachment Support** Users can now add files and images directly in chat. This allows providing richer context to the agent: for example: * Share **design images** to guide implementation. * Upload **CSV or PDF files** to supply data, logs, or specs. #### Fixes * Fixed quota usage display issue * Fixed send button not working with history messages. #### Bug Fixes * General bug fixes and performance improvements. #### Features * Added interactive sign-in button for authentication prompts with chat panel * Added retry logic with exponential backoff to authentication API calls #### Fixes * Updated filesystem tool parameter descriptions #### Bug Fixes * General bug fixes and performance improvements. #### Bug Fixes * General bug fixes and performance improvements. #### Bug Fixes * General bug fixes and performance improvements. #### Features and Improvements * Git Diff in Context Menu – Tag your local changes or compare branches (against `main` or any other branch). Reviewing just got faster and more intuitive. * Auto Approve in Chat – Automatically approving the next tools in the same chat. * Workflow Menu Revamp – A sleeker design with better usability for navigating and managing workflows. * Models Menu Update – Enterprise users no longer see credit usage, and titles have been cleaned up for clarity. * Smarter AutoScroller – If you scroll up during a live stream, auto-scroll won’t drag you back down until you’re ready. * Main Menu Upgrade – The chat’s main menu now includes MCP tools, and grouped properly for better navigation. #### Fixes * Regex Crash Resolved – In chat context menu. * Best Practices Workflow – Generated files now follow lowercase naming conventions consistently. #### Features * Improved login flow on VSCode. #### Bug Fixes * General bug fixes and performance improvements. #### Bug Fixes * General bug fixes and performance improvements. #### Features * `Auto Approve` toggle: When enabled, all tools and terminal commands in this chat session will be approved automatically * Updated models menu – Refreshed look & feel with clearer descriptions of credit usage for each model. * Standard Chat update – Revised welcome screen text to announce its **upcoming deprecation** (shown only to users with agentic chat). #### Bug Fixes * General bug fixes and performance improvements. #### Features * Qodo Aware is now available to use in Qodo Gen! Qodo Aware is your team’s AI assistant for deep code understanding, spanning repositories, services, and history. Get fast answers or thorough multi-step reasoning without context switching. Press the **Qodo Aware** button above the chatbox to use Qodo Aware. * [Built-in workflows](/qodo-ide/agent/workflows) are now uneditable. If you'd like to edit a workflow, duplicate it and edit the copy. #### Bug Fixes * General bug fixes and performance improvements. #### Features * Workflows in the workflows list now include descriptions. #### Bug Fixes * General bug fixes and performance improvements. * **Workflows:** Improved structure and clarity. Use slash commands like `/unit-test`, `/review`, `/fix`. * **Modes:** Persistent AI collaborators for tasks like coding, planning, and architecture. * **Share Agents:** Create, export, and share custom Workflows or Modes with your team. * **New:** Fully integrated **Qodo Aware**: click the eye icon to activate Ask or Deep Research agents. Tag repos for better context. #### **Fixes** * Improved quota bar behavior: now shows only after reaching 80%. #### **Improvements & Clean-up:** * Removed the "Generate Tests" panel and related functionality. We're removing the right-hand Test panel to reduce visual clutter and simplify your workspace. Test generation and interaction will now appear directly in the chat with the `/test` command, where they’re most relevant, helping you stay focused without losing functionality. #### **Fixes** * Improved error handling for quota-related issues in VSCode. #### **Features** * Quota information is now displayed on button click for users. * Enterprise users will no longer see the quota button. #### **Features** * Full file content is now returned when editing files, rather than only diffs. * Workflow now prints debug inputs for easier troubleshooting. #### Bug fixes * General bug fixes and performance improvements. #### Bug fixes * General bug fixes and performance improvements. #### **Fixes** * Logging and analytics improvements. #### **Features** * Login screen added to chat panel. * Show changes summary when message is manually stopped. #### **Fixes** * Removed test-only right-click panel option. #### Bug fixes * General bug fixes and performance improvements. #### **Features** * Git commit tracking added and integrated with analytics. #### **Fixes** * IDE now avoids unnecessary file loading when not focused. #### Bug fixes * General bug fixes and performance improvements. #### Bug fixes * General bug fixes and performance improvements. #### Improvements * Extension name shortened in VSCode * Error messages improvements * In VSCode: the "Auto commit message" button switched to the Qodo logo #### Bug fixes * General bug fixes and performance improvements. #### Features * **Terminal Agentic Tool (MCP) with command control**: The new Terminal Agentic Tool allows your local terminal to run directly within the IDE, letting developers execute tests and commands seamlessly, resulting in a more integrated and fluent development experience. You can control which terminal commands are allowed or blocked to run via chat preferences, giving you greater security and flexibility when running commands directly from the IDE. * **SSE MCPs**: You can now add SSE MCPs using just a URL, making the setup process more secure, faster, and easier to manage. * **Codebase Intelligence Agentic Tool (MCP):** Qodo Gen's agent can now use your **Company Codebase (RAG)** in **Agentic Mode**. This enables real-time code retrieval, deeper context awareness, and smarter code generation, refactoring, and debugging, all based on your actual codebase. * **Agentic Mode has been significantly improved** to handle more complex, multi-step tasks. It is now more dynamic and adaptable, enabling deeper interactions and more sophisticated workflows. * **Live diff**: View real-time changes as you request adjustments from Qodo Gen. * **Tooling throughout the process**: Tools are now accessible throughout the entire development process, not just at the beginning of a query. This allows for more flexibility and control as you iterate and refine your code. * **New and improved design**: The platform features a refreshed and improved design. * [**Qodo Merge**](https://www.qodo.ai/products/qodo-merge/) **Agentic Tool:** Qodo Merge, Qodo's code review tool designed to automate review workflows and elevate code quality, **is now fully integrated into Qodo Gen!** With Qodo Merge MCP, Qodo becomes a complete shift-left platform, streamlining the workflow from coding and testing to merging. The Qodo Merge Agentic Tool introduces built-in review assistance, including smart suggestions and auto-generated change descriptions directly from your diffs, helping ensure timely and high-quality code reviews. #### Bug fixes * General bug fixes and performance improvements. #### Features * **Enterprise Allow-list management MCP:** Enterprise customers can now control which Agentic Tools can be used within their organization. This is the first step toward a broader Agentic Tools Hub coming in the future! * **All non-enterprise features of Qodo Gen are now available to all!** * Improvements in chat interactions and user interface. #### Fixes * Enhanced error messaging for improved clarity. * General bug fixes and performance improvements. * Improved test reliability and consistency. #### Bug fixes * General bug fixes and performance improvements. #### Features: * **Improved Agentic Tools List UI:** It's now easier to view, add, and manage Agentic Tools. You can also add new tools directly via a script, making setup much faster for advanced users. * **Editor Content Persistence:** Your editor content is now saved when switching between different chat modes, preventing accidental loss of your work. #### Improvements: * **History File Location:** The History file is now named `.qodo/history` and has been moved to the user folder for better file organization. The file is named using a hash of the workspace path to ensure uniqueness. #### Fixes: * **Code Completion Preferences Cleanup:** The "User Instructions" field has been removed to simplify the Code Completion settings. * **Chat Mode Detection:** Fixed the logic for determining the correct chat mode when opening a new chat. This ensures the right mode is selected, even if the previous chat context was inconsistent. #### Bug fixes * General bug fixes and performance improvements. #### Bug fixes * Resolved an issue where the agent could become unresponsive. * Fixed compatibility problems with Agent Tools on Windows systems. #### Improvements * New welcome screen design * Some bug fixes and improvements #### Improvements * Behavior improvements. * Enhanced API error handling. * Fixed broken link in marketplace page. #### Improvements * Updated Marketplace page. * Show/hide chat history button based on context. * Added config file step & fixes. #### Bug fixes * Fixed login issue: clear refresh token & handle expired token. We’re thrilled to introduce **Qodo Gen Version 1**, packed with game-changing features to make your Qodo experience more intuitive than ever. #### New features * **Agentic Mode:** Choose between Standard or Agentic mode. Agentic mode is a game-changing flow of Qodo Gen Chat that dynamically uses tools to analyze requests and provide smarter, more adaptive responses. * **Agentic Tools (Custom MCPs):** Integrate external services like Jira with Qodo Gen using the open MCP protocol, allowing dynamic interactions with external tools. * **All-New Test Generation Flow in-Chat:** Creating tests is now easier with full integration into Qodo Gen Chat. Just type /test, and Qodo Gen will guide you through generating a complete test suite. You can refine tests, add cases and choose behaviors to test, all without switching tools. * **Artifacts:** Keep your chat clean. Open large code snippets as separate files in your IDE for easy application and comparison. * **Inline Context:** Quickly reference project files, functions, and classes in chat using @, improving searchability and response accuracy. * **Chat Preferences:** Customize commands and responses, code editor settings, code completion, and indexing for a tailored Qodo Gen experience. #### New features * Qodo rebrand: Updated logo and color scheme. #### Improvements * Enhanced analytics for better insights. #### Bug fixes * Fixed login issue affecting some users. #### Changes * Rolled back to v0.12.7 due to login issues. #### New features * Chat history now persists across IDE sessions. #### Improvements * Introduced new event structure for analytics. #### New features * Added `/help` command in chat: get information and answers to questions about Qodo Gen, taken directly from Qodo's documentation platform. * Added feedback buttons in chat. #### Improvements * Internal analytics enhancements. #### New features * Enabled batch processing for file indexing. * Added RAG tags for remote retrieval-augmented generation. #### Bug fixes * Fixed file focus issues in chat. * Made reference paths clickable in chat. #### New features * Clickable links added to reference links in repositories. * Context updates when files change. * Added `/generate-best-practices` command in chat. #### Bug fixes * Fixed "no content selected" error on file change. * README updates and improvements. #### New features * **Enhanced Model Selection**: Unleash the full potential of AI with our new model selection feature. Seamlessly switch between the world's most advanced AI models in real-time. Available Models: * 🧠 GPT-4.0 - The gold standard for advanced reasoning * 🔮 GPT-o1-preview - Enhanced reasoning and extensive knowledge base * ⚡ GPT-o1-mini - Lightning-fast coding specialist, optimized for efficiency * 🎯 Claude 3.5 Sonnet - Anthropic's latest, built for precision * 💫 Gemini 1.5 Pro - Google's cutting-edge multimodal AI * **Introducing support for best practices**: Qodo Gen now reads a `best_practices.md` file from the root of the project. when interacting with the chat, Qodo Gen takes into account those best practices when suggesting code. It currently supports all free chat and code chat commands. It does not support diff commands, advanced panel test generation, and code completion. Qodo Gen supports up to 1500 lines in the best practices file. * Added an option to copy messages from chat. #### Bug fixes * General bug fixes and performance improvements. #### New features * Change color to be more visible across themes #### Bug fixes * Fixed enterprise report analytics issues. #### Bug fixes * Fixed reopening free chat after closing all editors. #### New features * **Chat History:** Users can now switch between and revisit up to 20 recent chats. #### Bug fixes * Fixed Linux path issues. #### Changes * Various naming updates. #### Bug fixes * Fixed logout bug. #### Bug fixes * Fixed login lock issue after repeated failures. #### Changes * **Codiumate is now Qodo Gen!** Same features, new name. * **Extend Test Suite sunsetting:** The "Add more tests" inline option above generated tests, as well as the Extend Test Suite tab, will no longer be available. This change is necessary as part of Test Generation upgrading. #### New features * **Codebase Selection in Test Panel:** Enterprise RAG users can now select RAG usage. #### Bug fixes * Various bug fixes and improvements. #### New features * Added chat history to Codiumate Chat. #### New features * Added option to Add to Codiumate as context From the terminal * Codebase Selection: For Enterprise RAG users, you can now turn RAG usage on or off #### Changes * Codiumate Chat: Focus behavior now more intuitive * Improved code completion #### Changes * UI Improvements: The code snippet button has been relocated for easier access. Button labeling has been added, and action buttons are now always visible. Adjustments were made to color schemes for better visual consistency. * Error messages phrasing: Improved clarity in error explanations, detailing causes and necessary actions. Enhanced consistency in error message phrasing. #### Bug fixes * PHP support: Resolved an issue with the static analysis of PHP code. #### Changes * UI improvements. #### New features * Clear previously indexed context (cache) from the chat panel menu #### Bug fixes * Fixed freezing issue when chatting with small indexed snippets. #### Bug fixes * Increased max prefix/suffix length for code completion context. * Improved suffix handling in code completion requests. #### Bug fixes * Fixed recurring illegal line bug. #### Bug fixes * Fixed test panel issues. #### Bug fixes * Fixed `type_identifier` bug. #### Bug fixes * Fixed focus selection bug. #### Bug fixes * Fixed Java context builder. #### Bug fixes * Fixed illegal line bug. #### Changes * Improved context selection. * UI enhancements. #### Changes * UI improvements. #### Changes * Fixed extension uninstall event. #### Changes * Updated icons. #### New features * **New Codiumate Chat Interface:** Streamlined UI for easier navigation. * **Flexible Focus Selection:** Use `@` or `+` button to focus on specific code. * **Enhanced Context Options:** Index snippets, files, folders, or entire projects. * **Coding-Agent Activation:** Click the robot icon for coding assistance. #### Changed * Code completion enhancements * Added extension uninstall event #### Bug fixes * Fix: no wrap code block display in chat * Fix: display scrollbar for code in chat panel * Fix: error in thread after first message interrupt * Fix: formatting issues in codebase #### Bug fixes * Fixed performance issue #### Bug fixes * Fixed stopping and removing thread messages * Removed listener to fix slowness bug #### Changed * Changed the location of "Add folder to context" * Fixed parsing of paths on Windows * Improved Local RAG filtering #### Changed * Improved error handling in chat context reducer to provide more informative feedback on unknown actions. * Updated error message to advise saving file before re-selection. * Disabled Auto-Commands if the chat is open. #### Bug fixes * Normalize RAG settings key naming and change value types. #### New Features * Indexing Support for Folders and Files: You can now enhance your Codiumate experience by indexing entire folders or individual files. This update allows you to add your code directly as context for more precise and relevant Codiumate queries. #### New features * **Image Integration in Chat:** You can now paste images directly into the chat in both Free Chat and the new Coding Agent! This enhancement allows you to ask contextual questions about the images you upload. For instance, upload a design to request its HTML implementation, paste a UML diagram to have the Coding Agent plan according to it, and much more. #### Bug fixes * **Thread Response Continuity:** We've resolved a critical issue where threads would unexpectedly stop responding. You can now enjoy uninterrupted conversations without disruptions. * **Code Snippet Context Retention:** A bug in threads involving code snippets has been fixed. Previously, threads would lose the initial context when discussing code snippets; this issue has been addressed to ensure consistent and context-aware interactions. #### Bug fixes * Forward automatically triggered commands flag to the reducer #### Bug fixes * Fixed handling of revoked refresh tokens * Fixed command parsing in the chat panel #### New features * **Codiumate-Agent Alpha Release**: We're thrilled to announce the alpha release of our Codiumate-Agent, integrated within the VSCode extension. This marks the first introduction of our coding agent designed to assist developers in completing tasks efficiently within their projects. **Codiumate-Agent Highlights:** * **Task Specification:** Users can now write specifications for tasks directly within VSCode. * **Context Selection:** Offers the ability to select the relevant context for the task at hand. * **Automated Planning:** Codiumate-Agent can automatically write a plan based on the task specification. * **Code Auto-Completion:** Enhances coding efficiency by providing auto-completion for code based on the task's plan. #### Added * Enabling code completion when using task agent #### New features * Introduced Codiumate Agent Task Planner - Transform your task descriptions and contexts into a structured plan and implement with auto-complete. #### Changed * Fixed reading configuration file. * Updated docs links. #### New features * Added clipboard content to code completion context * Added Snippet types to code completion snippets * Added debug logs for code completion #### Changed * Renamed "Code Completion" to "Code Auto-complete" in settings for clarity. * Updated descriptions for code auto-completion settings to reflect service availability for subscribed members and support for custom instructions. # Qodo Code Governance Source: https://docs.qodo.ai/code-governance Govern code review across your organization with consistent standards, enforceable rules, and insights into review impact. Qodo Code Governance gives engineering leaders centralized control over how code is reviewed across the organization. Define consistent standards, enforce policies across repositories, and gain insight into how code review is working at scale. ## Governance insights Understand what is happening across your code review process and measure the impact of your governance. Manage and prioritize open pull requests across your organization, identify review bottlenecks, set triage policies, and take action with review and codebase context. Measure how teams interact with Qodo findings and track accepted code changes across pull requests, repositories, and authors. View findings across your organization and understand where issues are being raised and addressed. ## Govern your repositories Manage code review across your repositories and understand how codebases are connected. Configure and manage code review across repositories, teams, and services from a central location. Understand relationships between repositories and services to see how code changes can affect the wider system. ## Review Standards Define and enforce your organization's engineering standards consistently across every pull request. Turn your organization's engineering conventions into standards that Qodo can apply consistently, at scale, and in context. Manage and apply skills across repositories to guide coding agents and code review according to your organization's standards. ## Rule enforcement Turn engineering standards into explicit rules that Qodo checks during code review. Define, manage, and enforce rules that specify how code should be written, structured, or reviewed across your organization. Understand how your rules are performing and where they are being applied across code review. # The Qodo Code Review experience Source: https://docs.qodo.ai/code-review Qodo brings multi-agent, context-aware code review directly into your pull requests, catching breaking changes, spec gaps, and design deviations that diff-only tools miss. Most review tools only look at the diff. Qodo reviews every pull request (PR) with specialized AI agents that understand your full repository, history, and standards. For more information, see [how the review experience works](/code-review/overview). ## The review flow
1

Trigger

Automatically when a PR is published, or on every push to it. Trigger a code review →

2

Understand

Published directly on your pull request, every finding states what needs attention, why it matters, and how to fix it, ranked by severity. Anatomy of a finding →

3

Act

Discuss or dismiss a finding, or let Qodo apply the fix directly. Remediate findings →

## Explore Qodo's capabilities Beyond the core review, Qodo covers the rest of the pull request lifecycle, from deeper interaction with findings to tuning exactly what gets reviewed and how.

Deepen your code review

Go beyond reading a finding, discuss it, fix it, or see the deeper issue behind it.

Customize review output

Shape what Qodo shows you, where it shows up, and how much of it you see.

## FAQ Qodo analyzes the full repository, not just the changed lines, so it can reference files outside the diff and reason about changes the way a principal engineer would. For more information, see [How Qodo code review works](/code-review/overview). Specialized agents evaluate the change in parallel, correctness, standards compliance, architecture, and risk, then a judge agent merges their findings, removes duplicates, and filters out anything low-confidence before it reaches the pull request. For more information, see [How Qodo code review works](/code-review/overview). Both, in priority order. Qodo builds [Review Standards](/governance/review-standards) from your codebase, pull request history, and requirements, and every review agent applies them first. [Rule Miner](/governance/rule-enforcement/rule-miner) continuously turns recurring patterns from your team's own PR history into new enforced rules, so standards keep evolving with how your team actually works. Where nothing team-specific applies, Qodo falls back to established best practices. Yes. Qodo uses your pull request history to judge whether a finding is likely to matter, prioritizing issues similar to ones your team has fixed before and quieting ones you've consistently dismissed. For more information, see [Understanding PR history indexing](/core-concepts/pr-history). Yes, with cross-repository code review. Define a relationship between repositories and Qodo traces impact in both directions, for example flagging a PR that breaks a data model or API contract owned by another repository. For more information, see [Cross-repository code review](/governance/cross-repo-code-review). Yes. Turn on the **Per commit** trigger in the Qodo portal, or set `handle_push_trigger = true` in `.pr_agent.toml`, and Qodo updates the same review comment as new commits land. For more information, see [Enable persistent review comments](/code-review/persistent-review-comments). Yes. Small, single-file fixes get a one-click **Apply Suggestion** button; larger fixes come with an Agent prompt you can hand to an AI coding tool to implement with full context. For more information, see [Commit code fixes directly in the pull request](/code-review/commitable-code-suggestions) and [Remediate findings in pull requests](/code-review/remediate-findings-in-prs). # Assess code change risk using blast radius Source: https://docs.qodo.ai/code-review/assess-risk-with-blast-radius Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which pull requests need the closest review.
GitHub GitLab Azure DevOps
Blast radius is Qodo's classification of a code change's risk, based on its scope and sensitivity. Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull requests need the closest review directly from your Git provider's pull request list. Pull request list showing a blast radius label next to each pull request title ## How blast radius is classified Qodo estimates risk by analyzing the change in the context of the codebase it affects, not just the size of the diff. It weighs the impact and intent behind the change: a one-line edit to a production database configuration can carry more risk than a large documentation update, and the classification reflects that difference. Each pull request receives one of three risk levels: * 🔴 **Large blast radius** * 🟠 **Medium blast radius** * 🟡 **Small blast radius** **Azure DevOps**: Native tags don't support displaying emoji in pull requests. As a result, the tag appears as plain text, for example "Large blast radius". The label reflects the highest risk level identified across the pull request's review cycle. If a later commit raises the risk, the label updates to match, but the pull request only ever shows one blast radius classification at a time. ## Configure blast radius ### Configure blast radius in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **Code review**. 3. Enable **Publish blast radius label**. ### Configure blast radius in .pr\_agent.toml ```toml theme={null} [review_agent] publish_blast_radius_labels = true ``` Default: `false`. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#native-pull-request-labels): How native pull request labels fit into the review. * [Generate labels automatically](/code-review/generate-pr-labels): Add custom, content-based labels alongside the blast radius label. * [Optimize AI effort with Review effort mode](/code-review/use-qodo-in-prs/control-review-effort): Match review depth to the risk of each change. # Chat with Qodo in pull requests Source: https://docs.qodo.ai/code-review/chat-with-qodo-in-your-pull-requests Chat with Qodo to interact with Qodo directly inside pull requests.
Beta
Want to fix a finding without leaving the chat? Use Fix with Chat Agent to remediate issues while you chat with Qodo. Describe the change you want, iterate on the suggestion, and apply it directly to the PR.
Available under Research Preview. [Learn more](/code-review/remediate-findings-in-prs) The chat with Qodo is the evolution of the `/ask` command. It retains the simplicity of asking questions in your workflow while adding powerful new capabilities through advanced chat interactions and specialized commands. Chatting with Qodo makes pull request reviews interactive. Start a conversation by mentioning `@qodo`, `qodo`, or `/qodo` at the beginning of a PR comment, review comment, or inline code comment. You can also address Qodo with a greeting such as `Hey qodo`. When chatting with Qodo, you can: * Ask Qodo to explain a finding. Conversational Chat explain a finding * Dismiss a finding with a reason. Conversational Chat dismiss a finding before This is the view once dismissed. Conversational Chat dismiss a finding after * Discuss a suggestion or ask follow-up questions in natural language. Conversational Chat inline chat * Tell Qodo that the rule or repository relationship behind a finding is wrong, and get a link to fix it in the Qodo portal. Qodo only responds when addressed, so reviewer discussions are never interrupted. ## Start the chat Mention `@qodo` in any PR comment, review comment, or inline code comment. Place `@qodo`, `qodo`, or `/qodo` at the beginning of the comment, or precede it with a greeting such as `Hey qodo`. Mention `@qodo` (or `/qodo` / `qodo`) each time you want Qodo to respond, including follow-up replies in a thread it has already participated in. Qodo replies only to messages that explicitly address it, so reviewer-to-reviewer discussion in a thread is never interrupted. ### Conversation context Qodo uses the chat location to understand context for: * **Inline code finding**: Scoped to the specific finding. * **Inline code comment**: Scoped to the specific line. * **PR comment**: Scoped to the entire PR and all findings. If Qodo cannot determine which finding or PR element you mean, it asks a clarifying question. ## What you can ask Qodo to do * **Explain a finding**\ Ask why a finding was raised or how the suggested fix works. Qodo replies in natural language. * **Dismiss a finding**\ Tell Qodo a finding does not apply. Qodo marks it as dismissed with one of four reasons: * **False positive**: The finding is wrong or describes an issue that does not exist. * **Rejected**: The finding is incorrect or invalid. * **Deferred**: The finding is acknowledged, but will be handled outside this PR. * **Intentional**: The flagged behavior is intended (e.g., kept for backwards compatibility). When a finding is dismissed, Qodo updates the PR in three coordinated places so reviewers can see at a glance what is still actionable: * The **PR summary comment** strikes the finding through and tags it `✗ Dismissed`, so the open-vs-closed split is visible without scrolling through every thread. * The **inline review thread** is marked resolved and collapsed. It can be reopened at any time via **Unresolve conversation**. * The **inline finding comment** itself is rendered with strikethrough, signalling that the suggestion was acknowledged and closed without requiring a code change. * **Discuss in natural language**\ Ask follow-up questions, request more detail, or push back on a suggestion. Qodo responds conversationally with the PR diff and thread as context. * **Report an incorrect rule or relationship**\ In the thread of a rule violation or cross-repo conflict finding, tell Qodo that the rule or relationship behind it is wrong. Qodo replies with a link to that rule or relationship in the Qodo portal, where you can correct it so future reviews do not repeat the finding. For more information, see [Fix the source of a finding in the portal](#fix-the-source-of-a-finding-in-the-portal). ## Triggering Qodo There are no fixed sub-commands inside the Chat. Qodo interprets your message in natural language. To address Qodo, start a message with any of: | Trigger | Description | | - | - | | `@qodo …` | Standard mention. | | `/qodo …` | Slash-style mention. | | `qodo …` | Bare mention at the start of a comment. | Address Qodo in every message you want it to act on, including follow-ups in a thread it has already replied to. Untagged replies are treated as reviewer discussion and left alone. To dismiss a finding, just tell Qodo in plain language (e.g., *"@qodo this is intentional, we want to keep the legacy behavior"*). Qodo will record the dismissal with the appropriate reason. ## Fix the source of a finding in the portal Some findings come from context that is configured in the Qodo portal, not only from the code in the pull request. Rule violations come from a [rule](/governance/rule-enforcement/generate-and-manage-rules) defined on the **Rules** page, and cross-repo conflicts come from a [repository relationship](/governance/cross-repo-code-review/repository-relationships) defined on the **Relationships** tab. When that context is wrong or outdated, dismissing the finding closes it in this PR, but the next review can raise it again. Qodo points you to the portal so you can fix the source. This applies to inline finding threads only: * **Cross-repo conflict**: When you say the relationship is wrong or outdated, such as the repositories no longer depending on each other, Qodo dismisses the finding and replies with a link to each relationship behind it. Links are labeled with the two repositories, such as `web-client -> api-server`, and open that relationship in the Relationships tab, where you can update or delete it. The thread stays open so the reply remains visible. * **Rule violation**: When you dismiss the finding as a false positive or reject it, Qodo's reply includes a **View rule** link to the rule. On the rule's page, you can update the rule or its scope, or disable it. * **Questions about the rule or relationship**: When you ask about the rule or relationship behind the finding, or question whether it applies, Qodo's answer includes the same link. Asking a question does not dismiss the finding. Qodo never changes a rule or relationship itself. You make the change in the portal, subject to your portal permissions. If Qodo cannot identify the specific relationship, the link opens the Relationships tab instead. ## Example conversations **Developer** ```text theme={null} @qodo I don't understand why this is flagged as a bug. The function looks correct to me. ``` **Qodo** ```text theme={null} The returned object is an array, but the code accesses it as if it were a single value on line 42. That will throw a TypeError at runtime. ``` **Developer** ```text theme={null} @qodo This is intentional, we're keeping the legacy behavior for backwards compatibility. ``` **Qodo** ```text theme={null} Got it. I've marked this finding as dismissed (intentional) and resolved the thread. ``` **Developer** ```text theme={null} @qodo Valid point, but we'll address this in a follow-up PR. ``` **Qodo** ```text theme={null} Understood. I've dismissed this finding as deferred so it won't block this PR. ``` **Developer** ```text theme={null} @qodo shared-lib was archived last quarter. That relationship is outdated, nothing consumes this anymore. ``` **Qodo** ```markdown theme={null} Got it. This cross-repo conflict has been dismissed. If the cross-repository relationship that produced it is incorrect or outdated, you can update or delete the corresponding relationship in the Qodo portal so future reviews use the right repositories: [web-client -> shared-lib](https://app.qodo.ai/management/relationships?repoId=8c1d2f6a-3e4b-4c5d-9a7e-1b2c3d4e5f60&relatedRepoId=2a9b7c4e-6d5f-4e3a-8b1c-0f9e8d7c6b5a&view=table). ``` In the PR, the `web-client -> shared-lib` link opens that relationship in the Qodo portal. **Developer** ```text theme={null} @qodo This rule does not apply here. Generated migration files are exempt from it. ``` **Qodo** ```markdown theme={null} Dismissed as a false positive. If the rule is incorrect or no longer relevant, you can update the rule or its scope, or disable it in the Qodo portal: [View rule](https://app.qodo.ai/rules/5969?state=active). ``` In the PR, the View rule link opens the rule in the Qodo portal. **Developer** ```text theme={null} @qodo This suggestion is wrong, the field is already validated upstream. ``` **Qodo** ```text theme={null} Thanks for the context. I've dismissed this finding as rejected. ``` **Developer** ```text theme={null} @qodo I pushed fixes for the open findings, can you review this PR again? ``` **Qodo** Qodo runs the review and posts the updated results in the PR. ## Guidelines for GitHub users GitHub does not always update bot responses in real time. After posting a message: 1. Refresh the page if you do not see the Qodo response indicator. 2. Refresh again after a few seconds if the full response does not appear. If Qodo still has not responded after a minute or two, post the message again in the same thread. ## Disable Chat with Qodo Chat with Qodo is enabled by default. To turn it off: ### Disable Chat with Qodo in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **Chat agent**. 3. Disable the **Chat with Qodo** toggle. For more information, see [Configure Workflow settings in the Qodo portal](/configuration/workflow#chat-agent). ### Disable Chat with Qodo in .pr\_agent.toml ```toml theme={null} [chat_agent] enabled = false ``` Default: `true`. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Remediate findings in pull requests](/code-review/remediate-findings-in-prs): Fix findings using chat or the remediation agent. * [Dismiss a code review finding](/code-review/dismiss-a-finding): Close a finding without fixing it and record why. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Anatomy of a Qodo Code Review Source: https://docs.qodo.ai/code-review/comment-anatomy Qodo surfaces code review feedback directly inside your pull requests in a way that is actionable, focused, and easy to resolve. Qodo's code review surfaces feedback directly inside your pull requests, structured incrementally from context to individual findings, so you can read, prioritize, and act on it without wading through noise. Each finding focuses on what requires attention and why, with clear links back to the relevant code. This page is a reference for that structure: each section below corresponds to a part of the pull request, in the order it appears. New to Qodo? It's recommended to read this reference page top to bottom. Already reviewing a pull request? Skip ahead to [Unpack a code review finding](#unpack-a-code-review-finding). ## Pull request summary Before presenting individual issues, Qodo provides context to help you understand *what changed* and *why it matters*. For more information about how this context is generated and configured, see [Generate a PR summary](/code-review/pr-summary). Pull request summary comment showing tags, walkthroughs, and file changes This includes the following sections: Qodo adds an AI-generated summary of the pull request's intent and impact. * By default, the summary is posted as a standalone comment and your original pull request description stays unchanged. * You can also configure Qodo to merge the summary into the native pull request description. This helps reviewers align quickly on the purpose of the pull request. Qodo tags each pull request and estimates how long the review will take, so reviewers can prioritize before opening a single file. Tags include: Bug fix, Tests, Enhancement, Documentation, and Configuration changes. Qodo breaks down the change in detail: * **Description:** A plain-language breakdown of what changed and why. * **Diagram:** An architecture diagram showing the flow and connections introduced by the change. * **High-Level Assessment:** Suggestions and alternatives for the author and reviewer to consider before or during review. Expanded diagram walkthrough showing the architecture flow and connections introduced by a pull request Qodo provides a file-level overview of the pull request. For each modified file, you can see: * The file path * The type of change (for example, Bug Fix or Enhancement) * Lines added and removed This helps reviewers understand the scope of the change set before examining individual findings. ## Code review findings overview After providing context, Qodo presents a findings overview covering category counts, the context behind the review, and each finding's quality impact and severity. Code review findings overview showing category counts, severity groups, and resolved findings with strikethrough This includes the following sections: Findings are grouped by category, with counts for each type. | Category | What it means | | - | - | | **🐞 Bugs** | Issues that may cause incorrect behavior or failures. | | **📘 Rule violations** | Violations of organizational or repository rules. | | **📎 Requirement gaps** | Missing or unmet business or ticket requirements. | | **🔗 Cross-repo conflicts** Beta | Breaking changes detected across repository boundaries. See [Cross-repository code review](/governance/cross-repo-code-review). | | **📜 Skill insights** Beta | Guidance or violations surfaced from a repository's skills. See [Manage skills across repositories](/governance/manage-skills-across-repositories). | This overview gives you an immediate sense of the review's focus and severity. When a review draws on additional context, such as [rules](/governance/rule-enforcement), [skills](/governance/manage-skills-across-repositories), or [cross-repo context](/governance/cross-repo-code-review), Qodo displays a **Context sources** section listing exactly what was applied. The section also carries the review's routing summary: a line such as *"2 issues published inline · 3 in summary"* showing at a glance how the findings were split between inline comments and the summary. Routing is controlled by the [Comments settings](/configuration/display#comments). Context sources section showing compliance rules, skills, and cross-repo context applied to the review When [web search](/code-review/use-qodo-in-prs/third-party-dependencies-context) contributes to a finding, the Context sources section also lists the external sources the agent referenced, such as official documentation, release notes, or specifications. Web search results shown in a pull request finding When cross-repo context contributes to a [cross-repository conflict](/code-review/view-cross-repo-conflicts-in-findings) finding, the Context sources section also links to the relationship behind it. Each explored repository has a **View relationship** link. Click it to open that relationship in the **Relationships** tab. Access follows your organization's portal permissions. For more information, see [View cross-repository conflicts](/code-review/view-cross-repo-conflicts-in-findings). Disable the **Show context** setting to exclude this section from the code review, for example if it adds noise for your own tooling that parses Qodo's PR comments. For more information, see [Configure Qodo using the portal](/configuration/display#comment-parts). In addition to categories, each finding includes a quality impact label. This label indicates which quality dimension is affected by the issue. Common labels include: | Label | What it means | | - | - | | **Correctness** | Issues that may cause incorrect behavior or wrong results. | | **Security** | Issues that could expose vulnerabilities or sensitive data. | | **Reliability** | Issues that may affect stability, error handling, or fault tolerance. | | **Performance** | Issues that impact efficiency, latency, or resource usage. | | **Observability** | Issues that affect logging, metrics, or system visibility. | These labels provide quick semantic context, helping you understand *what kind of quality is impacted* before diving into the full issue details. Findings showing quality impact labels such as Rule violation, Reliability, Bug, and Correctness Findings are grouped by severity, making it clear what needs attention first. | Severity | What it means | | - | - | | **High** | High-priority or blocking issues that should be addressed before merging, such as security or compliance violations, sensitive data exposure, or critical correctness issues. | | **Medium** | Non-blocking issues that improve code quality, maintainability, or consistency with defined standards. | | **Low** | Lower-impact or informational findings that provide context or optional guidance. | **High, Medium, and Low** are the default severity labels. You can rename them using the **Severity terminology** setting. For more information, see [Configure Qodo using the portal](/configuration/display#groups). This prioritization helps you focus on what matters most without losing visibility into the full set of findings. Findings grouped into High, Medium, and Low severity groups, each showing quality impact labels As you push new commits, Qodo marks the findings that no longer need action. A resolved finding is struck through and shows only its status, which keeps the focus on the open findings. Each resolved finding has one of these statuses: * ✓ Resolved: A later commit fixed the issue. * ✗ Dismissed: The finding was dismissed without a fix and no longer needs action. * ⊖ Outdated: The code the finding referred to was removed or rewritten. The finding no longer applies. By default, resolved findings stay in their group. You can move them to a separate **Resolved findings** section after the open findings, or hide them entirely. For more information, see [Track resolved findings](/code-review/track-resolved-findings). ## Unpack a code review finding Each finding can be expanded to reveal full details. You can access findings: * From the prioritized summary list * Inline, directly in the **Files changed** view Collapsed findings list grouped by severity, before expanding an individual finding Regardless of how you access it, each finding presents the same structured information. Click each tab below to see the different elements of a finding: A clear, human-readable explanation of the issue and its potential impact. Code review finding description explaining the issue and its potential impact * A snippet showing where the issue occurs * Direct links to the relevant lines in the pull request Code review finding code reference showing relevant snippet and pull request line links
Beta GitHub GitLab
Entries are generated automatically based on [PR history indexing](/core-concepts/pr-history). The **Relevance** section highlights related pull requests with similar findings from past reviews. This provides historical context by linking to previous pull requests where a similar issue was discussed, accepted, or rejected. Each entry includes: * A relevance classification indicating whether the finding has high, medium, or low relevance based on how similar findings were handled in past pull requests: * ⭐⭐⭐ **High**: Similar findings were typically accepted/fixed. * ⭐⭐ **Medium**: Mixed or inconclusive history. * ⭐ **Low**: Similar findings were typically ignored. * A brief explanation of the historical pattern * Links to relevant past pull requests * An indicator that the insight was generated from similar findings Code review finding relevance section showing similar findings from past pull requests For more information about how this classification works, see [Prioritize findings using Relevance](/code-review/relevance). Context explaining *why* the issue was flagged, such as: * The specific rule involved, linked to that rule in the Qodo portal * For cross-repo conflicts, the repository relationship behind the finding, linked to that relationship in the Qodo portal * Linked requirements or tickets (when applicable) Click a rule link to open the rule's side panel on the **Rules** page, where you can check what the rule requires. Admins can also edit the rule there. Rules that have a standard ID are shown by ID without a link. Click a relationship link, labeled with the two repositories such as `web-client -> api-server`, to open that relationship on the Relationships tab. For more information, see [View cross-repository conflicts](/code-review/view-cross-repo-conflicts-in-findings#cross-repository-conflict-details). On Gerrit, the rule name in an inline finding comment also links to the rule. This transparency makes it easier to trust and validate the feedback. Code review finding evidence section showing rule and linked requirements context For issues that can be fixed programmatically, Qodo provides an **agent prompt**. You can copy the prompt and use it in an AI coding tool to apply the suggested fix with full context, helping you move from feedback to resolution faster. Code review finding agent prompt for applying the suggested fix with AI assistance GitHub GitLab For small, inline findings in a single file, Qodo attaches a commit-ready fix directly to the comment. You can apply it without switching to your local environment. * Click **Apply Suggestion** to commit the fix immediately. * Click **Add suggestion to batch** to group multiple fixes into a single commit. For more information, see [Commit code fixes directly in the pull request](/code-review/commitable-code-suggestions). Each finding includes two links that open it in the Qodo portal: * **Dismiss**: Opens the finding directly in the portal's dismiss reason picker. * **View**: Opens the finding in the portal without dismissing it, showing the same detail panel described throughout this reference. Both links route you from the pull request to the Qodo portal, directly to this finding. If you're not already signed in, you're prompted to sign in first. For more information, see [Dismiss a finding](/code-review/dismiss-a-finding). Findings from all pull requests are also tracked centrally in the Qodo portal. For more information about filtering and monitoring findings across all repositories, see [Monitor organization-wide pull request findings](/governance/view-all-findings-in-organization). ## Previous reviews (formerly Audit trail) Qodo keeps a collapsible **Previous reviews** section in the comment, showing the history of past review runs on the pull request. It renders like the comment's other collapsible parts (Context sources, Tip of the day) and sits between the daily tip and the footer: * A **Review updated until commit** line links to the commit the current review reflects. * Each earlier commit has its own collapsible **Results up to commit** entry. * A review-mode badge, for example 🚀 Fast or ⚖️ Balanced, shows which mode produced the review. * Expanding an entry surfaces the full set of findings from that earlier review run. Findings that were later resolved appear struck through with a resolved mark, reflecting the current state of every finding. This helps reviewers see how the review evolved as new commits were pushed. Disable the **Show previous reviews** setting, under **Comment parts** in the portal's **Display** tab, to hide this section from the review comment. For more information, see [Configure Qodo using the portal](/configuration/display#comment-parts). Previous reviews section showing review history up to each commit ## Native pull request labels Beyond the review comment itself, Qodo can publish select signals as native labels directly in your Git provider's pull request interface, for example in the Labels sidebar or the pull request list. * **Review time estimate**: See [Generate a PR summary](/code-review/pr-summary#publish-the-review-time-estimate-as-a-native-label-or-tag). * **Blast radius**: See [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius). ## Related resources * [Prioritize findings using Relevance](/code-review/relevance): See how likely each finding is to matter, based on your team's history. * [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius): Triage pull requests by the risk of the change. * [Dismiss a code review finding](/code-review/dismiss-a-finding): Close a finding without fixing it and record why. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Determine where Qodo posts the PR summary Source: https://docs.qodo.ai/code-review/comment-location Control where Qodo publishes the PR summary: as a standalone comment or in the native pull request description. When a developer or coding agent opens a pull request, they typically provide a description. The PR summary from Qodo and the native pull request description provided by the user can be combined into a single comment or kept separate. By default, Qodo posts the PR summary as a standalone comment and does not modify the native pull request description. You can change this setting from the portal or in your `.pr_agent.toml` file. ## Determine the location of the PR summary | Location | Behavior | | - | - | | **Standalone comment** (default) | The PR summary from Qodo is published as a standalone comment, separate from the user's native pull request description, which stays unchanged. | | **Native PR description** | The PR summary from Qodo and the user's description are merged into a single comment with a separator. The combined comment is posted where the pull request description typically appears natively. | | **Dynamic location** | Qodo selects the best location for the PR summary automatically. If the user doesn't provide a pull request description, the PR summary is posted in the native location; otherwise it is posted as a standalone comment. | ## Configure the PR summary location ### Configure the PR summary location in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **PR summary**. 3. Select an option under **Comment location**. These settings apply to all connected repositories unless overridden at the repository level. For more information, see [Configure Qodo using the portal](/configuration/portal-configuration). ### Configure the PR summary location in .pr\_agent.toml Set `publish_mode` in the `[qodo_describe_agent]` section of your `.pr_agent.toml`: ```toml theme={null} [qodo_describe_agent] publish_mode = "comment" ``` | Value | Location | | - | - | | `comment` (default) | Standalone comment | | `pr_description` | Native PR description | | `dynamic` | Dynamic location | For more information, see [Configure using .pr\_agent.toml file](/configuration/configuration-file). ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#pull-request-summary): The parts of the PR summary and how to read them. * [Generate a PR summary](/code-review/pr-summary): What the summary includes and how to generate it. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Commit code fixes directly in the pull request Source: https://docs.qodo.ai/code-review/commitable-code-suggestions Qodo can generate code suggestions that you can apply directly to your pull request with a single click.
GitHub GitLab
The **Committable code suggestions** feature provides commit-ready fixes directly in code review comments. For small, isolated findings like a redundant check, an off-by-one, or a missing guard clause, there's no need to switch to your local environment. Qodo analyzes the finding, generates a precise fix, and lets you apply it with a single click. Committable suggestions are scoped to changes that are self-contained and easy to verify, so you can apply them with confidence knowing the fix won't introduce new issues. This feature uses GitHub's native suggestion workflow, allowing you to incorporate feedback directly into your pull request from review comments. For more information, see [Incorporating feedback in pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request). As with any AI-generated code change, review the proposed diff before applying it to confirm it is appropriate for your codebase. You'll find **Committable code suggestions** listed under the Committable code suggestion section in the Qodo feedback panel. ## Rules and guidelines Not every finding qualifies for a committable suggestion, and that's intentional. A suggestion is only committable when it meets all of the following criteria: * The finding is inline (line-level, not a general comment) * It touches a single file * The fix is five lines or fewer Fixes that span multiple files, involve complex logic, or could introduce unintended side effects are deliberately excluded. The goal is confidence: if Qodo offers a committable suggestion, it's because the fix is contained, verifiable, and safe to apply directly. ## Enable Suggest committable fixes ### Configure committable fixes in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Remediation**. 3. Enable **Suggest committable fixes**. Enabled by default. For more information, see [Configure Remediation settings in the Qodo portal](/configuration/remediation). ### Configure committable fixes in .pr\_agent.toml ```toml theme={null} [review_agent] enable_commitable_suggestions = true ``` | Value | Behavior | | - | - | | `true` | Auto-attaches committable suggestions to eligible inline findings | | `false` (default) | Disables committable suggestions | ## Review and commit the suggestions 1. In your PR, expand the **Committable code suggestion** comment. A diff is displayed showing the suggested fix. Commitable Code suggestion A diff is displayed providing the options to apply the changes. Apply commitable suggestion 2. Click one of the following options: * Click **Apply Suggestion** to commit the fix immediately. * Click **Add suggestion to batch** to accumulate multiple changes and commit them together. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Remediate findings in pull requests](/code-review/remediate-findings-in-prs): Fix findings using chat or the remediation agent. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Dismiss a code review finding Source: https://docs.qodo.ai/code-review/dismiss-a-finding Close a finding without fixing it and record why, from the Findings page in the Qodo portal or directly from the pull request. Dismiss a finding when it doesn't need a code change, instead of leaving it open. Dismissing records the reason, giving reviewers visibility into what was considered, and showing that the finding was deliberately dismissed rather than simply missed. Dismissing shows a strikethrough on the finding's title, changes its state to **Dismissed**, and collapses the detail panel to just **Dismissal reason**, including any explanation you gave. If Qodo can't complete one of these updates on GitHub, the portal shows **Finding dismissed with incomplete GitHub updates** and lists what failed. The finding stays dismissed either way. A dismissal cannot be undone. You can dismiss it directly in the pull request, or in the Qodo portal. A finding can also be dismissed using [chat](/code-review/chat-with-qodo-in-your-pull-requests#what-you-can-ask-qodo-to-do), or directly from a connected coding agent using the [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-review-resolver-skill). ## Dismiss from the pull request Dismiss and View only appear on open findings. Resolved, dismissed, or outdated findings don't show them. 1. On the finding inside the PR, select **Dismiss**. This routes you from the PR to the Qodo portal, directly to this finding. If you're not already signed in, you're prompted to sign in first, and this link requires Qodo portal access. 2. From the drop-down menu, select a [reason](#reasons-to-dismiss-a-finding), and optionally add details in **Explain your reasoning**. 3. Select **Dismiss finding**. 4. Select **Back to PR** to return to where you left off, or stay in the portal on this finding, with the detail panel open. ## Dismiss from the Findings page 1. In the Qodo portal, select **Findings** from the left navigation. 2. Click the finding to open its detail panel. 3. Select **Dismiss**, in the top-right corner of the panel. 4. From the drop-down menu, select a [reason](#reasons-to-dismiss-a-finding), and optionally add details in **Explain your reasoning**. 5. Select **Dismiss finding**. ## Reasons to dismiss a finding A reason is required. The explanation is optional. | Reason | Meaning | | - | - | | **False positive** | The finding is incorrect for this code. | | **Intentional** | The code is written this way on purpose. | | **Fix later** | Valid, but not for this PR. | | **Not specified** | Dismiss without a specific reason. | Explanations can be up to 2,000 characters. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#unpack-a-code-review-finding): Every element of a finding, including Dismiss and View. * [Chat with Qodo in pull requests](/code-review/chat-with-qodo-in-your-pull-requests#what-you-can-ask-qodo-to-do): Dismiss a finding by asking Qodo in plain language instead. * [Monitor organization-wide pull request findings](/governance/view-all-findings-in-organization): Track findings, including dismissed ones, across repositories. # Enable automatic CI failure feedback Source: https://docs.qodo.ai/code-review/enable-ci-failure-feedback Configure Qodo to automatically surface structured CI failure analysis, including failed stages, test names, and error logs, directly inside pull requests.
GitHub
Qodo provides automatic CI feedback when a pull request contains failed checks. When a CI failure is detected, Qodo analyzes the results and surfaces structured, actionable information directly in the pull request to help you quickly understand and resolve the issue. The CI feedback includes: * **Failed stage**: The pipeline stage where the failure occurred * **Failed test name**: The specific test or job that failed * **Failure summary**: A concise explanation of what went wrong * **Relevant error logs**: Extracted log output to aid debugging This feedback helps reduce context switching by keeping CI failure analysis inside the pull request, where you are already working. ## Request CI feedback manually Comment on the pull request: ```bash theme={null} /checks "https://github.com/{repo_name}/actions/runs/{run_number}/job/{job_number}" ``` Where: * `{repo_name}` is the name of the repository. * `{run_number}` is the run number of the failed check. * `{job_number}` is the job number of the failed check. ## Configure CI failure feedback in .pr\_agent.toml ### Turn off automatic feedback To stop the tool from running automatically, add the following to the [configuration file](/configuration/configuration-file): ```js theme={null} [checks] enable_auto_checks_feedback = false ``` ### Configuration options Configure the `checks` tool by setting configurations under the `checks` part in your [configuration file](/configuration/configuration-file). | Configuration key | Default value | Description | | - | - | - | | `enable_auto_checks_feedback` | `false` | Automatically provides feedback when a CI check fails on a pull request. | | `excluded_checks_list` | `["lint"]` | A list of CI checks to exclude from feedback (for example: `["check1", "check2"]`). | | `persistent_comment` | `true` | Updates an existing CI feedback comment instead of posting a new one for each run. | | `enable_help_text` | `false` | Displays a help message when a user comments `/checks` on a pull request. | | `final_update_message` | `false` | When `persistent_comment` is enabled, posts an additional message indicating that the CI feedback was updated to the latest commit. | Example: PR comment showing a failed CI check with details from Qodo Expanded CI check failure details shown in a pull request comment Example output of CI failure feedback displayed as a Qodo comment on a pull request ## Related resources * [Trigger a code review](/code-review/use-qodo-in-prs): Run reviews automatically or manually. * [Configure Qodo using the .pr\_agent.toml file](/configuration/configuration-file): Set up and manage repository-level configuration. # Configure extra instructions Source: https://docs.qodo.ai/code-review/extra-instructions Customize how Qodo reviews your code by passing extra instructions to the Issue finding agent, Compliance agent, or Review effort mode, using the Qodo portal, your .pr_agent.toml configuration file, or directly in a PR comment for a single review. You can customize how Qodo reviews your code by passing extra instructions to the **Issue finding agent**, **Compliance agent**, or the review effort agent. Instructions can be configured in the Qodo portal, in your `.pr_agent.toml` file, or included directly in a PR comment for a single review. The `/agentic_review` command supports three instruction parameters, one per agent: * `issues_user_guidelines`: extra instructions for the Issue finding agent, which handles bug, security, and performance detection * `compliance_user_guidelines`: extra instructions for the Compliance agent, which handles rule checking * `smart_router_extra_instructions`: extra instructions for the review effort agent, which decides how much review depth a pull request needs. See [Control review effort](/code-review/use-qodo-in-prs/control-review-effort) for the full set of review effort controls. ## Configure extra instructions ### Configure extra instructions in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Prompts**. 3. Add custom instructions for the **Issue finding agent**, **Compliance agent**, or **Review effort mode**. Portal settings apply organization-wide when no repository-level configuration is defined. For more information, see [Configure Prompts settings in the Qodo portal](/configuration/prompts). ### Configure extra instructions in .pr\_agent.toml Add the following to your `.pr_agent.toml`: ```toml theme={null} [review_agent] issues_user_guidelines = "Focus on security vulnerabilities and input validation" compliance_user_guidelines = "Check for GDPR compliance requirements" smart_router_extra_instructions = "Treat database migration files as high risk" ``` ## Use a PR comment To apply instructions for a single review without changing your config file, include them as parameters when triggering `/agentic_review` in a PR comment: ``` /agentic_review --review_agent.issues_user_guidelines="Focus on security vulnerabilities" --review_agent.compliance_user_guidelines="Check for GDPR compliance" --review_agent.smart_router_extra_instructions="Treat database migrations as high risk" ``` ## Related resources * [Trigger a code review](/code-review/use-qodo-in-prs): Run reviews automatically or manually. * [Optimize AI effort with Review effort mode](/code-review/use-qodo-in-prs/control-review-effort): Match review depth to the risk of each change. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Control where review feedback appears in pull requests Source: https://docs.qodo.ai/code-review/feedback-location Controls where Qodo's review feedback appears in a pull request. Surface feedback as a high-level summary, inline on the relevant code, or both, depending on how your team prefers to review and fix issues. This setting helps balance visibility vs. focus: summaries are useful for understanding the overall state of a PR, while inline comments are ideal for resolving issues directly in context. To route each action level to a different location instead of applying one setting to all findings, see [Control review verbosity](/code-review/review-verbosity). ## Configure feedback location ### Configure feedback location in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Display** > **Comments**. 3. Select a **Comment type**. For more information, see [Configure Display settings in the Qodo portal](/configuration/display#comments). ### Configure feedback location in .pr\_agent.toml ```toml theme={null} [review_agent] comments_location_policy = "both" ``` Supported values: * **`summary`** Feedback appears only in the **Conversation** tab. Best for reviewing the overall impact and prioritization of findings. * **`inline`** Feedback appears only in the **Files changed** view. Best for fixing issues directly next to the affected code. * **`both`** Feedback appears in both the summary and inline views. **(default)** Summary example: Code Review by Qodo showing findings listed in the pull request conversation tab Inline example: Code Review by Qodo showing a finding as an inline comment anchored to changed lines in the files tab ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Control review verbosity in pull requests](/code-review/review-verbosity): Route each severity's findings to inline comments, the summary, or both. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Control findings visibility and expansion in pull requests Source: https://docs.qodo.ai/code-review/findings-visibility Configure how many findings are shown, collapsed, or expanded in pull request reviews to keep feedback focused without losing full visibility. Large pull requests can generate many findings, which can clutter the review and make it harder to focus on what matters. Qodo addresses this by showing only a subset by default, the rest collapse behind View all and stay one click away, nothing is discarded. You can also control how each finding's individual components (for example, description or code) are shown or expanded, separately for the summary comment and for inline comments. This page describes how to control what's shown within a finding, not where it's published. For choosing whether findings appear inline, in the summary comment, both, or not at all by severity, see [Control review verbosity](/code-review/review-verbosity). ## Configure findings visibility in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Display**. 3. Configure the following settings: * **Finding overflow**: How many findings are shown before the rest collapse behind "View all." Set under **Overflow** > [Findings visible per group](/configuration/display#overflow). * **Per-finding verbosity**: Whether each part of a finding is hidden, collapsed, or expanded in the summary comment. Set under **Findings** > [Finding content sections](/configuration/display#findings). * **Show content section titles**: Shows a label above each finding part in the summary comment. Set under **Findings** > [Show content section titles](/configuration/display#findings). * **Inline comment sections**: Whether each part of a finding is shown in the inline comment. Set under **Findings** > [Inline findings](/configuration/display#findings). * **Link finding summary to inline findings**: Links a summary finding's title to its inline comment. Set under **Comment routing** > [Link finding summary to inline findings](/configuration/display#comments). Currently supported on Bitbucket and Gerrit only. * **Resolved findings**: Whether resolved findings are shown, where they appear, and how much of the resolved section is shown. Set under [Resolved findings](/configuration/display#resolved-findings). ## Configure findings visibility in .pr\_agent.toml ### Finding overflow
GitHub GitLab Azure DevOps
Control how many findings are shown before the rest collapse behind **"View all"**. ```toml theme={null} [review_agent_ux] finding_overflow_count = 3 ``` | Value | Behavior | | - | - | | `0` | All findings collapsed | | `1`, `3` (default), `5` | Number of findings shown before "View all" | | `-1` | All findings expanded (the portal shows this option as "All") | ### Resolved findings Control whether resolved findings are shown, whether they stay in place or move to a separate section, and how much of that section is shown. ```toml theme={null} [review_agent_ux] show_resolved_findings = true resolved_findings_placement = "resolved_section" resolved_overflow_count = 0 ``` `resolved_overflow_count` applies only when `resolved_findings_placement` is `"resolved_section"`. For more information about each value and how it renders by Git provider, see [Track resolved findings](/code-review/track-resolved-findings). ### Per-finding verbosity
GitHub GitLab Azure DevOps
For each part of a finding, control whether it's hidden, shown collapsed, or shown expanded in the summary comment. Each part is controlled by two keys: `render_*` sets whether the part is shown at all, `expand_*` sets whether it's expanded or collapsed when shown. ```toml theme={null} [review_agent_ux] render_description = true expand_description = true render_code = true expand_code = false render_recommendation = true expand_recommendation = false render_evidence = true expand_evidence = false expand_prompt = false ``` | Part | Keys | Default | | - | - | - | | Description | `render_description`, `expand_description` | Expanded | | Code | `render_code`, `expand_code` | Collapsed | | Relevance | `render_recommendation`, `expand_recommendation` | Collapsed | | Evidence | `render_evidence`, `expand_evidence` | Collapsed | | Agent prompt | `render_prompt`, `expand_prompt` | Collapsed | To hide a part entirely, set its `render_*` key to `false`. Agent prompt doesn't set `render_prompt` by default. Unset, it falls back to the legacy `show_prompt` key (`true`), which combined with `expand_prompt = false` gives it a default of Collapsed, not Hidden. Setting `render_prompt` explicitly overrides `show_prompt`. ### Show content section titles
Bitbucket Gerrit
Shows the section titles (Description, Code, Agent Prompt) above each finding part in the summary comment. Currently supported on Bitbucket and Gerrit only. ```toml theme={null} [review_agent_ux] show_subsection_names = false ``` Default: `false`. ### Inline comment sections For each part of a finding, control whether it's shown in the inline comment attached to the code line, separately from the summary comment. Each part is either shown or hidden. ```toml theme={null} [review_agent_ux] inline_render_description = true inline_render_code = false inline_render_evidence = false inline_render_recommendation = false inline_render_prompt = true ``` | Part | Key | Default | | - | - | - | | Description | `inline_render_description` | Shown | | Code | `inline_render_code` | Hidden | | Relevance | `inline_render_recommendation` | Hidden | | Evidence | `inline_render_evidence` | Hidden | | Agent prompt | `inline_render_prompt` | Shown | Unset, `inline_render_description` and `inline_render_prompt` follow the summary comment's `render_description` and `render_prompt`. `inline_render_code`, `inline_render_evidence`, and `inline_render_recommendation` stay hidden regardless of the summary comment's settings. ### Link finding summary to inline findings
Bitbucket Gerrit
When a finding is published as both a summary and an inline comment, link the summary finding's title to its inline comment. ```toml theme={null} [review_agent_ux] link_findings_to_inline_comments = true ``` Default: `true`. Currently supported on Bitbucket and Gerrit only. On GitHub, GitLab, and Azure DevOps, the summary comment is published before the inline comments exist, so there's no URL yet to link to, and the setting has no effect. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Track resolved findings in pull requests](/code-review/track-resolved-findings): Show resolved findings in place, in a separate section, or not at all. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Generate labels automatically Source: https://docs.qodo.ai/code-review/generate-pr-labels Automatically generate and apply relevant labels or hashtags based on code changes, using predefined or custom label definitions. GitHub GitLab Gerrit The Generate Labels feature analyzes code changes in a Pull Request (PR) or Gerrit change and suggests relevant labels. On Gerrit, Qodo applies generated labels as hashtags. Suggestions are based on a predefined set of labels and their descriptions. Generated labels can reflect the type of change, impacted areas, or nature of the update, which helps you triage and track PRs and Gerrit changes. Gerrit support is available for on-premises deployments. The dedicated Qodo user requires the [Edit Hashtags permission](https://gerrit-review.googlesource.com/Documentation/access-control.html#category_edit_hashtags) on `refs/heads/*`. ## Generate labels manually You can trigger label generation directly from the pull request using a comment command: ```bash theme={null} /generate_labels ``` ## Configure custom labels in .pr\_agent.toml Qodo supports custom labels in two ways, depending on how you manage configuration in your environment. This section covers `.pr_agent.toml`. To use labels defined in the repository instead, see [Configure custom labels from the repository labels page](#configure-custom-labels-from-the-repository-labels-page). You can enable and configure custom labels directly at the repository level. To do this, apply the relevant configuration changes in the local `.pr_agent.toml` file in your repository. ### Custom label format When defining custom labels in `.pr_agent.toml`, use the following format: * **Label name**: The name of the custom label. * **Description**: A comprehensive, detailed description explaining when Qodo should suggest this label for a pull request. **Example:** * **Label name:** `security` * **Description:** `Suggest this label when the PR introduces authentication/authorization logic, handles secrets, touches crypto, or modifies security-sensitive endpoints.` ### Enable custom labels After adding custom labels, they become available for use by Qodo’s label generation feature. In your repository's `.pr_agent.toml` file: * Set `enable_custom_labels` to `True`: This will disable the default labels and enable the custom labels you define. * Add the custom labels. It should be formatted as follows: ```js theme={null} [config] enable_custom_labels=true [custom_labels."Custom Label Name"] description = "Description of when AI should suggest this label" [custom_labels."Custom Label 2"] description = "Description of when AI should suggest this label 2" ``` **Example:** If you want Qodo to detect changes to SQL queries in a pull request, you can add a custom label with a clear description that explains when it should be applied: Custom labels list showing configured labels with names and descriptions When the `generate_labels` feature runs on a pull request that includes SQL-related changes, Qodo will automatically suggest this custom label: Qodo suggesting a custom label on a pull request with SQL-related changes Note that custom labels are not only used by `generate_labels`. They are also taken into account by the PR description feature, helping enrich summaries and classifications. ## Configure custom labels from the repository labels page
GitHub GitLab
Qodo can also work directly with labels defined in the repository itself. When enabled, Qodo reads labels from the repository’s labels page and uses them as candidates when suggesting labels for pull requests. * **GitHub:** `https://github.com/{owner}/{repo}/labels`, or click the **Labels** tab in the issues or PR's page. * **GitLab:** `https://gitlab.com/{owner}/{repo}/-/labels`, or click **Manage** and then **Labels** from the left menu. To make a repository label discoverable this way, start its description with the prefix `pr_agent:`. This prefix is how Qodo tells label candidates apart from the rest of the repository's labels, and applies only to this configuration method. **Example (GitHub or GitLab label description):** `pr_agent: Suggest this label when the PR introduces authentication/authorization logic, handles secrets, touches crypto, or modifies security-sensitive endpoints.` GitHub repository Labels page showing a label's description field with the required pr_agent: prefix ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#native-pull-request-labels): How native pull request labels fit into the review. * [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius): Triage pull requests by the risk of the change. * [Configure Qodo using the .pr\_agent.toml file](/configuration/configuration-file): Set up and manage repository-level configuration. # Ignore content from analysis Source: https://docs.qodo.ai/code-review/ignore-content-from-analysis Qodo allows you to control what is excluded from analysis, including pull requests, files, and folders. Ignoring content helps reduce noise from automated changes, generated code, or areas that are out of scope, ensuring reviews focus only on relevant updates. You can prevent automatic reviews from running on certain pull requests based on specific criteria: * PRs with specific titles (using regex matching) * PRs between specific branches (using regex matching) * PRs from specific repositories (using regex matching) * PRs not from specific folders * PRs containing specific labels * PRs opened by specific users * PRs generated files by language/framework * Ignore tickets with specific labels ## Configure ignore rules in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **Ignore PRs**. 3. Configure the title, author, label, and branch settings. For more information, see [Configure Workflow settings in the Qodo portal](/configuration/workflow#ignore-prs). ## Configure ignore rules in .pr\_agent.toml If you're not using the portal, configure any of the settings below directly in your `.pr_agent.toml` file. ### Ignore PRs with specific titles To ignore PRs with a specific title such as "\[Bump]: ...", you can add the following to your [configuration file](/configuration/configuration-file): ```bash theme={null} [config] ignore_pr_title = ["\\[Bump\\]"] ``` Where the `ignore_pr_title` is a list of regex patterns to match the PR title you want to ignore. Default is `ignore_pr_title = ["^\\[Auto\\]", "^Auto"]`. ### Ignore PRs between specific branches To ignore PRs from specific source or target branches, you can add the following to your [configuration file](/configuration/configuration-file): ```js theme={null} [config] ignore_pr_source_branches = ['develop', 'main', 'master', 'stage'] ignore_pr_target_branches = ["qa"] ``` Where the `ignore_pr_source_branches` and `ignore_pr_target_branches` are lists of regex patterns to match the source and target branches you want to ignore. They are not mutually exclusive, you can use them together or separately. ### Ignore PRs from specific repositories To ignore PRs from specific repositories, you can add the following to your [configuration file](/configuration/configuration-file): ```js theme={null} [config] ignore_repositories = ["my-org/my-repo1", "my-org/my-repo2"] ``` Where the `ignore_repositories` is a list of regex patterns to match the repositories you want to ignore. This is useful when you have multiple repositories and want to exclude certain ones from analysis. ### Ignore PRs not from specific folders To allow only specific folders (often needed in large monorepos), set: ```js theme={null} [config] allow_only_specific_folders=['folder1','folder2'] ``` For the configuration above, automatic feedback will only be triggered when the PR changes include files where 'folder1' or 'folder2' is in the file path ### Ignore PRs containing specific labels To ignore PRs containing specific labels, you can add the following to your [configuration file](/configuration/configuration-file): ```js theme={null} [config] ignore_pr_labels = ["do-not-merge"] ``` Where the `ignore_pr_labels` is a list of labels that when present in the PR, the PR will be ignored. ### Ignore PRs from specific users Qodo tries to automatically identify and ignore pull requests created by bots using: * GitHub's native bot detection system * Name-based pattern matching While this detection is robust, it may not catch all cases, particularly when: * Bots are registered as regular user accounts * Bot names don't match common patterns To supplement the automatic bot detection, you can manually specify users to ignore. Add the following to your [configuration file](/configuration/configuration-file) to ignore PRs from specific users: ```js theme={null} [config] ignore_pr_authors = ["my-special-bot-user", ...] ``` Where the `ignore_pr_authors` is a regex list of usernames that you want to ignore. There is one specific case where bots will receive an automatic response - when they generated a PR with a *failed test*. In that case, the [`ci_feedback`](https://qodo-merge-docs.qodo.ai/tools/ci_feedback/) tool will be invoked. ### Ignore generated files by language/framework To automatically exclude files generated by specific languages or frameworks, you can add the following to your [configuration file](/configuration/configuration-file): ```js theme={null} [config] ignore_language_framework = ['protobuf', ...] ``` You can view the list of auto-generated file patterns in [`generated_code_ignore.toml`](https://github.com/qodo-ai/pr-agent/blob/main/pr_agent/settings/generated_code_ignore.toml). Files matching these glob patterns will be automatically excluded from PR Agent analysis. ### Ignore tickets with specific labels When Qodo analyzes tickets (JIRA, GitHub Issues, GitLab Issues, etc.) referenced in your PR, you may want to exclude tickets that have certain labels from the analysis. This is useful for filtering out tickets marked as "ignore-compliance", "skip-review", or other labels that indicate the ticket should not be considered during PR review. To ignore tickets with specific labels, add the following to your [configuration file](/configuration/configuration-file): ```js theme={null} [config] ignore_ticket_labels = ["ignore-compliance", "skip-review", "wont-fix"] ``` Where `ignore_ticket_labels` is a list of label names that should be ignored during ticket analysis. ### Ignore PRs opened by bots and AI agents By default, Qodo does not review pull requests opened by bot accounts: ```toml theme={null} [config] ignore_bot_pr = true ``` These PRs are skipped silently. No review runs and no comment is posted. A PR is treated as bot-authored when any of the following is true: * The Git platform marks the author as a bot, such as a GitHub App account like `my-agent[bot]`. * The author's username matches a bot-like heuristic. This includes fragments such as `-bot`, `[bot]`, `jenkins`, `service`, `cicd`, or `assistant` as a separate word, as well as the exact usernames `claude`, `augment`, and `codex`. Ordinary human-owned service accounts, such as `deploy-jenkins-ci`, may also match. * The PR description contains an automation phrase such as `This PR was created automatically by`. #### Enabling reviews for bot PRs To enable reviews for PRs opened by bots, including AI coding agents, add the setting to `.pr_agent.toml` under the section for your Git provider: ```toml theme={null} [github_app] ignore_bot_pr = false ``` When a provider section does not set `ignore_bot_pr`, the setting falls back to the value under `[config]` (default `true`). Setting `ignore_bot_pr` under `[config]` applies to every provider unless a provider's own section overrides it. Placing it under `[github]` (without `_app`) has no effect. Place `.pr_agent.toml` at the repo root on the default branch so the Qodo app can read it. For an org-wide default, add it to the root of a repository named `pr-agent-settings` in your organization, which the Qodo app must have access to. The setting takes effect on the next PR the bot opens. | Provider | Section | | :- | :- | | GitHub | `[github_app]` | | GitLab | `[gitlab]` | | Bitbucket Cloud | `[bitbucket_app]` | | Bitbucket Data Center | `[bitbucket_server]` | | Azure DevOps | `[azure_devops_server]` | | Gerrit | `[gerrit]` | #### Reviewing selected bot PRs while keeping other bots ignored Setting `ignore_bot_pr = false` enables reviews for every bot author. To keep specific bots excluded, combine it with `ignore_pr_authors`, which accepts regular expressions matched against the author's username: ```toml theme={null} [github_app] ignore_bot_pr = false [config] ignore_pr_authors = ["dependabot", "renovate"] ``` #### Rules and guidelines * A team member can always trigger a review on a bot-authored PR by commenting `/agentic_review`, even when `ignore_bot_pr` is set to `true`. * This setting affects PRs opened or updated by bots. Comments posted by bot accounts receive a response only when they contain slash commands such as `/qodo ` or `/agentic_review`. Mentions such as `@Qodo` from bot accounts are ignored. * On self-hosted deployments using the classic GitHub App webhook server, the repository-level override may not apply. In that case, set `ignore_bot_pr = false` in the deployment configuration instead. Classic self-hosted deployments for GitLab, Bitbucket Data Center, and Azure DevOps do not have a deployment-level switch for this setting. ## Related resources * [Trigger a code review](/code-review/use-qodo-in-prs): Run reviews automatically or manually. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # How Qodo code review works Source: https://docs.qodo.ai/code-review/overview Qodo combines multi-agent review, deep repository context, and continuous learning to deliver high-signal, actionable feedback on every pull request. Qodo accelerates code reviews and improves the quality of your applications by surfacing bugs and issues in your code. Qodo integrates seamlessly into your Git workflows, helping you review and understand AI-generated code. It ensures that every line of code in production aligns with best practices and meets your organization's engineering standards. As AI generates more code, reviewing that code safely requires more than generic checks or long lists of comments. Qodo is built for that shift. ## What the review surfaces Qodo analyzes pull requests using specialized review agents that evaluate code from multiple perspectives. These agents surface findings such as: * **Bugs:** Logic errors, edge cases, and anti-patterns in the change. * **Rule violations:** Deviations from your organization's standards. * **Requirement gaps:** Where a pull request misses its linked spec. * **UX deviations:** Where the implementation diverges from linked Figma designs. * **Cross-repository conflicts:** Breaking changes that affect related repositories. * **Skill-related findings:** Issues raised by your repositories' skills. These agents draw on four sources of context: your full codebase and its architecture, your [pull request history](/core-concepts/pr-history), linked tickets and requirements, and your organization's standards and policies. They assess changes as a principal software architect would, not as isolated diffs. ## Findings you can act on For each finding, Qodo explains: * What needs attention * Why it matters * How to move forward All feedback appears directly inside your pull requests, where you already work. Qodo code review findings panel showing prioritized issues grouped by High and Medium severity in a pull request ## Accuracy without noise Qodo is designed to deliver both high recall and high precision. Combining multiple review agents with shared context lets Qodo catch what a single-pass review misses, while filtering out low-impact or irrelevant comments before they reach the pull request. This precision keeps improving over time: Qodo continuously learns from how your team has handled similar findings in the past, so review feedback stays aligned with how your team actually works, not just generic best practices. The result is a review experience you trust and act on. ## Review Standards in code review At the core of the code review experience are Qodo's [Review Standards](/governance/review-standards). Review Standards capture your organization's conventions from multiple sources, including your codebase, pull request history, and defined requirements. They continuously evolve over time and serve as a single source of truth for how code should be written and reviewed. During every pull request, Qodo's review agents apply these Review Standards in context. This ensures feedback is consistent, relevant, and aligned with how your organization actually builds software, not generic best practices. ## Next steps * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. * [Anatomy of a finding](/code-review/comment-anatomy): See a finding's severity, evidence, and recommended fix. * [Code review capabilities and FAQ](/code-review): Browse the full capability index and answers to common questions. # Enable persistent review comments Source: https://docs.qodo.ai/code-review/persistent-review-comments Persistent review comments allow Qodo to update an existing review comment when new commits are pushed, instead of posting a new review each time. Instead of posting a new comment for every push, Qodo keeps a single review comment up to date across a pull request's lifetime. On this page, "persistent" refers only to the code review comment described in [How persistent review comments are updated](#how-persistent-review-comments-are-updated). It's unrelated to the PR summary's [Standalone comment](/code-review/comment-location) setting and to CI failure feedback's own [`persistent_comment`](/code-review/enable-ci-failure-feedback) setting, since each applies to a different comment. ## Why use persistent review comments Persistent review comments help teams: * Keep pull request conversations clean * Track progress across commits more easily * Reduce noise during iterative reviews ## How persistent review comments are updated * With every new commit, Qodo updates the existing review comment. * If a new issue is introduced in a new commit, it appears as an additional finding marked with a ⭐️ **New** label. * All findings are visible directly in the pull request code review. * Qodo also posts a "Code review by qodo was updated up to the latest commit" message in the pull request each time it updates the comment. To disable this, see [Persistent comment notification](#persistent-comment-notification) below. * Qodo keeps a **Previous reviews** section in the comment, showing the history of past review runs. See [Previous reviews](/code-review/comment-anatomy#previous-reviews-formerly-audit-trail) for how to read it. Qodo bot comment showing the persistent comment notification, "Code review by Qodo was updated up to the latest commit" To enable this behavior, push-trigger handling must be enabled in your repository configuration. You can enable it from the Qodo portal or using the `.pr_agent.toml` file. ## Configure persistent review comments in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **Code review**. 3. Configure **Review every push**. 4. Navigate to **Configurations** > **Display** > **Notification comments**. 5. Configure **Persistent comment notification**. These settings apply to all connected repositories unless overridden at the repository level. For more information, see [Configure Qodo using the portal](/configuration/portal-configuration). ## Configure persistent review comments in .pr\_agent.toml ### Review every push Add the following inside your relevant git provider section in `.pr_agent.toml`. Do not include this in multiple provider sections. Example (GitLab): ```toml theme={null} [gitlab] handle_push_trigger = true push_commands = [ "/agentic_review" ] ``` | Setting | Default | Behavior | | - | - | - | | `handle_push_trigger` | `false` | Re-runs configured commands when new commits are pushed to the pull request | | `push_commands` | `["/agentic_review"]` | Commands run on each push, once `handle_push_trigger` is `true` | The portal's **Review every push** toggle also sets `review_agent.enable_incremental_review`, which makes the re-run focus only on changes since the last review instead of reviewing the whole pull request again: ```toml theme={null} [review_agent] enable_incremental_review = true ``` | Value | Behavior | | - | - | | `true` (default) | Follow-up reviews focus only on changes since the last review | | `false` | Every re-run reviews the full pull request again | ### Persistent comment notification Set the following in the `[review_agent]` section: ```toml theme={null} [review_agent] persistent_comment_notification = true ``` | Value | Behavior | | - | - | | `true` (default) | Posts a "Code review by qodo was updated up to the latest commit" message each time the comment is updated | | `false` | Suppresses the notification message | For more information, see [Configure using .pr\_agent.toml file](/configuration/configuration-file). ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#previous-reviews-formerly-audit-trail): How previous reviews appear in the review comment. * [Track resolved findings in pull requests](/code-review/track-resolved-findings): Show resolved findings in place, in a separate section, or not at all. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Pull request command and interaction reference Source: https://docs.qodo.ai/code-review/pr-command-and-interaction-reference Every command and interaction available to trigger or guide Qodo directly from a pull request. Qodo can be triggered and guided from a Pull Request (PR) in two ways. Enter a slash command, or interact with it directly, using plain language or the buttons and checkboxes it adds to the pull request. This page lists both, with links to the page that covers each in detail. Commands and interactions work on all supported Git providers unless a provider badge says otherwise. ## Slash commands Enter slash commands directly in a pull request comment. | Command | Use | Description | | - | - | - | | [`/agentic_review`](/code-review/use-qodo-in-prs/code-review) | Primary review workflow | Runs the main Qodo review experience, generating prioritized findings and suggested fixes. Accepts `--review_agent.issues_user_guidelines`, `--review_agent.compliance_user_guidelines`, and `--review_agent.smart_router_extra_instructions` as parameters. See [Extra instructions](/code-review/extra-instructions). | | [`/agentic_describe`](/code-review/pr-summary) | PR summarization | Generates a structured summary of the pull request. | | [`/ask`](/code-review/chat-with-qodo-in-your-pull-requests) | PR-specific questions | Answers questions about the pull request and its code changes. | | [`/generate_labels`](/code-review/generate-pr-labels)
GitHub GitLab Gerrit | PR categorization | Suggests labels based on code changes (hashtags on Gerrit). | | [`/checks`](/code-review/enable-ci-failure-feedback)
GitHub | CI troubleshooting | Analyzes CI failures and surfaces useful debugging context. | ## Natural language and native actions For the following actions, no command is needed. Qodo responds to plain language, or you use a button or checkbox it adds to the pull request. | Interaction | Description | Learn more | | - | - | - | | Mentioning `@qodo` (or `qodo`, `/qodo`) | Starts a conversation. Ask Qodo to explain a finding, discuss a suggestion, or push back, in natural language. | [Chat with Qodo](/code-review/chat-with-qodo-in-your-pull-requests) | | Asking a question without mentioning Qodo
GitHub GitLab | Qodo detects a question written in a PR comment and answers it, without requiring `@qodo` or `/ask`. | [Auto-detected questions](/code-review/auto-detected-questions) | | Telling Qodo a finding doesn't apply | Qodo dismisses the finding as False positive, Rejected, Deferred, or Intentional, and updates the summary comment, review thread, and inline comment accordingly. | [Chat with Qodo](/code-review/chat-with-qodo-in-your-pull-requests#what-you-can-ask-qodo-to-do) | | Telling Qodo a rule or relationship is wrong | In a rule violation or cross-repo conflict thread, Qodo replies with a link to that rule or relationship in the Qodo portal, where you can update, disable, or delete it. | [Chat with Qodo](/code-review/chat-with-qodo-in-your-pull-requests#fix-the-source-of-a-finding-in-the-portal) | | Asking Qodo to fix a finding | Triggers the Remediation agent, which opens a pull request with the proposed fix. | [Remediate findings in pull requests](/code-review/remediate-findings-in-prs) | | Selecting the author self-review checkbox
GitHub | Confirms the author reviewed the findings. Can be configured to add Qodo as a reviewer, allowing the PR to be merged. | [Enable author self-review in pull requests](/code-review/self-review) | | Clicking **Apply Suggestion** or **Add suggestion to batch**
GitHub GitLab | Commits a Qodo-generated code fix directly to the pull request, using the Git provider's native suggestion workflow. | [Commit code fixes directly in the pull request](/code-review/commitable-code-suggestions) | ## Related resources * [Chat with Qodo in pull requests](/code-review/chat-with-qodo-in-your-pull-requests): Ask questions and request changes without leaving the pull request. * [Trigger a code review](/code-review/use-qodo-in-prs): Run reviews automatically or manually. * [TOML configuration and command reference](/configuration/configuration-and-command-reference): The settings behind these commands. # Generate a PR summary Source: https://docs.qodo.ai/code-review/pr-summary Qodo generates a structured pull request summary to help reviewers quickly understand the scope and impact of a change. Qodo reviews the full codebase, not just the diff, to generate a structured summary of the pull request (PR) that gives reviewers meaningful context before they look at a single line of code. The summary captures the intent of the change, estimates how long the review will take, surfaces high-level suggestions, and diagrams the architecture where relevant. Generated PR summary comment showing tags, the Walkthroughs section, and File Changes grouped by category The summary includes: * **Summary, tags, and time estimate:** A brief summary of the PR's intent, followed by tags (Bug fix, Tests, Enhancement, Documentation, or Configuration changes) and a time estimate, so reviewers can prioritize before opening a single file. * **Walkthroughs:** A Description, Diagram, and High-Level Assessment that break down what changed, how, and why. * **File Changes:** Modified files grouped by category, for a quick view of the change surface. Code review file changes overview showing modified file paths, change types, and lines added or removed For more information, see [Comment anatomy](/code-review/comment-anatomy#pull-request-summary). ## Generate a PR summary manually Comment on the pull request: `/agentic_describe` Qodo acknowledges the request and posts the generated summary directly in the pull request. ## Generate a PR summary automatically Qodo generates a summary automatically when a pull request is opened or updated. This is the default behavior. If you want to change the default behavior, use one of the following methods. ### Configure automatic PR summaries in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **PR summary**. 3. Set **PR summary trigger** to **Manual only** (generated using `/agentic_describe`) or **Published PRs** (generated automatically when a PR is published, default). For more information, see [Configure Qodo using the portal](/configuration/workflow#pr-summary). ### Disable automatic PR summaries in .pr\_agent.toml Automatic PR summaries run when `/agentic_describe` is included in `pr_commands`. Remove it from the list to disable automatic summaries and rely on manual requests only. ```toml theme={null} [github_app] pr_commands = ["/agentic_review"] ``` `pr_commands` is set per Git provider section, or in `[config]` as a fallback for providers that don't define their own. For more information, see [Configuration and command reference](/configuration/configuration-and-command-reference#review-workflow-options). ## Set the location of the summary in the pull request By default, Qodo posts the PR summary as a standalone comment and does not modify the pull request description. To publish it in the pull request description instead, or let Qodo choose dynamically, see [Comment location](/code-review/comment-location). ## Publish the review time estimate as a native label or tag
GitHub GitLab Azure DevOps
As pull request volume grows, seeing the review effort directly in your Git provider's pull request list makes it easier to compare and triage which reviews to tackle first, without opening each one. GitHub pull request list showing review time estimate labels such as "Less than 10 minutes" and "10-20 Minutes" next to each pull request title ### Configure the review time estimate label in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **PR summary**. 3. Enable **Publish review time estimate label**. Qodo then applies the review time estimate as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), in addition to the estimate already displayed inside the summary. It's visible on the pull request and in the pull request list (for example, "10-20 Minutes"), without opening the summary. Disabled by default. ### Configure the review time estimate label in .pr\_agent.toml ```toml theme={null} [qodo_describe_agent] publish_review_time_estimate_labels = true ``` Default: `false`. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#pull-request-summary): The parts of the PR summary and how to read them. * [Determine where Qodo posts the PR summary](/code-review/comment-location): Post the summary as a comment or in the pull request description. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Reduce review noise on pull requests Source: https://docs.qodo.ai/code-review/reduce-review-noise Use Display settings to keep High-severity findings visible while presenting lower-severity findings more compactly. Display settings control how prominently Qodo surfaces findings. In pull requests with many findings, **High**-severity findings stay visible everywhere while lower-severity findings appear more compactly. High, Medium, and Low are the default severity labels, renamed from the portal using the **Severity terminology** setting. For more information, see [Configure Qodo using the portal](/configuration/display#groups). ## Configure a low-noise review ### Configure a low-noise review in the Qodo portal (Recommended) This is a recommended low-noise setup for teams that get a high volume of findings and want to focus on what matters most. Configure these settings in the Qodo portal: 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Display**. 3. Under **Overflow**, set **Findings visible per group** so High shows **All** and Medium and Low collapse to **1**, keeping only the top severity tier fully surfaced. 4. Turn on **Advanced comment routing overrides**. 5. In the routing matrix, set each severity tier's destination: | Severity | Destination | | - | - | | High | Both | | Medium | Summary | | Low | Drop | 6. Disable **Show images and animations**, under **Notification comments** on the **Display** tab, to hide Qodo's loading and empty-state illustrations. 7. Use **Finding content sections**, on the **Display** tab, to collapse or hide the parts you don't need to see in every finding. 8. Under **Comment parts**, on the **Display** tab, disable **Show context**, **Show tip of the day**, **Show previous reviews**, **Show comment footer**, and **Divider lines** to further declutter the comment. With this setup: * **High**-severity findings appear inline and in the summary. * **Medium**-severity findings stay in the summary. * **Low**-severity findings are hidden. * The loading and empty-state illustrations are hidden. * Each finding shows only the parts you keep expanded. * The comment drops its context section, tip of the day, previous review results, footer, and dividers, leaving only the findings themselves. For more information, see [Control review verbosity](/code-review/review-verbosity) for the full list of routing settings, [Control findings visibility](/code-review/findings-visibility) for Show images and animations and Finding content sections, and [Configure Qodo using the portal](/configuration/display#comment-parts) for the Comment parts settings. See also [Configure Qodo using the portal](/configuration/display#notification-comments) for the Notification comments settings. For the equivalent setup using `.pr_agent.toml` instead of the portal, see [Shape the review experience using the .pr\_agent.toml file](/code-review/shape-the-review-experience-lean-vs-verbose). ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Shape the review experience using the .pr\_agent.toml file](/code-review/shape-the-review-experience-lean-vs-verbose): The TOML equivalent of this setup. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Prioritize findings using Relevance Source: https://docs.qodo.ai/code-review/relevance Relevance shows how likely a finding is to matter, based on how your team has handled similar findings in past pull requests.
Beta GitHub GitLab
The **Relevance** section highlights related pull requests with similar findings from past reviews. This provides historical context by linking to previous pull requests where a similar issue was discussed, accepted, or rejected, so you can judge whether a finding is worth acting on without digging through history yourself. Code review finding relevance section showing similar findings from past pull requests ## How relevance is classified Each finding gets a relevance classification based on how similar findings were handled in past pull requests: * ⭐⭐⭐ **High**: Similar findings were typically accepted or fixed. * ⭐⭐ **Medium**: Mixed or inconclusive history. * ⭐ **Low**: Similar findings were typically ignored. ## What's in an entry Each Relevance entry includes: * A relevance classification (High, Medium, or Low) * A brief explanation of the historical pattern * Links to relevant past pull requests * An indicator that the insight was generated from similar findings ## How relevance is calculated Relevance is powered by [PR history indexing](/core-concepts/pr-history), Qodo's mechanism for analyzing your team's pull request activity. This isn't a one-time score: as your team merges new pull requests and makes new review decisions, Qodo keeps learning, so relevance classifications stay aligned with how your standards evolve rather than reflecting a stale snapshot. ## Get started To view Relevance on a finding: Ensure your repository is integrated with Qodo (GitHub or GitLab). Open a pull request reviewed by Qodo. Expand an issue finding to view the Relevance section, which includes links and context from similar past pull requests. No additional configuration is required during the beta phase. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Understanding PR history indexing](/core-concepts/pr-history): How Qodo builds the history behind Relevance. * [Dismiss a code review finding](/code-review/dismiss-a-finding): Close a finding without fixing it and record why. * [Rule Miner or Relevance isn't producing results](/code-review/troubleshooting/rule-miner-or-relevance-not-producing-results): What to check when Relevance doesn't appear. # Remediate findings in pull requests Source: https://docs.qodo.ai/code-review/remediate-findings-in-prs Fix code review findings directly in your PRs using the Conversational Chat or using the automated Remediation Agent. Research Preview **Research Preview**: The Remediate findings feature is set as Research Preview and is under active development. Functionality and results may evolve as we continue to improve the feature. Review and validate outputs before use, and avoid using these features in production or business-critical workflows. High, Medium, and Low are the default severity labels, renamed from the portal using the **Severity terminology** setting. For more information, see [Configure Qodo using the portal](/configuration/display#groups). Identifying an issue is only the first step. Resolving review findings often requires developers to switch context, implement changes, validate the fix, and update the pull request. As findings accumulate, these additional steps can slow down reviews and delay merges. ## Choose the remediation method that best meets your needs Qodo provides the following methods to remediate findings identified during code review: | Method | Best for | | - | - | | Fix within chat | Guided remediation where you intentionally select which fixes to apply, rather than relying on broad or automated changes. | | Automatically remediate findings at scale | Qodo’s remediation agent runs on your pull requests and automatically applies fixes and creates a dedicated remediation pull request. | ## Fix with chat Use the chat to remediate specific findings through a conversational workflow. This option is best for targeted fixes, smaller changes, or when you want more control over the remediation process. Example: "Qodo, fix the null pointer issue in this PR." ### Configure Fix with chat in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow**. 3. Verify that **Chat with Qodo** is enabled. This feature is enabled by default. See [Chat with Qodo in pull requests](/code-review/chat-with-qodo-in-your-pull-requests). 4. Navigate to **Configurations** > **Remediation** and click the **Remediation agent** toggle. 5. Set the remediation behavior: a. To automatically generate fixes for review findings, click the **Auto fix** toggle. b. Select the level of severity level at or above for the findings will be fixed. * High: Default * Medium * Low 6. Set the pull request behavior, for remediations. a. To open a dedicated pull request for the fix, click **Open a fix PR** toggle. When disabled, fixes are pushed directly to the source branch. b. To automatically close the fix pull request after the finding is resolved, click the **Close fix PR when done** toggle. You can reopen the pull request at any time before merge. ### Fix findings through chat 1. Start a conversation by mentioning `@qodo`, `qodo`, or `/qodo` at the beginning of a PR comment. 2. Ask Qodo to fix the issue using natural language. 3. Qodo views the comment and adds . 4. Qodo opens a PR with the fix and produces a final report and closes the PR. Qodo fix in chat conversation A new pull request containing the proposed fix is created for your review. ## Automatically remediate findings at scale Use the Remediation Agent to automatically remediate findings at scale. You can remediate selected findings or all findings that match your configured severity threshold. The agent creates a new branch from the pull request under review, applies the fixes, and opens a separate remediation pull request containing the proposed changes. Example: "Qodo, fix all high-severity findings in this PR." ### Configure the remediation agent in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Remediation**. 3. Scroll down and select the **Remediation agent** toggle. 4. Under **Auto-fix severity**, select the highest severity level the Remediation agent should remediate: * **High** * **Medium** * **Low** Severity levels are inclusive. Selecting a level applies remediation to that level and all higher severities. 5. \[Optional] Configure pull request behavior for fixes. 1. For the **Open a fix PR** option. * Enable to deliver fixes in a separate pull request. * Disable to apply fixes directly to the current branch. 2. For the **Close fix PR when done** option. Enable to automatically close the fix pull request once all fixes are applied. ### Configure the remediation agent in .pr\_agent.toml The **Remediation agent** toggle sets `chat_agent.enable_fixer_agent`: ```toml theme={null} [chat_agent] enable_fixer_agent = true ``` Also set `fixer_agent.enable`. The portal sets this automatically; when configuring `.pr_agent.toml` directly, set it explicitly as well, or the remediation agent won't run: ```toml theme={null} [fixer_agent] enable = true ``` The **Auto fix** toggle sets `fixer_agent.enable_auto_fix`: ```toml theme={null} [fixer_agent] enable_auto_fix = true ``` The **Auto-fix severity** setting sets `fixer_agent.action_level_threshold`: ```toml theme={null} [fixer_agent] action_level_threshold = 3 ``` | Value | Behavior | | - | - | | `3` (default) | Fixes High findings only | | `2` | Fixes High and Medium findings | | `1` | Fixes all findings, including Low | The **Open a fix PR** toggle sets `fixer_agent.open_new_pr`: ```toml theme={null} [fixer_agent] open_new_pr = true ``` | Value | Behavior | | - | - | | `true` (default) | Delivers fixes in a separate pull request | | `false` | Pushes fixes directly to the current branch | The **Close fix PR when done** toggle sets `fixer_agent.close_fix_pr`: ```toml theme={null} [fixer_agent] close_fix_pr = true ``` | Value | Behavior | | - | - | | `true` (default) | Closes the fix pull request once the fixing loop concludes | | `false` | Leaves the fix pull request open | ## How findings are remediated When remediation is triggered for a pull request: 1. Qodo creates a child branch from the pull request branch, applies the fix, and opens a separate remediation pull request. 2. The Remediation Agent applies fixes for the selected findings. 3. A remediation pull request is opened with the proposed changes. 4. You can review the generated commits and merge the remediation pull request when ready. Remediation agent PR fixed ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Chat with Qodo in pull requests](/code-review/chat-with-qodo-in-your-pull-requests): Ask questions and request changes without leaving the pull request. * [Commit code fixes directly in the pull request](/code-review/commitable-code-suggestions): Apply suggested fixes with one click. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Control review verbosity in pull requests Source: https://docs.qodo.ai/code-review/review-verbosity Verbosity controls where Qodo's findings are surfaced on your pull requests: route each severity tier's findings to a different location. Verbosity settings control where Qodo's findings appear on your pull requests: route each severity tier (**High**, **Medium**, and **Low**, by default) to a different location. High, Medium, and Low are the default severity labels, renamed from the portal using the **Severity terminology** setting. The examples on this page use the default names; the underlying `.pr_agent.toml` keys (`action_required`, `remediation_recommended`, `informational`) don't change when you rename the labels. For more information, see [Configure Qodo using the portal](/configuration/display#groups). To control how many findings show before collapsing behind a **View** link, see **Findings visible per group** in [Configure Qodo using the portal](/configuration/display#overflow). That setting replaces the older View more control, which no longer exists in the portal. ## Route findings by severity By default, every severity tier appears in the same place. Use **Advanced comment routing overrides** to change where findings go: * Leave it off to keep every severity tier in the same default location. * Turn it on to set a different destination per severity tier, using the routing matrix. In the routing matrix, there's a row for each severity tier (High, Medium, and Low by default). Select one destination per row: * **Inline**: Findings appear directly on the relevant lines of code. * **Summary**: Findings appear in the summary comment. * **Both**: Findings appear both inline and in the summary comment. * **Drop**: Findings are not shown. ## Configure review verbosity in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Display** > **Comments**. 3. Turn on **Advanced comment routing overrides**. 4. In the routing matrix, set each severity tier's destination. For more information, see [Configure Display settings in the Qodo portal](/configuration/display#comments). ## Configure review verbosity in .pr\_agent.toml ### Action level routing mode `comments_routing_preset` is unset by default (the key is commented out in `configuration.toml`). Set it explicitly to control every severity tier the same way: ```toml theme={null} [review_agent] comments_routing_preset = "custom" ``` | Value | Behavior | | - | - | | Unset (default) | Falls back to `[review_agent.comments_routing]` if it's defined, otherwise to `comments_location_policy`. See [Set feedback location](/code-review/feedback-location). | | `both` | Every severity tier appears both inline and in the summary | | `inline` | Every severity tier appears inline only | | `summary` | Every severity tier appears in the summary only | | `custom` | Set a different destination per severity tier, using the routing matrix (equivalent to the portal's Advanced comment routing overrides) | When more than one of these settings is present, Qodo resolves them in this order: `[review_agent.comments_routing]` table > `comments_routing_preset` > `comments_location_policy`. ### Per-severity routing Set a nested table under `[review_agent.comments_routing]`, with a row for each severity tier. `comments_routing_preset` doesn't need to be set to `"custom"` for this table to take effect. An unset preset with this table defined works the same way. ```toml theme={null} [review_agent.comments_routing] action_required = "both" remediation_recommended = "inline" informational = "summary" ``` | Value | Behavior | | - | - | | `inline` | Findings appear directly on the relevant lines of code | | `summary` | Findings appear in the summary comment | | `both` | Findings appear both inline and in the summary comment | | `drop` | Findings are not shown | Avoid setting `action_required` to `drop`. High-severity findings are meant to always stay visible, and while Qodo doesn't block this if set directly in `.pr_agent.toml`, it isn't a supported configuration. For a worked example that combines these settings, see [Reduce review noise on pull requests](/code-review/reduce-review-noise). ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Configure severity levels and inline comment thresholds in pull requests](/code-review/severity-thresholds): Limit inline comments to the severities that matter. * [Reduce review noise on pull requests](/code-review/reduce-review-noise): A recommended low-noise setup that combines these settings. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Enable author self-review in pull requests Source: https://docs.qodo.ai/code-review/self-review Require PR authors to acknowledge Qodo findings before merging by enabling a self-review checkbox that can optionally trigger Qodo to approve the pull request.
GitHub
Self-review acknowledgment allows PR authors to confirm they reviewed and addressed the findings generated by Qodo. When enabled, a checkbox appears in the PR that the author can use to acknowledge the review results. Teams can also configure Qodo to add itself as a reviewer after the author confirms the self-review, allowing the PR to be merged. ## Why use self-review Self-review helps teams: * Ensure authors review Qodo findings before merging * Add a lightweight confirmation step to the review workflow * Allow Qodo to become a reviewer once the author confirms the review ## Configure self-review in .pr\_agent.toml Self-review is configured in the `.pr_agent.toml` [configuration file](/configuration/configuration-file). ### Enable the self-review checkbox Add the following configuration: ```bash theme={null} [review_agent] demand_self_review = true ``` Default: `false` When enabled, a checkbox appears in the review summary comment, directly under the findings. The author can select this checkbox to confirm they reviewed the findings. ### Add Qodo as a reviewer after self-review You can configure Qodo to add itself as a reviewer when the author confirms the self-review. ```bash theme={null} [review_agent] approve_pr_on_self_review = true ``` Default: `false` When enabled: Pull request showing author self-review acknowledgment checkbox ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Trigger a code review](/code-review/use-qodo-in-prs): Run reviews automatically or manually. * [Configure Qodo using the .pr\_agent.toml file](/configuration/configuration-file): Set up and manage repository-level configuration. # Configure severity levels and inline comment thresholds in pull requests Source: https://docs.qodo.ai/code-review/severity-thresholds Set a severity threshold to control which findings appear as inline comments in pull requests, while always preserving full visibility in the summary view.
GitHub GitLab
Findings are categorized by severity. Severity is used both for prioritization and for controlling which findings appear inline in the pull request. ## Configure severity thresholds ### Configure severity thresholds in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Display** > **Comments**. 3. Set **Inline comment severity threshold**. For more information, see [Configure Display settings in the Qodo portal](/configuration/display#comments). ### Configure severity thresholds in .pr\_agent.toml ```toml theme={null} [review_agent] inline_comments_severity_threshold = 3 ``` | Threshold Value | Inline Issues Shown | Description | | - | - | - | | Unset (default) | Not set | No threshold applied, the [per-severity routing](/code-review/review-verbosity#per-severity-routing) is the sole control | | 3 | High | Blocking or critical issues | | 2 | High, Medium | Important but non-blocking issues, plus critical ones | | 1 | High, Medium, Low | All findings | * The severity threshold applies only to inline comments. * A finding below the threshold still appears in the summary, it's never dropped entirely. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Control review verbosity in pull requests](/code-review/review-verbosity): Route each severity's findings to inline comments, the summary, or both. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Shape the review experience using the .pr_agent.toml file Source: https://docs.qodo.ai/code-review/shape-the-review-experience-lean-vs-verbose The review experience is shaped by how multiple configuration settings work together. By tuning severity thresholds, display mode, limits on findings, verbosity, and ignore rules, you can make reviews feel more lean or more verbose. You shape the review experience by combining settings in your `.pr_agent.toml` file. The examples below show how to tune severity thresholds, display mode, finding limits, verbosity, and ignore rules for a leaner or more verbose review. These settings can also be configured from the Qodo portal (Recommended). For more information, see [Reduce review noise on pull requests](/code-review/reduce-review-noise) for the portal equivalent of the lean setup below, and [Configure Qodo using the portal](/configuration/portal-configuration) for the full settings reference. ## Lean review experience A lean review experience focuses on surfacing only the most critical issues and minimizing noise. It is typically achieved by combining: * Higher severity thresholds for inline comments * Fewer findings shown by default * Summary-focused feedback * More aggressive ignore rules (for PRs, files, tickets, or authors) **Example configuration:** ```bash theme={null} # Only show the most critical issues inline inline_comments_severity_threshold = 3 # Show feedback primarily in the summary comments_location_policy = "summary" # Ignore low-signal PRs and generated code [config] ignore_pr_labels = ["chore", "skip-review"] ignore_language_framework = ["protobuf"] # Display a minimal set of findings and keep most sections collapsed # ⚠️ Not supported or degraded experience on Bitbucket and Gerrit [review_agent_ux] finding_overflow_count = 1 resolved_findings_placement = "resolved_section" resolved_overflow_count = 0 expand_description = true expand_code = false expand_evidence = false expand_prompt = false # Strip the comment down to just the findings show_dividers = false show_daily_tips = false show_comment_footer = false ``` This setup highlights only issues that must be addressed before merging and keeps the review output compact. ## Verbose review experience A verbose review experience provides broader coverage and richer context. It is typically achieved by combining: * Lower severity thresholds for inline comments * More findings shown by default * Feedback shown both inline and in summary * No ignore rules **Example configuration:** ```bash theme={null} # Show multiple severity levels inline inline_comments_severity_threshold = 1 # Show feedback both inline and in summary comments_location_policy = "both" # Display more findings and expand contextual sections # ⚠️ Not supported or degraded experience on Bitbucket and Gerrit [review_agent_ux] finding_overflow_count = 5 resolved_findings_placement = "resolved_section" resolved_overflow_count = -1 expand_description = true expand_code = true expand_evidence = true expand_prompt = true ``` This setup is useful during onboarding, when working with new codebases, or when teams want deeper insight and guidance. For configuring which commands run automatically per git environment, see [Configure using .pr\_agent.toml](/configuration/configuration-file). ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Reduce review noise on pull requests](/code-review/reduce-review-noise): The portal equivalent of the lean setup. * [Configure Qodo using the .pr\_agent.toml file](/configuration/configuration-file): Set up and manage repository-level configuration. # Track resolved findings in pull requests Source: https://docs.qodo.ai/code-review/track-resolved-findings How Qodo detects that a finding was fixed, and how to show resolved findings in place, in a separate section, or not at all. As you push commits to a Pull Request (PR), Qodo checks which findings you have addressed and marks them resolved in the review comment. By default, resolved findings stay visible and struck through, which lets you see your progress toward a clean PR. You choose where they appear: in place within their group, in a separate section after the open findings, or not at all. ## How resolved findings are detected Each time Qodo reviews a new commit, it re-evaluates every finding that's still open against the changes made since the finding was raised. * Qodo looks at the full set of changes in the PR, not only the code the finding pointed to. A fix counts even when it lands somewhere else, for example in a new file or in a helper the finding did not mention. * A finding is marked resolved when the changes address the issue it describes. Findings that the changes do not address stay open. * When the full set of changes is not available, for example for a very large change set, Qodo checks the code the finding pointed to. All three statuses count as resolved findings. Each resolved finding carries one status: | Status | Description | | - | - | | ✓ Resolved | A later commit fixed the issue. | | ✗ Dismissed | The finding was dismissed without a fix and no longer needs action. | | ⊖ Outdated | The code the finding referred to was removed or rewritten. The finding no longer applies. | ## How resolved findings appear A resolved finding keeps its title, struck through, followed by its status. It drops the other labels a finding usually carries, such as finding type, category, severity, or the ⭐ New mark. This keeps resolved findings in the background and makes the open, actionable findings stand out, which helps you focus on resolving them. Where the finding also has an inline comment, Qodo marks that comment as resolved, if your Git provider supports it. ## Placement | Placement | What you see | | - | - | | Resolve in place (default) | Resolved findings stay in their original group, struck through, in one running count with the open findings. | | Move to resolved section | Resolved findings move to a Resolved findings section after the open findings. The open findings count from 1, and the resolved section counts from 1 again. The numbers in your groups reflect only the findings that still need action. | ## Resolved findings overflow With resolved findings in their own section, the overflow setting controls how much of the section is shown. | Setting | GitHub, GitLab, and Azure DevOps | Bitbucket and Gerrit | | - | - | - | | None (default) | The section is collapsed behind its title. Expand it to see every resolved finding. | Shows only the count, such as 2 of 9 resolved. | | 1, 3, or 5 | Shows that many resolved findings, with the rest behind **View resolved (N)**. | Shows that many resolved findings, followed by a count such as 7 of 15 resolved (3 displayed). | | All | Shows every resolved finding, with no collapse. | Shows every resolved finding. | Bitbucket and Gerrit do not support collapsible sections. As a result, resolved findings beyond the overflow breakpoint are not displayed. You can view them in the Qodo portal instead. ## Hide resolved findings Turn off Show resolved findings to leave resolved findings out of the review comment entirely, regardless of placement. Open findings count from 1. ## Configure resolved findings ### Configure resolved findings in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Display** > **Resolved findings**. 3. Choose the options: * **Show resolved findings**: Whether resolved findings appear in the review comment. * **Placement**: Resolve in place, or Move to resolved section. * **Resolved findings overflow**: How much of the resolved section is shown. Applies only when Placement is set to Move to resolved section. 4. Click **Save**. The **Live preview** shows the result for the Git provider you select. For more information, see [Configure Display settings in the Qodo portal](/configuration/display#resolved-findings). ### Configure resolved findings in .pr\_agent.toml ```toml theme={null} [review_agent_ux] show_resolved_findings = true resolved_findings_placement = "resolved_section" resolved_overflow_count = 0 ``` | Key | Value | Behavior | | - | - | - | | `show_resolved_findings` | `true` (default) | Shows resolved findings in the review comment | | | `false` | Leaves resolved findings out of the review comment | | `resolved_findings_placement` | `"in_place"` (default) | Keeps resolved findings struck through in their original group | | | `"resolved_section"` | Moves resolved findings to a separate section after the open findings | | `resolved_overflow_count` | `0` (default) | None. The resolved section is collapsed behind its title | | | `1`, `3`, `5` | Number of resolved findings shown before the rest are hidden | | | `-1` | All. Every resolved finding is shown | `resolved_overflow_count` applies only when `resolved_findings_placement` is `"resolved_section"`. For more information, see [Configure Qodo using the .pr\_agent.toml file](/configuration/configuration-file). ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Control findings visibility and expansion in pull requests](/code-review/findings-visibility): Set how many findings show before the rest collapse. * [Enable persistent review comments](/code-review/persistent-review-comments): Keep one review comment up to date across pushes. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Troubleshooting code review Source: https://docs.qodo.ai/code-review/troubleshooting Guides for resolving issues with Qodo Code Review. Use this guide if Qodo is not posting review comments on your pull requests. Use this guide if Rule Miner isn't generating rules, or Relevance isn't appearing on your pull requests. For additional help, please [contact support.](mailto:support@qodo.ai) # Review comments not appearing on pull requests Source: https://docs.qodo.ai/code-review/troubleshooting/review-comments-not-appearing Use this guide if Qodo is not posting review comments on your pull requests. If Qodo is not posting review comments on your pull requests, this guide walks you through the most common causes. Work through the verification steps to rule out each potential cause, or use the table below to jump directly to your symptom. | Symptom | Start here | | :- | :- | | No webhook deliveries in your Git provider log | [Verification step 1](#verification-step-1-confirm-the-webhook-is-reaching-qodo): Wrong endpoint URL or event types not configured | | `403 Forbidden` or `401 Unauthorized` in the webhook log | [Verification step 1](#verification-step-1-confirm-the-webhook-is-reaching-qodo): Webhook secret mismatch or missing | | Webhook delivers successfully but no review comment appears | [Verification step 2](#verification-step-2-confirm-the-user-is-licensed): User may not have a paid seat or a linked Git account | | Qodo reviews some repositories but not others | [Verification step 4](#verification-step-4-confirm-the-integration-has-access-to-the-repository): Integration does not have access to the repository | | Reviews were working before but have stopped | [Verification step 3](#verification-step-3-confirm-the-integration-has-the-required-permissions): Permissions may have changed | | Bot-created or draft PRs are skipped | [Verification step 5](#verification-step-5-additional-reasons-reviews-may-be-skipped): Default behavior. Can be disabled in configuration | ## Verification steps **Single-tenant and multi-tenant:** Follow verification steps 1–5. You do not have access to application logs. If you cannot identify the cause, contact [Qodo Support](mailto:support@qodo.ai) with the PR URL and timestamp. **On-premises:** Follow verification steps 1–5, then see [Check your logs](#check-your-logs) for additional diagnostics. ### Verification step 1: Confirm the webhook is reaching Qodo If your Git provider is not sending webhook events, Qodo will not process the PR. Check your webhook delivery logs: * **GitHub**: [Viewing webhook deliveries](https://docs.github.com/en/webhooks/testing-and-troubleshooting-webhooks/viewing-webhook-deliveries). Qodo uses a GitHub App. Navigate to your GitHub App settings to find **Recent Deliveries**. * **GitLab**: [Webhook logs](https://docs.gitlab.com/user/project/integrations/webhooks/#webhook-logs). * **Bitbucket**: Qodo uses a Bitbucket Connect App, which does not provide a native webhook delivery log. If you suspect webhooks are not being sent, [contact Qodo Support](https://www.qodo.ai/contact/). * **Azure DevOps**: [Troubleshoot service hooks](https://learn.microsoft.com/en-us/azure/devops/service-hooks/troubleshoot). **Interpreting the response:** | Response | Meaning | | :- | :- | | `200 OK` or `202 Accepted` | Webhook received. Continue to Verification step 2. | | `403 Forbidden` | Webhook secret mismatch. | | `401 Unauthorized` | Webhook secret missing, mismatched, or could not be retrieved (GitLab and Azure DevOps). Authentication failure (other providers). | | No deliveries listed | Wrong endpoint URL or event types not configured. | If no deliveries are listed, confirm the required event types are enabled: | Event | GitHub | GitLab | Bitbucket | Azure DevOps | | :- | :- | :- | :- | :- | | PR opened or updated | Pull requests | Merge request events | Pull request | Pull request created or updated | | Comments or commands | Issue comments | Comments | Pull request comment created | Pull request commented on | | Push to PR branch | Push | Push events | Repository push | Code pushed | If you see a `403` (GitHub or Bitbucket) or `401` (GitLab or Azure DevOps), verify that a webhook secret is configured and matches your Qodo deployment: * **GitHub**: GitHub App settings → Webhook secret * **GitLab**: Webhook settings → Secret token * **Bitbucket Server**: Webhook settings → Secret * **Azure DevOps**: Service hook subscription settings → Webhook secret ### Verification step 2: Confirm the user is licensed Qodo silently skips reviews when either of the following conditions is not met: * The user must have a paid seat, either as part of a paid team or with an individual license. * The user must have their Git Cloud account linked in the Qodo portal. Supported providers and plans: GitHub, Bitbucket, and GitLab Cloud on the Teams plan. Enterprise customers should confirm their Git organization ID has been registered with Qodo. Log in to the [Qodo portal](https://app.qodo.ai/signin) and confirm: 1. Your organization has an active subscription. 2. The PR author is a member of the licensed organization with their Git Cloud account linked. 3. You are not at or over your monthly review limit. If you are, reviews will be skipped until the next billing cycle. ### Verification step 3: Confirm the integration has the required permissions Qodo requires write access to post comments. Go to your GitHub App settings → **Permissions & events**. Confirm: * Pull requests: Read & Write * Issues: Read & Write * Contents: Read * Checks: Read & Write (if check run annotations are enabled) If you recently updated permissions, your organization may need to re-approve them. Check for a pending approval banner under your organization's **Settings → GitHub Apps**. Confirm the access token or PAT used by Qodo has the following scopes: * `api` or `read_api` * `write_repository` * `write_merge_requests` (if available on your GitLab version) Confirm the bearer token used by Qodo has: * Read and write access to repositories * Read and write access to pull requests Confirm the PAT used by Qodo has: * Code: Read & Write * Pull Request Threads: Read & Write ### Verification step 4: Confirm the integration has access to the repository Go to your organization's **Settings → GitHub Apps → Qodo → Configure**. Under **Repository access**, confirm the repository is listed, or **All repositories** is selected. Private repositories require explicit access. Confirm the webhook is configured at the correct level: project versus group. If using a group webhook, verify it is set to propagate to subgroups and projects. Webhooks on Bitbucket are configured per repository. Confirm the webhook is set up under the correct repository's settings, not just at the workspace level. Service hook subscriptions are project-scoped. Confirm the subscription is configured for the correct project, and that any event filters do not exclude the repository. ### Verification step 5: Additional reasons reviews may be skipped **PR opened by a bot** Qodo ignores PRs from bot accounts by default (`ignore_bot_pr = true`) across all supported providers. These PRs are skipped silently. A PR is classified as bot-authored when any of the following is true: * The Git platform marks the author as a bot (for example, a GitHub App account such as `my-agent[bot]`). * The author's username matches a bot-like heuristic, including fragments such as `-bot`, `[bot]`, `jenkins`, `service`, `cicd`, or `assistant`, as well as exact usernames such as `claude`, `augment`, and `codex`. Human-owned service accounts such as `deploy-jenkins-ci` may also match. * The PR description contains an automation phrase such as `This PR was created automatically by`. To disable, add `ignore_bot_pr = false` to the provider-specific section of your `.pr_agent.toml` (for example, `[github_app]` for GitHub). For more information about the correct section per provider and file placement, see [Reviews on PRs created by bots and AI agents](/code-review/ignore-content-from-analysis#ignore-prs-opened-by-bots-and-ai-agents). **Draft pull requests** Qodo skips draft PRs on GitHub, GitLab, and Azure DevOps by default. Set the **Code review trigger** to **Draft and published PRs** in the [Qodo portal](/configuration/workflow#code-review), set `feedback_on_draft_pr = true` in the relevant config section (`[github_app]` for GitHub, `[gitlab]` for GitLab, `[azure_devops_server]` for Azure DevOps), or mark the PR as ready for review. **GitHub only: API rate limit** GitHub enforces hourly API rate limits. If Qodo has exhausted its rate limit, it will skip processing until the limit resets, typically within an hour. Try opening a new PR or re-triggering a review after an hour. ## Check your logs On-premises deployments only. Single-tenant and multi-tenant customers should contact [Qodo Support](mailto:support@qodo.ai). Qodo logs are structured JSON. Filter by the PR URL, which is logged as the `api_url` field on every event: ```bash theme={null} # Filter by PR URL grep '"api_url"' /path/to/qodo.log | grep 'api.github.com/repos/your-org/your-repo/pulls/123' ``` If you have access to a structured log tool such as Loki, CloudWatch, or Datadog, query by field directly: ```javascript theme={null} api_url = "https://api.github.com/repos/your-org/your-repo/pulls/123" ``` ### Additional log fields | Field | Example value | Use | | :- | :- | :- | | `api_url` | Varies by provider (see table below) | Isolate a specific PR. | | `git_org` | `your-org` | All events for an organization. | | `repo` | `your-repo` | All events for a repository. | | `sender` | `octocat` | Events triggered by a specific user. | | `request_id` | `abc123` | Trace a single webhook event end-to-end. | ### `api_url` format by provider | Provider | Format | | :- | :- | | GitHub Cloud | `https://api.github.com/repos///pulls/` | | GitHub Server | `https:///api/v3/repos///pulls/` | | GitLab Cloud | `https://gitlab.com///-/merge_requests/` | | GitLab Server | `https://///-/merge_requests/` | | Bitbucket Cloud | `https://bitbucket.org///pull-requests/` | | Bitbucket Server | `https:///projects//repos//pull-requests/` | | Azure DevOps | `https://dev.azure.com///_git//pullrequest/` | ### Log patterns Once you have the relevant log lines, look for the following: #### Not licensed or not eligible ```javascript theme={null} User {username} is not eligible to trigger auto commands for PR User {username} is not eligible to comment on PR Monthly invoke count for '{org}' is {count}, above trial max invokes of 30 ``` **Solution:** Confirm the organization has an active subscription and the user is a registered member. If the monthly limit is exceeded, upgrade your plan or contact support. #### Webhook secret or signature failure ```javascript theme={null} Request signatures didn't match! (GitHub, Bitbucket) Secret mismatch between request and settings (GitLab) Secret retrieved does not match stored PAT (Azure DevOps) ``` **Solution:** Re-sync the webhook secret between your Git provider and your Qodo configuration. #### Integration not installed on the repository ```javascript theme={null} PR not found, or PR-Agent app is not installed on the repository ``` **Solution:** Install or configure the integration to cover the repository. For more information, see [Verification step 4](#verification-step-4-confirm-the-integration-has-access-to-the-repository). #### Permission failure ```javascript theme={null} Error getting permissions ``` **Solution:** Review the required permissions for your Git provider. For more information, see [Verification step 3](#verification-step-3-confirm-the-integration-has-the-required-permissions). #### Rate limit (GitHub) ```javascript theme={null} Rate limit is too close to the limit, will not proceed ``` **Solution:** Wait for the GitHub API rate limit to reset, typically within one hour. #### Output suppressed by configuration ```javascript theme={null} Skipping publish_comment since publish_output is disabled ``` **Solution:** Set `CONFIG.PUBLISH_OUTPUT = true` in your Qodo configuration. #### Queue workers not running ```javascript theme={null} CRITICAL: No queue workers available! Webhook events will be REJECTED. ``` **Solution:** Ensure the configured number of queue workers are running and connected to the queue provider (such as Redis). ## Still not working? Contact [Qodo Support](mailto:support@qodo.ai) with the following: * The PR URL. * The date and time the PR was opened. * Your Git provider: GitHub, GitLab, Bitbucket, or Azure DevOps. * Your deployment type: single-tenant, multi-tenant, or on-premises. * Any relevant log lines if self-hosted. # Rule Miner or Relevance isn't producing results Source: https://docs.qodo.ai/code-review/troubleshooting/rule-miner-or-relevance-not-producing-results Follow these troubleshooting instructions if Rule Miner isn't generating rules, or Relevance isn't appearing on your pull requests. [Rule Miner](/governance/rule-enforcement/rule-miner) and [Relevance](/code-review/relevance) are two separate features that both depend on the same underlying engine: [PR history indexing](/core-concepts/pr-history). If a repository's history hasn't finished indexing, or indexing failed, both features have nothing to learn from and stay silent, without a visible error. Some causes below apply to only one feature, each section notes which. ## Confirm Rule Miner is enabled (Rule Miner only) Rule Miner has an organization or repository-level setting that turns it off entirely, independent of indexing status. Go to **Configurations** > **Context** > **Review standards** in the Qodo portal and confirm **Mine rules from code review history** is enabled. For more information, see [Configure Rule Miner](/governance/rule-enforcement/rule-miner#configure-rule-miner). Relevance has no separate enable or disable setting. ## Check PR history indexing status (both features) Go to the [Monitor and manage repositories](/governance/repositories/manage-repositories) page and find the repository's **PR history indexing** status: All users can see the status badge. The **Start indexing**, **Retry**, and **Update** buttons are visible only to organization admins. If you don't see these buttons, ask an organization admin to trigger indexing. | Status | What it means for Rule Miner and Relevance | | - | - | | **Not started**, **Queued**, or **Indexing** | Indexing hasn't finished yet. Neither feature has history to learn from. Wait for indexing to complete. If the status is Not started, select **Start indexing** to trigger it sooner. | | **Active**, **Active, Updating**, or **Active, Queued** | Indexing has completed at least once. If you're still not seeing results, see [Confirm you meet the minimum indexed history](#confirm-you-meet-the-minimum-indexed-history-both-features) below. | | **Active\*** | Previously indexed history is still available and usable, only the latest incremental update has repeatedly failed. Rule Miner and Relevance can still use the existing history, subject to the thresholds in [Confirm you meet the minimum indexed history](#confirm-you-meet-the-minimum-indexed-history-both-features) below. Select **Update** to retry, or contact support if it doesn't resolve on its own. | | **Failed** | The initial indexing run never completed. Neither feature has any history to learn from yet. Select **Retry**, or contact support if it doesn't resolve. | ## Confirm you meet the minimum indexed history (both features) Even with successful indexing, Rule Miner and Relevance each require a minimum amount of indexed history before they start producing results. Click the repository row to open the sidebar and check **What this unlocks** under [PR history indexing detail](/governance/repositories/manage-repositories#pr-history-indexing-detail). If a feature isn't listed there yet, the repository hasn't reached the required threshold. ## Still not working? Contact [Qodo Support](mailto:support@qodo.ai) with the following: * The repository name and Git provider. * The PR history indexing status shown for the repository. * Whether you're missing Rule Miner rules, Relevance context, or both. # Trigger a code review Source: https://docs.qodo.ai/code-review/use-qodo-in-prs Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request. Qodo works directly inside your Git provider and integrates into your existing pull request workflow. You can start using it immediately with default behavior, and customize it later as needed. ## Run a code review Qodo can review pull requests **automatically** or **manually**. Both approaches produce the same review experience and findings, and both are fully configurable. The difference is when and how the review is triggered. See the [**Configuration**](/configuration) fundamentals for details. ### Run reviews automatically Automatic is the default. Qodo runs a review as soon as a pull request is opened, reopened, or marked ready for review, without any manual trigger. Automatic reviews are controlled by the [Code review trigger](/configuration/workflow#code-review) setting in the Qodo portal, or using the `.pr_agent.toml` file, and allow Qodo to: * Run reviews when a pull request is opened, reopened, or marked ready for review * Keep review feedback in sync with the latest code changes Optionally, enable [Review every push](/configuration/workflow#code-review) to update the existing review comment on every new commit pushed to the pull request, instead of only at publish time (see [Enable persistent review comments](/code-review/persistent-review-comments)). Automatic reviews are ideal for teams that want: * Consistent review coverage * Less manual intervention * Faster feedback loops ### Run a review manually Request a review on demand at any time by adding a comment to the pull request, regardless of your **Code review trigger** setting: ```bash theme={null} /agentic_review ``` When you post the comment: * Qodo acknowledges the request with a 👀 reaction * The review is generated and posted directly in the pull request * Feedback appears based on your configuration (summary, inline, or both) Manual requests are useful when: * You want to review on demand * You're testing configuration changes * You don't want reviews to run on every pull request update To rely on manual requests only, and stop automatic reviews from running at all, set [Code review trigger](/configuration/workflow#code-review) to **Manual only** in the Qodo portal, or using the `.pr_agent.toml` file. Re-running a review does not clear findings from previous runs. Qodo automatically strikes through a finding once it's resolved or no longer relevant due to code changes, such as a fix made in a related repository. You can dismiss any other finding manually. For more information, see [Dismiss a finding](/code-review/dismiss-a-finding). ### Disable using .pr\_agent.toml Automatic reviews run when `/agentic_review` is included in `pr_commands`. Remove it from the list to disable automatic reviews and rely on manual requests only. ```toml theme={null} [github_app] pr_commands = ["/agentic_describe"] ``` `pr_commands` is set per Git provider section (`[github_app]`, `[gitlab]`, `[bitbucket_app]`, `[bitbucket_server]`, `[azure_devops_server]`), or in `[config]` as a fallback for providers that don't define their own. For more information, see [Configuration and command reference](/configuration/configuration-and-command-reference#review-workflow-options). ### What to expect while a review runs While a review runs, Qodo posts a temporary "review in progress" comment so you know it's processing the request. Review time varies depending on the size of the pull request, but typically takes a few minutes. The comment is removed once the review is posted, or updated if the run fails or is superseded by a newer run. Admins can disable this with the [In-progress comment](/configuration/display#notification-comments) setting. ## Next steps * [Anatomy of a finding](/code-review/comment-anatomy): See what a finding looks like and what each part means. * [Chat with Qodo](/code-review/chat-with-qodo-in-your-pull-requests): Ask questions or request changes directly in the review thread. * [Remediate findings](/code-review/remediate-findings-in-prs): Let Qodo generate and apply a fix. * [Pull request command and interaction reference](/code-review/pr-command-and-interaction-reference): Every command and interaction available in a pull request. # Optimize AI effort with Review effort mode Source: https://docs.qodo.ai/code-review/use-qodo-in-prs/control-review-effort Control the depth of AI code review by letting Qodo automatically match review effort to the risk of each change, or apply a fixed mode to all the reviews in the repository. Review effort mode controls the depth of AI code review. By default, it is set to **Auto**, which dynamically matches review depth to the risk of each change. You can switch to **Balanced** to apply a standard level of analysis to every review, or choose another fixed mode to apply the same level of analysis to every review in the repository. Review effort mode helps you: * Apply the optimal review mode for each code change. * Reduce review time for incremental changes where deeper analysis is not needed. * Give repository owners the flexibility to choose the appropriate review effort for each repository based on its importance. ## How Review effort mode is applied Before starting a full code review, Review effort mode performs a fast analysis of the changes. It goes beyond the size of the diff, evaluating the potential impact of the changes, including factors such as: * The type of code being modified. * The potential impact of introducing a defect. * The complexity of the change. * The level of reasoning required to identify potential issues. For example: * A large block of generated code may present a low risk of introducing defects. * A single-line change to billing logic may have a high impact if incorrect. Based on this analysis, Review effort mode determines the optimal level of AI scrutiny required for the review. ## Review effort modes Review effort mode routes each review into one of these review modes: | Mode | Description | | - | - | | **Auto** | Intelligently selects a fast, balanced, or deep review. This is the default mode. | | **Fast** | Performs a fast review for simple or low-risk changes. | | **Balanced** | Applies the standard review process used before Review effort modes were introduced. | | **Deep** | Performs a more comprehensive review using the most advanced model selection and agentic architecture. Disabled in Research Preview mode. | ### How review effort is selected When **Auto** cannot confidently determine the appropriate review depth, it prioritizes safety. Rather than selecting a lower-effort review, it routes the review to a higher review depth to ensure that potentially important changes receive sufficient analysis. ## Review effort examples Review effort mode evaluates each code change and selects the most appropriate review effort based on the potential impact of the change. The following examples show how different types of changes can be routed to different review modes. ### Documentation update A developer updates a documentation file to correct a spelling mistake. Since the change has minimal impact, Review effort mode routes the review to the Fast mode, providing a fast and cost-efficient review. ### Billing logic refactor A developer modifies billing logic that could affect financial calculations. Even if the change contains only a small number of lines, Review effort mode identifies the potential impact and routes the review to the Deep mode. Multiple review agents analyze the changes to provide deeper coverage. Instead, they are promoted to at least the Auto mode to ensure that potentially important changes receive sufficient analysis. ## Configure Review effort mode ### Configure Review effort mode in the Qodo portal (Recommended) By default, Auto is enabled with the full effort range, dynamically routing each review to Fast, Balanced, or Deep based on risk. Drag the range handle to cap the highest effort Auto may use, or move it all the way down to **Fast** to apply that level of analysis to every review in the repository. 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Workflow** > **Review effort mode**. Review effort mode 3. Drag the handle on the **Fast → Balanced → Deep** slider to set the highest review effort Auto may use for this repository. **Fast** is always included as the lower bound; the handle sets the upper bound: * Leaving the handle at **Deep** (the default) allows Auto to choose Fast, Balanced, or Deep for each review. * Moving the handle to **Balanced** restricts Auto to Fast or Balanced only. * Moving the handle to **Fast** forces every review in the repository to use Fast. 4. Click **Save changes**. ### Configure Review effort mode in .pr\_agent.toml ```toml theme={null} [review_agent] override_effort = "lite" ``` | Portal mode | `.pr_agent.toml` setting | | - | - | | Auto (default) | Leave `override_effort` unset, with `enable_smart_router = true` | | Fast | `override_effort = "lite"` | | Balanced | `override_effort = "standard"` | | Deep | `override_effort = "extended"` | ### Set a review effort range The portal's range handle corresponds to a `review_effort_range` value, with a `lower` and `upper` bound of `fast`, `balanced`, or `deep`. The lower bound is always `fast`; the upper bound is whichever effort the handle is set to. This range determines which efforts Auto may choose from — a lower cap never runs a review above the configured upper bound. | Portal range | Effective behavior | | - | - | | Fast to Deep (default) | Auto chooses Fast, Balanced, or Deep. | | Fast to Balanced | Auto chooses Fast or Balanced only. | | Fast to Fast | Every review runs at Fast. | ## Customize Auto review Use custom instructions to help Auto determine the appropriate review depth based on the changes being reviewed. 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Prompts** > **Review effort mode**. 3. Add free-text instructions to guide how Qodo reviews code for the repository. 4. Save your changes. The configured instructions are applied whenever Qodo reviews code in the selected repository, providing flexibility to optimize review effort based on each repository's needs. For more information, see [Configure extra instructions](/code-review/extra-instructions). ## Related resources * [Trigger a code review](/code-review/use-qodo-in-prs): Run reviews automatically or manually. * [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius): Triage pull requests by the risk of the change. * [Configure extra instructions](/code-review/extra-instructions): Steer what Qodo looks for during a review. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Enrich context with up-to-date dependencies Source: https://docs.qodo.ai/code-review/use-qodo-in-prs/third-party-dependencies-context See how Qodo uses web search to find the latest official documentation, specifications, and release notes to produce more accurate and up-to-date findings. During a pull request review, Qodo can search the web for up-to-date documentation, specifications, and release notes for third-party dependencies referenced in your code. Qodo uses a third-party search service to retrieve relevant sources, helping the review agent produce more accurate findings based on current information. ## How web search is used When Qodo reviews a pull request, it identifies third-party dependencies referenced in the changes and searches the web for relevant documentation, specifications, and release notes. The review agent uses this information to: * Detect usage that conflicts with the latest API or specification for a dependency. * Flag deprecated methods, removed features, or breaking changes introduced in newer versions. * Ground third-party evidence in official docs, issues, and other helpful sources available instead of the model's internal knowledge, in order to prevent hallucinations. ## Configure web search ### Configure web search in the Qodo portal (Recommended) Web search is enabled by default for new users. If you're an existing user: 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Context**. 3. Enable **Web search**. ### Configure web search in .pr\_agent.toml ```toml theme={null} [review_agent] enable_web_search_tool = true ``` Default: `false`. New workspaces get this enabled automatically by the portal; existing workspaces and hand-written `.pr_agent.toml` files fall back to this default. ## View web search references in findings When web search contributes to a finding, the **Context sources** panel in the review comment lists the external sources the agent referenced. This shows you which documentation, release notes, or other sources informed the finding. Web search results shown in a pull request finding For more information, see [Comment anatomy](/code-review/comment-anatomy#code-review-findings-overview). ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#code-review-findings-overview): The findings overview, including the Context sources panel. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # View cross-repository conflicts in your findings Source: https://docs.qodo.ai/code-review/view-cross-repo-conflicts-in-findings Learn how cross-repository conflict findings are generated by Qodo's cross-repository code review and how they flag breaking changes against related repositories.
Beta
Cross-repository conflicts are findings generated by Qodo's cross-repository code review that flag a change in a pull request that would break a related repository. ## How cross-repository conflicts are generated Cross-repository conflicts are generated by Qodo's **cross-repository code review**, which reviews pull requests in repositories that have a defined relationship with other repositories. When a pull request modifies a component covered by a relationship, such as a shared library, an API contract, or a database schema, the agent reads the related repositories and traces the impact in both directions. If a change would break a related repository, it reports a **cross-repository conflict** finding with a direct link to the affected lines in that repository. The review runs automatically on any pull request in a repository that has at least one active relationship. By default, the review compares against the **main branch** of each related repository. If your change has a matching pull request or branch in the related repository, include the related pull request URL or branch name in your pull request description or a linked ticket so the conflict is evaluated against that code. Otherwise, Qodo may flag a conflict that a related, unmerged pull request already resolves. For more information, see [Cross-repository code review](/governance/cross-repo-code-review). For how relationships are defined and how cross-repository review works in depth, see [Cross-repository code review](/governance/cross-repo-code-review). ## Configure cross-repository conflicts ### Configure cross-repository conflicts in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Set up a relationship between repositories. See [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships). 3. Navigate to **Configurations** > **Finding types**. 4. Verify that **Cross-repo impact** is enabled. ## View the cross-repository conflict in the findings Cross-repository code review adds the following finding type to the review output: 🔗 **Cross-repo conflict**: A change in the pull request would break a related repository. Qodo pull request comment showing a cross-repository conflict finding with a description and a link to the affected code in the related repository Cross-repository conflicts appear alongside other review findings: * 🐞 Bugs * 📘 Rule violations * 📎 Requirement gaps All findings are displayed in a unified review comment. Cross-repository conflicts also appear on the [Findings page](/governance/view-all-findings-in-organization) in the Qodo portal, tagged `Cross-repo`. ## Cross-repository conflict details Each cross-repository conflict finding includes: * **Description**: Explanation of the breaking change and which related repository is affected * **Code reference**: Link to the affected lines in the related repository * **Evidence**: The related repository code used to detect the conflict, including a link to each relationship behind the finding * **Agent prompt**: A suggested prompt to help resolve the issue Relationship links are listed first in Evidence, one for each related repository involved in the conflict. Each link is labeled with the two repositories, such as `web-client -> api-server`. Click a relationship link to open that relationship in the **Relationships** tab. The tab opens in Table view with the relationship's side panel open. From there, read the full relationship context, retry the analysis with custom instructions, download it as Markdown, or delete the relationship. For more information, see [View cross-repository relationships](/governance/repositories/relationships). The same link appears in the finding's Evidence section on the [Findings page](/governance/view-all-findings-in-organization#finding-details) in the Qodo portal. Access to the linked relationship follows your organization's portal permissions. If your organization restricts Software Map or Relationships access, or the relationship was deleted, the portal shows a message that the relationship could not be loaded. Contact your organization admin for access. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Cross-repository code review](/governance/cross-repo-code-review): How relationships are defined and how cross-repository review works. * [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships): Set up the relationships that cross-repository review uses. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # View requirement gaps in your findings Source: https://docs.qodo.ai/code-review/view-requirement-gaps-in-findings Learn how requirement gaps are generated by the Spec Agent and how they reflect missing or incomplete implementation against linked specifications. Research Preview **Research Preview**: The Qodo Spec Agent is set as Research Preview and is under active development. Functionality and results may evolve as we continue to improve the feature. Review and validate outputs before use, and avoid using these features in production or business-critical workflows. Requirement gaps are findings generated by the Qodo Spec Agent that indicate where a pull request does not fully implement requirements defined in its linked specification. ## How requirement gaps are generated Requirement gaps are generated by the **Qodo Spec Agent**, which analyzes pull requests that include a linked specification. The agent compares the implementation in the pull request against the requirements defined in the specification and identifies any discrepancies. When a requirement is not fully satisfied, the Spec Agent reports a **📎 Requirement gap** finding. The Spec Agent runs automatically whenever a pull request is opened or updated. ## Configure requirement gaps ### Configure requirement gaps in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Set up a documentation integration under **Integrations** > **Documentation & Design**. See [Documentation & design integrations](/integrations/documentation-and-design-integrations). 3. Navigate to **Configurations** > **Finding types**. 4. Enable the **Spec gaps** toggle. Changes are saved automatically. ### Configure requirement gaps in .pr\_agent.toml The portal's Spec gaps toggle shows as off until you interact with it. Until then, this engine default applies regardless. ```toml theme={null} [review_agent] enable_spec_agent = true ``` | Value | Behavior | | - | - | | `true` (default) | Extends requirement gap findings with Spec and PRD reviews | | `false` | Disables Spec gaps | ## View the requirement gap in the findings The Spec Agent adds the following finding type to the review output: 📎 **Requirement gap**: A requirement defined in the specification is not fully implemented in the pull request.
Requirement gap finding in a pull request
Requirement gaps appear alongside other review findings: * 🐞 Bugs * 📘 Rule violations * 📎 Requirement gaps All findings are displayed in a unified review comment. ## Requirement gap details Each requirement gap finding includes: * **Description**: Explanation of what requirement is missing or incomplete * **Code reference**: Link to the relevant lines in the pull request diff * **Evidence**: The specification section used for validation * **Agent prompt**: A suggested prompt to help resolve the issue ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Documentation & design integrations](/integrations/documentation-and-design-integrations): Connect the specs the Spec Agent checks against. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # View Skill insights in your findings Source: https://docs.qodo.ai/code-review/view-skill-related-findings See how Qodo surfaces skill-related findings in pull requests based on your repository’s `SKILL.md` file. Beta During a pull request review, Qodo evaluates changes against skills defined in your repository’s `SKILL.md` file and surfaces findings when relevant instructions are not followed. Skills are reusable, agent-agnostic instruction sets that extend what your AI coding agent can do. Each skill is a plain-text file that describes how to complete a specific engineering task, such as enforcing standards, guiding review behavior, or applying domain-specific practices. Skills follow the open Agent Skills standard and are portable across compatible agents. ## How Skill insights are detected When Qodo reviews a pull request, it identifies skills relevant to the changes and applies the instructions defined in those skills. If a skill includes constraints, expectations, or review guidance, Qodo evaluates whether the changes comply and surfaces a finding when a mismatch is detected. Not every skill affects code review. Skills intended only for code generation or workflow automation may not be used during pull request review. ## Configure Skill insights ### Configure Skill insights in your repository Add a `SKILL.md` file to one of these repository directories: `.qodo/skills`, `.claude/skills`, `.cursor/skills`, `.agents/skills`, or `skills`. Qodo checks them in that order and uses the first match. This file defines the skills Qodo uses during pull request reviews. ## Understand Skill insights in your findings When Qodo surfaces a finding, it indicates that the code does not align with instructions defined in a repository skill. Skill insights are displayed within findings in the pull request as supporting context that explains why a finding was raised. They appear as a Skill insight label inside the finding, alongside other metadata such as severity or category. Skill insights in a pull request finding Each insight may include a reference to the skill that influenced it. This provides additional context and helps you understand the reasoning behind the finding. Skill insights help you understand: * Why the finding was raised * Which skill is relevant * The context behind the feedback * How it relates to your repository practices Selecting the skill opens it in the Qodo portal where you can review the full definition. ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Manage skills across repositories](/governance/manage-skills-across-repositories): View all skills used in code review across your repositories. # View UX deviations in your findings Source: https://docs.qodo.ai/code-review/view-ux-deviations-in-findings Learn how UX deviations are generated by the Design Review Agent and how they reflect visual or interaction discrepancies against linked Figma designs. Research Preview **Research Preview**: The Qodo Design Review Agent is set as Research Preview and is under active development. Functionality and results may evolve as we continue to improve the feature. Review and validate outputs before use, and avoid using these features in production or business-critical workflows. The Design Review Agent surfaces findings under the UX Deviations section in the review output. These findings highlight differences between the implementation and the linked Figma design or design system. ## How UX deviations are generated UX deviations are generated by the **Qodo Design Review Agent**, which analyzes pull requests that include a linked Figma design. The agent compares the implementation in the pull request against the designs defined in Figma and identifies any discrepancies. When a design is not fully satisfied, the Design Review Agent reports a **🎨 UX deviation** finding. The Design Review Agent runs automatically whenever a pull request is opened or updated. ## Configure UX deviations ### Configure UX deviations in the Qodo portal (Recommended) 1. Log in to the Qodo portal. 2. Set up the Figma integration under **Integrations** > **Documentation & Design**. See [Integrate Qodo with Figma](/integrations/documentation-and-design-integrations/integrate-with-figma). 3. Navigate to **Configurations** > **Finding types**. 4. Enable the **Design gaps** toggle. Changes are saved automatically. ### Configure UX deviations in .pr\_agent.toml The portal's Design gaps toggle shows as off until you interact with it. Until then, this engine default applies regardless. ```toml theme={null} [review_agent] enable_ui_agent = true ``` | Value | Behavior | | - | - | | `true` (default) | Compares Figma requirements against your front-end code | | `false` | Disables Design gaps | ## View the UX deviation in the findings The Design Review Agent adds the following finding type to the review output: * 🎨 **UX deviation**: A design element defined in Figma is not fully implemented in the pull request. UX deviations appear alongside other review findings: * 🐞 Bugs * 📘 Rule violations * 📎 Requirement gaps All findings are displayed in a unified review comment. ## UX deviation details Each UX deviation finding includes: * **Description**: Explanation of what design element is missing or inconsistent * **Code reference**: Link to the relevant lines in the pull request diff * **Evidence**: The Figma design section used for validation * **Agent prompt**: A suggested prompt to help resolve the issue ## Related resources * [Anatomy of a Qodo Code Review](/code-review/comment-anatomy): The parts of the review comment and how to read them. * [Integrate Qodo with Figma](/integrations/documentation-and-design-integrations/integrate-with-figma): Connect the designs the Design Review Agent checks against. * [Customize the code review experience](/configuration): What you can configure, and where to configure it. # Customize the code review experience Source: https://docs.qodo.ai/configuration Customize the code review experience so it matches your team’s standards, workflows, and tolerance for noise. You don’t need to configure everything to get value from Qodo. Most teams start with the defaults and selectively customize only what they need. Configuration allows you to: * Filter out noise from irrelevant pull requests * Guide Qodo’s feedback to align with your team’s practices * Maintain consistent review behavior across projects and repositories * Improve the quality, relevance, and focus of review feedback ### What can be configured? Qodo configuration allows you to control several aspects of the review experience: #### How reviews run * Which review commands are available * Whether reviews run manually or automatically * When reviews run (for example, on draft PRs, published PRs and additional commits) #### How feedback appears * Where comments appear (PR conversation summary or inline comments on file changes) * Severity thresholds for inline feedback * Control the number of surfaced findings Qodo feedback is embedded directly within the Git provider experience and integrates with the provider’s native comment system. Available display options may vary depending on the provider’s capabilities. #### What Qodo reviews * Which repositories, branches, folders, or files are included * Which pull requests should be ignored * Which tickets or labels should be excluded #### How Qodo behaves * Custom instructions for review output * Persistent review comments * Feature-level behavior (for example, suggestion tracking or CI feedback) ### Supported configuration locations Qodo settings can be defined at multiple levels, each corresponding to a different location. These settings can be configured using a `.pr_agent.toml` file or through the Qodo portal. Supported locations: * **Qodo portal** (Recommended): Managed through the Qodo portal interface. These settings apply only when no configuration is defined in the repository wiki, repository root, or organization settings repository. See [Configure Qodo using the portal](/configuration/portal-configuration). * **Repository Wiki** (`.pr_agent.toml`): Does not require committing changes to the codebase. Changes take effect immediately. See [Wiki configuration](/configuration/configuration-file#wiki-configuration). * **Repository Root** (`.pr_agent.toml`): Applies only to a specific repository. Requires committing a `.pr_agent.toml` file to the default branch. See [Repository root configuration](/configuration/configuration-file#repository-root-configuration). * **Organization settings repository** (`pr-agent-settings`): Defines defaults that apply across multiple repositories in the organization. See [Organization-level configuration](/configuration/configuration-file#organization-level-configuration). * **Project settings repository** (`pr-agent-settings`): Defines defaults that apply across multiple repositories in a project or group. See [Project or group-level configuration](/configuration/configuration-file#project-or-group-level-configuration). **Enterprise** customers can configure environment-level settings. #### Configuration precedence When settings are defined in more than one location, Qodo applies them in the following order (highest precedence first): 1. Repository Wiki (Wiki availability depends on the Git provider, as not all providers support a wiki feature). 2. Repository Root 3. Organization/ Project settings repository (`pr-agent-settings`) 4. Qodo portal (within this level, repository settings override Git organization settings, which override workspace settings) This hierarchy enables organizations to define shared defaults while still allowing repository-specific overrides when needed. Configuration precedence Configuration precedence #### FAQ Repository-level settings override both project-level and organization-level defaults. Project-level settings take precedence over organization-level settings. For repositories nested within multiple subgroups, Qodo searches only **one level up** for a `pr-agent-settings` repository. No. Settings defined in the Qodo portal have the lowest precedence and are overridden by repository, project, or organization-level configuration. Within the Qodo portal, repository settings override Git organization settings, which override workspace settings. This override applies only inside the portal: portal settings as a whole still have the lowest precedence and are overridden by repository, project, or organization-level configuration defined outside the portal. ### Get started Get detailed instructions on the configuration methods that suits your workflow: * [Configure Qodo using the portal](/configuration/portal-configuration) (Recommended) * [Configure Qodo using the .pr\_agent.toml file](/configuration/configuration-file) # Configure Agentic toolbox settings in the Qodo portal Source: https://docs.qodo.ai/configuration/agentic-toolbox Controls which users in your workspace can access the Qodo Agentic Toolbox, from the Agentic toolbox tab of the Qodo portal's Configurations page. The **Agentic toolbox** tab controls which users in your workspace can access the [Qodo Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview). Click **Save access** to apply your changes. Agentic toolbox tab of the Configurations page showing the Access setting | Setting | Description | Options | | - | - | - | | **[Who can user the codebase tool?](/agentic-toolbox/manage-access-in-qodo-portal)** | Controls which users in your workspace can access the Agentic Toolbox. | • **Everyone** (default): All users can access the Agentic Toolbox.
• **No one**: No users can access the Agentic Toolbox.
• **Only specific people**: Only the users you select can access the Agentic Toolbox. Select **Add users** to choose.
• **Everyone except specific people**: All users can access the Agentic Toolbox except the users you select. | # TOML configuration and command reference Source: https://docs.qodo.ai/configuration/configuration-and-command-reference An overview of the TOML configuration options available in Qodo v2. Qodo v2 is designed to work out of the box, with minimal setup required. Teams can start receiving useful pull request feedback immediately, while configuration options allow you to fine-tune how reviews behave and how feedback appears in your workflow. Configuration settings are defined in the repository's [`.pr_agent.toml`](/configuration/configuration-file) file and can also be applied at the organization level in the [Qodo portal](/configuration/portal-configuration). Learn more in [Customize the code review experience](/configuration). The sections below describe the available configuration settings. For the commands and actions you can use directly in a pull request, see the [Pull request command and interaction reference](/code-review/pr-command-and-interaction-reference). ## Repository configuration options Configuration is managed in the [`.pr_agent.toml`](/configuration/configuration-file) file. ### Review output and visibility | Setting | TOML section | Description | Values | | - | - | - | - | | [`comments_location_policy`](/code-review/feedback-location) | `[review_agent]` | Controls where findings are posted in the pull request. | `summary` – all findings appear in a single summary comment
`inline` – findings are posted directly on relevant lines of code
`both` – a summary comment is posted and findings are also added inline (default) | | [`inline_comments_severity_threshold`](/code-review/severity-thresholds) | `[review_agent]` | Determines which severity levels generate inline comments. | Unset (default) – no threshold applied
`3` – High
`2` – High and Medium
`1` – all findings | | [`comments_routing_preset`](/code-review/review-verbosity) | `[review_agent]` | Routes every severity tier to the same location, or enables per-tier routing using the `[review_agent.comments_routing]` table. Unset, falls back to `comments_location_policy`. | Unset (default)
`both` – every tier appears inline and in the summary
`inline` – every tier appears inline only
`summary` – every tier appears in the summary only
`custom` – set a destination per tier using `[review_agent.comments_routing]` | | [`comments_routing`](/code-review/review-verbosity) | `[review_agent.comments_routing]` | Nested table setting a destination per severity tier (`action_required`, `remediation_recommended`, `informational`). Takes precedence over `comments_routing_preset` when present. | Per tier: `inline` / `summary` / `both` / `drop` | ### PR summary | Setting | TOML section | Description | Values | | - | - | - | - | | [`publish_mode`](/code-review/comment-location) | `[qodo_describe_agent]` | Controls where the PR summary is posted. | `comment` – posts the summary as a standalone comment, separate from the pull request description (default)
`pr_description` – updates the PR body with User Description and AI Description headings
`dynamic` – posts a comment if the author already wrote a PR description, otherwise updates the PR body | | [`publish_review_time_estimate_labels`](/code-review/pr-summary#publish-the-review-time-estimate-as-a-native-label-or-tag) | `[qodo_describe_agent]` | If set to `true`, applies the review time estimate as a native pull request label or tag. | `true` / `false` (default) | ### Findings display Not supported on Bitbucket Data Center. | Setting | TOML section | Description | Values | | - | - | - | - | | [`finding_overflow_count`](/code-review/findings-visibility) | `[review_agent_ux]` | Controls how many findings are shown before the rest collapse behind "View all". | `0` – all findings collapsed
`1`, `3` (default), `5` – number of findings shown before "View all"
`-1` – all findings expanded (portal: "All") | | `use_images_and_animations` | `[review_agent_ux]` | If set to `true`, shows Qodo's loading and empty-state illustrations and animations in review comments. | `true` (default) / `false` | | [`show_context_used`](/code-review/comment-anatomy#code-review-findings-overview) | `[review_agent_ux]` | If set to `true`, shows the "Context sources" section in the code review summary comment. | `true` (default) / `false` | | [`show_persistent_review_section`](/code-review/comment-anatomy#previous-reviews-formerly-audit-trail) | `[review_agent_ux]` | If set to `true`, shows the "Previous reviews" history section in the code review summary comment. | `true` (default) / `false` | | [`show_daily_tips`](/configuration/display#comment-parts) | `[review_agent_ux]` | If set to `true`, shows the rotating "Tip of the day" section above the comment footer. | `true` (default) / `false` | | [`show_dividers`](/configuration/display#comment-parts) | `[review_agent_ux]` | If set to `true`, shows divider lines between the parts of the review comment; when `false`, parts stay separated by a single blank line. | `true` (default) / `false` | | [`show_comment_footer`](/configuration/display#comment-parts) | `[review_agent_ux]` | If set to `true`, shows the Qodo footer at the bottom of the review comment. | `true` (default) / `false` | | [`severity_terminology`](/configuration/display#groups) | `[review_agent_ux]` | The vocabulary used for the three severity tiers in the review comment. | `high_medium_low` (default) / `critical_warning_informational` / `required_recommended_optional` / `p0_p1_p2` | | [`findings_label_coloring`](/configuration/display#groups) | `[review_agent_ux]` | How group badges look in the review comment. | `simplified` (default, Qodo brand) / `color_scale` / `grayscale` | ### Resolved findings | Setting | TOML section | Description | Values | | - | - | - | - | | [`show_resolved_findings`](/code-review/track-resolved-findings) | `[review_agent_ux]` | If set to `true`, shows resolved findings (fixed, dismissed, or outdated) in the review comment. | `true` (default) / `false` | | [`resolved_findings_placement`](/code-review/track-resolved-findings#placement) | `[review_agent_ux]` | Where resolved findings appear in the review comment. | `in_place` (default) – struck through in their original group
`resolved_section` – in a separate section after the open findings. The open findings and the resolved section are numbered separately, each starting from 1. | | [`resolved_overflow_count`](/code-review/track-resolved-findings#resolved-findings-overflow) | `[review_agent_ux]` | How much of the resolved section is shown. Applies only when `resolved_findings_placement` is `resolved_section`. | `0` (default) – section collapsed behind its title
`1`, `3`, `5` – number shown before "View resolved"
`-1` – all shown | ### Expanded sections in findings Not supported on Bitbucket Data Center. | Setting | TOML section | Description | Values | | - | - | - | - | | [`expand_description`](/code-review/findings-visibility) | `[review_agent_ux]` | If set to `true`, expands the description section by default. | `true` (default) / `false` | | [`expand_code`](/code-review/findings-visibility) | `[review_agent_ux]` | If set to `true`, expands the code section by default. | `true` / `false` (default) | | [`expand_recommendation`](/code-review/findings-visibility) | `[review_agent_ux]` | If set to `true`, expands the recommendation section by default. | `true` / `false` (default) | | [`expand_evidence`](/code-review/findings-visibility) | `[review_agent_ux]` | If set to `true`, expands the evidence section by default. | `true` / `false` (default) | | [`expand_prompt`](/code-review/findings-visibility) | `[review_agent_ux]` | If set to `true`, expands the agent prompt section by default. | `true` / `false` (default) | ### Show content section titles | Setting | TOML section | Description | Values | | - | - | - | - | | [`show_subsection_names`](/code-review/findings-visibility#show-content-section-titles) | `[review_agent_ux]` | If set to `true`, shows a label above each finding part in the summary comment. Currently supported on Bitbucket and Gerrit only. | `true` / `false` (default) | ### Inline comment sections | Setting | TOML section | Description | Values | | - | - | - | - | | [`inline_render_description`](/code-review/findings-visibility#inline-comment-sections) | `[review_agent_ux]` | If set to `true`, shows the description section in the inline comment; unset, follows `render_description`. | `true` / `false` | | [`inline_render_code`](/code-review/findings-visibility#inline-comment-sections) | `[review_agent_ux]` | If set to `true`, shows the code section in the inline comment. | `true` / `false` (default) | | [`inline_render_recommendation`](/code-review/findings-visibility#inline-comment-sections) | `[review_agent_ux]` | If set to `true`, shows the recommendation section in the inline comment. | `true` / `false` (default) | | [`inline_render_evidence`](/code-review/findings-visibility#inline-comment-sections) | `[review_agent_ux]` | If set to `true`, shows the evidence section in the inline comment. | `true` / `false` (default) | | [`inline_render_prompt`](/code-review/findings-visibility#inline-comment-sections) | `[review_agent_ux]` | If set to `true`, shows the agent prompt section in the inline comment; unset, follows `render_prompt`. | `true` / `false` | | [`link_findings_to_inline_comments`](/code-review/findings-visibility#link-finding-summary-to-inline-findings) | `[review_agent_ux]` | If set to `true`, links a summary finding's title to its published inline comment. Currently supported on Bitbucket and Gerrit only. | `true` (default) / `false` | ### Review workflow options | Setting | TOML section | Description | Values | | - | - | - | - | | `pr_commands` | Git provider section (`[github_app]`, `[gitlab]`, `[bitbucket_app]`, `[bitbucket_server]`, `[azure_devops_server]`), or `[config]` as a fallback for providers that don't define their own | Commands run automatically when a PR is opened or updated. Remove a command to disable its trigger, for example remove `/agentic_review` to stop automatic code reviews. | [`/agentic_describe`](/code-review/pr-summary), [`/agentic_review`](/code-review/use-qodo-in-prs/code-review) | | `feedback_on_draft_pr` | Git provider section (`[github_app]`, `[gitlab]`, `[azure_devops_server]`) | If set to `true`, also runs `pr_commands` when a PR is opened as a draft, instead of waiting until the PR is published. | `true` / `false` (default) | | [`handle_push_trigger`](/code-review/persistent-review-comments) | Git provider section (`[github_app]`, `[gitlab]`, `[bitbucket_app]`, `[bitbucket_server]`, `[azure_devops_server]`) | If set to `true`, re-runs configured commands when new commits are pushed to the pull request. | `true` / `false` (default; `true` by default in `[azure_devops_server]`) | | [`push_commands`](/code-review/persistent-review-comments) | Git provider section (`[github_app]`, `[gitlab]`, `[bitbucket_app]`, `[bitbucket_server]`, `[azure_devops_server]`) | Commands run automatically when new commits are pushed to the pull request. Requires `handle_push_trigger = true`. | [`/agentic_review`](/code-review/use-qodo-in-prs/code-review) | | [`persistent_comment_notification`](/code-review/persistent-review-comments) | `[review_agent]` | If set to `true`, posts a "Qodo updated to latest commit" message each time the persistent review comment is updated. | `true` (default) / `false` | | [`enable_incremental_review`](/code-review/persistent-review-comments#review-every-push) | `[review_agent]` | If set to `true`, a push-triggered re-review focuses only on changes since the last review instead of the whole pull request. | `true` (default) / `false` | | `publish_in_progress_comment` | `[review_agent]` | If set to `true`, publishes a temporary "review in progress" comment while the review runs, then removes it once the review posts. | `true` (default) / `false` | | [`publish_blast_radius_labels`](/code-review/assess-risk-with-blast-radius) | `[review_agent]` | If set to `true`, applies Qodo's code change risk classification as a native pull request label. | `true` / `false` (default) | | [`demand_self_review`](/code-review/self-review) | `[review_agent]` | If set to `true`, a checkbox appears in the PR for the author to confirm they reviewed the findings. | `true` / `false` (default) | | [`approve_pr_on_self_review`](/code-review/self-review) | `[review_agent]` | If set to `true`, adds Qodo as a reviewer after the author confirms self-review, allowing the PR to be merged. | `true` / `false` (default) | | [`enable_chat_in_code_suggestions`](/code-review/auto-detected-questions) | `[pr_code_suggestions]` | If set to `true`, enables Qodo to automatically recognize and respond to questions written in PR comments. | `true` (default) / `false` | | [`enable_cross_repo_agent`](/governance/cross-repo-code-review/repository-relationships#disable-cross-repo-impact) | `[review_agent]` | If set to `true`, enables cross-repository code review. | `true` (default) / `false` | | [`enabled`](/code-review/chat-with-qodo-in-your-pull-requests#disable-chat-with-qodo) | `[chat_agent]` | If set to `true`, enables the Qodo chat agent to answer questions and run commands on pull requests. | `true` (default) / `false` | | [`enable_skills_agent`](/governance/manage-skills-across-repositories) | `[review_agent]` | If set to `true`, enables skill insights to be applied during code review. | `true` / `false` (default) | | [`enable_spec_agent`](/code-review/view-requirement-gaps-in-findings#configure-requirement-gaps-in-pr_agent-toml) | `[review_agent]` | If set to `true`, extends requirement gap findings with Spec and PRD reviews. | `true` (default) / `false` | | [`enable_ui_agent`](/code-review/view-ux-deviations-in-findings#configure-ux-deviations-in-pr_agent-toml) | `[review_agent]` | If set to `true`, compares Figma requirements against your front-end code. | `true` (default) / `false` | | [`enable_web_search_tool`](/code-review/use-qodo-in-prs/third-party-dependencies-context#configure-web-search-in-pr_agent-toml) | `[review_agent]` | If set to `true`, lets the review agent search the web for up-to-date documentation on third-party dependencies. | `true` / `false` (default) | | [`override_effort`](/code-review/use-qodo-in-prs/control-review-effort#configure-review-effort-mode-in-pr_agent-toml) | `[review_agent]` | Sets the review depth. Unset lets the router decide; any other value forces that depth directly. | Unset (default) – Auto
`lite` – Fast
`standard` – Balanced
`extended` – Deep | | [`enable_review_md`](/governance/use-review-md#set-using-pr_agent-toml) | `[review_agent]` | If set to `true`, applies the repository's `REVIEW.md` instructions during code review. | `true` / `false` (default) | ### Custom review instructions | Setting | TOML section | Description | Values | | - | - | - | - | | [`issues_user_guidelines`](/code-review/extra-instructions) | `[review_agent]` | Extra instructions for the Issue finding agent, which handles bug, security, and performance detection. | string | | [`compliance_user_guidelines`](/code-review/extra-instructions) | `[review_agent]` | Extra instructions for the Compliance agent, which handles rule checking. | string | | [`smart_router_extra_instructions`](/code-review/extra-instructions) | `[review_agent]` | Extra instructions for the review effort agent, which decides how much review depth a pull request needs. | string | ### CI feedback options GitHub | Setting | TOML section | Description | Values | | - | - | - | - | | [`enable_auto_checks_feedback`](/code-review/enable-ci-failure-feedback) | `[checks]` | If set to `true`, automatically provides feedback when a CI check fails on a pull request. | `true` / `false` (default) | | [`excluded_checks_list`](/code-review/enable-ci-failure-feedback) | `[checks]` | A list of CI checks to exclude from feedback. | `["check1", "check2"]` | | [`persistent_comment`](/code-review/enable-ci-failure-feedback) | `[checks]` | If set to `true`, updates an existing CI feedback comment instead of posting a new one for each run. | `true` (default) / `false` | | [`enable_help_text`](/code-review/enable-ci-failure-feedback) | `[checks]` | If set to `true`, displays a help message when a user comments `/checks` on a pull request. | `true` / `false` (default) | | [`final_update_message`](/code-review/enable-ci-failure-feedback) | `[checks]` | If set to `true`, posts an additional message indicating the CI feedback was updated to the latest commit. | `true` / `false` (default) | ### Ignore rules | Configuration key | TOML section | Description | Values | | - | - | - | - | | [`ignore_pr_title`](/code-review/ignore-content-from-analysis) | `[config]` | Ignores PRs with matching title patterns. | regex list | | [`ignore_pr_source_branches`](/code-review/ignore-content-from-analysis) | `[config]` | Ignores PRs from matching source branches. | regex list | | [`ignore_pr_target_branches`](/code-review/ignore-content-from-analysis) | `[config]` | Ignores PRs to matching target branches. | regex list | | [`ignore_pr_labels`](/code-review/ignore-content-from-analysis) | `[config]` | Ignores PRs with specific labels. | label list | | [`ignore_pr_authors`](/code-review/ignore-content-from-analysis) | `[config]` | Ignores PRs opened by specific users. | regex list | | [`ignore_bot_pr`](/code-review/ignore-content-from-analysis#ignore-prs-opened-by-bots-and-ai-agents) | Git provider section (`[github_app]`, `[gitlab]`, `[bitbucket_app]`, `[bitbucket_server]`, `[azure_devops_server]`, `[gerrit]`) | Ignores PRs opened by bots and AI agents. | `true` (default) / `false` | | [`ignore_repositories`](/code-review/ignore-content-from-analysis) | `[config]` | Excludes specific repositories from analysis. | regex list | | [`allow_only_specific_folders`](/code-review/ignore-content-from-analysis) | `[config]` | Limits analysis to PRs that touch specific folders. | folder list | | [`ignore_language_framework`](/code-review/ignore-content-from-analysis) | `[config]` | Excludes generated files by language/framework. | framework list | | [`ignore_ticket_labels`](/code-review/ignore-content-from-analysis) | `[config]` | Ignores linked tickets with specific labels. | label list | ### Remediation | Setting | TOML section | Description | Values | | - | - | - | - | | [`enable_fixer_agent`](/code-review/remediate-findings-in-prs) | `[chat_agent]` | If set to `true`, turns on the Remediation agent. | `true` / `false` (default) | | [`enable`](/code-review/remediate-findings-in-prs) | `[fixer_agent]` | The flag the engine checks before running `/fix`. Computed automatically from `enable_fixer_agent` for portal-managed workspaces; must be set explicitly in a hand-written `.pr_agent.toml`. | `true` / `false` (default) | | [`enable_auto_fix`](/code-review/remediate-findings-in-prs) | `[fixer_agent]` | If set to `true`, turns on Auto fix, automatically generating fixes for review findings. | `true` / `false` (default) | | [`action_level_threshold`](/code-review/remediate-findings-in-prs) | `[fixer_agent]` | Minimum severity level the Remediation agent fixes. | `3` – High only (default)
`2` – High and Medium
`1` – all findings | | [`open_new_pr`](/code-review/remediate-findings-in-prs) | `[fixer_agent]` | If set to `true`, delivers fixes in a separate pull request instead of pushing to the current branch. | `true` (default) / `false` | | [`close_fix_pr`](/code-review/remediate-findings-in-prs) | `[fixer_agent]` | If set to `true`, closes the fix pull request once the fixing loop concludes. | `true` (default) / `false` | | [`enable_commitable_suggestions`](/code-review/commitable-code-suggestions) | `[review_agent]` | If set to `true`, auto-attaches committable suggestions to eligible inline findings. | `true` / `false` (default) | ### Access control | Setting | TOML section | Description | Values | | - | - | - | - | | `invite_only_mode` | `[config]` | If set to `true`, only invited users receive Qodo's review feedback on their pull requests. Other users are silently skipped. | `true` / `false` (default) | # Configure Qodo using the .pr_agent.toml file Source: https://docs.qodo.ai/configuration/configuration-file Manage Qodo configuration as code using a .pr_agent.toml file at the repository, project, group, or organization level. It is recommended to configure your code review settings using the [Qodo portal](/configuration/portal-configuration). The configuration file enables you to customize how Qodo behaves during code reviews. Learn more about the Qodo configuration mechanisms [here.](/configuration) It controls: * Review behavior * Feedback presentation * Automation * Feature-level settings Qodo reads configuration from a file named: ```bash theme={null} .pr_agent.toml ``` The file is organized into sections (TOML tables). Each section controls a specific aspect of Qodo’s behavior during code review. When a setting is defined in multiple locations, the highest-precedence configuration takes effect. **Example configuration:** ```bash expandable theme={null} ⚠️ Select ONLY ONE section below, the one that matches your git provider. # Do not include multiple provider sections in the same configuration file. # GitHub App [github_app] pr_commands = [ "/agentic_describe", "/agentic_review" ] # GitLab [gitlab] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Bitbucket Cloud [bitbucket_app] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Bitbucket Server / Data Center [bitbucket_server] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Azure DevOps [azure_devops_server] pr_commands = [ "/agentic_describe", "/agentic_review" ] [review_agent] comments_location_policy = "both" # severity threshold rank for inline comments: # 3=action_required, # 2=remediation_recommended, # 1=informational. # Only findings with rank >= threshold will be published inline inline_comments_severity_threshold = 3 # Extra prompt for usecase to be added as instruction for the agent issues_user_guidelines = "" compliance_user_guidelines = "" ``` ### Configuration using `pr_agent.toml` File-based configuration can be defined at repository, project/group, or organization levels. Each level may have platform-specific setup patterns. ### Repository level #### Repository root configuration
GitHub GitLab Bitbucket Azure DevOps
Create a local configuration file. Create a file named `.pr_agent.toml`. Add the desired configuration settings. Commit the file to the root of the default branch. The configuration takes effect for pull requests created after the change is merged. This configuration applies only to this repository. #### Wiki configuration
GitHub GitLab Bitbucket Cloud Azure DevOps
Create a wiki configuration. Enable the repository wiki. Learn more [here.](/configuration/enable-a-repository-wiki-for-configuration) Create a new wiki page named `.pr_agent.toml`. Ensure the page begins with a fenced TOML block. Add any configuration parameters you need. Save the page. Changes take effect immediately and do not require a repository commit. ### Project or group-level configuration
GitLab Bitbucket Data Center Azure DevOps
Create a project or group configuration. Create a repository named `pr-agent-settings` within: * A project (Bitbucket, Azure DevOps), or * A group or subgroup (GitLab). Add a `.pr_agent.toml` file to the root of the default branch. Define the configuration settings. This configuration applies to all repositories directly under that project or group. **GitLab:** For repositories nested in multiple subgroups, Qodo looks only one level up for a `pr-agent-settings` repository. ### Organization-level configuration #### Cloud platforms
GitHub GitLab Cloud Bitbucket Cloud
Create a global configuration file. Create a repository named `pr-agent-settings` in your organization. Add a `.pr_agent.toml` file to the root of the default branch. Define organization-wide defaults. The configuration: * Takes effect for pull requests created after the change is merged. * Applies to all repositories in the organization unless overridden by a local or wiki configuration. #### Enterprise environments
Bitbucket Data Center Azure DevOps
All repositories in the organization inherit settings from this configuration. Create organization-level configuration. Create a project named: * `PR_AGENT_SETTINGS` with project key `PR_AGENT_SETTINGS` (Bitbucket Data Center), or * `pr-agent-settings` (Azure DevOps). Inside that project, create a repository named `pr-agent-settings`. Add a `.pr_agent.toml` file to the repository. If both organization-level and project-level configurations exist, project-level settings take precedence. A repository’s local configuration always overrides both. ## Next steps * [Configuration and command reference](/configuration/configuration-and-command-reference): A full list of configuration options and which TOML section each belongs to. # Configure Context settings in the Qodo portal Source: https://docs.qodo.ai/configuration/context Controls how rules from Rule Miner and non-admin users are approved, and web search grounding, from the Context tab of the Qodo portal's Configurations page. The **Context** tab controls how rules from Rule Miner and non-admin users are approved, and web search grounding. Skill insights, cross-repo impact, spec gaps, and design gaps configuration moved to the [Finding types](/configuration/finding-types) tab. Review standards section of the Context tab, showing Auto-approve user suggestions, Mine rules from code review history, Auto-approve rule miner suggestions, and REVIEW.md instructions ## Review standards The **Review standards** settings control how rules from [Rule Miner](/governance/rule-enforcement/rule-miner) and from non-admin users are approved, and whether REVIEW\.md instructions are applied during review. | Setting | Description | Options | | - | - | - | | **Auto-approve user suggestions** | When enabled, rules added by non-admins are activated immediately without requiring admin approval. When disabled, they appear in the **Pending rules** tab for admin approval. This setting applies at the organization level only. | Enable / Disable (default) | | **Mine rules from code review history** Beta | Enables or disables Rule Miner for the organization or a specific repository. | Enable (default) / Disable | |     ↳ **Auto-approve rule miner suggestions** | When enabled, mined rules from review history are activated automatically. When disabled, rules appear in the **Pending rules** tab for review before activation. | Enable (default for organizations that started using Qodo since September 1, 2026) / Disable (default for organizations onboarded before September 1, 2026) | | **[REVIEW.md instructions](/governance/use-review-md)** Research Preview | Qodo reads a REVIEW\.md file at your repository root and applies the review instructions and guidelines it contains, a simple way to customize how Qodo reviews your code. | Enable / Disable (default) | ## Web search | Setting | Description | Options | | - | - | - | | **[Web search](/code-review/use-qodo-in-prs/third-party-dependencies-context)** | Lets the review agent search the web for the latest official documentation, specifications, and release notes to produce more accurate and up-to-date findings. | Enable (default for new users) / Disable (default for existing users) | # Configure Display settings in the Qodo portal Source: https://docs.qodo.ai/configuration/display Controls how findings and review comments are structured and presented in your pull requests, from the Display tab of the Qodo portal's Configurations page. The **Display** tab controls how findings and review comments are structured and presented in your pull requests: counters, labels, grouping, ordering, overflow behavior, resolved findings, per-finding content, comment structure, and notifications. Apply a [display mode](#display-modes) for a ready-made configuration, or configure each setting individually. Display mode selector showing Lean, Balanced, Robust, and Custom, with the active review preset's badge next to it ## Display modes New customers who onboard after display modes are introduced in Qodo 2.9 get the default value for each setting. Existing customers keep their configured settings. Display modes let you quickly configure how findings and review comments appear to your team in pull requests, without setting each Display option individually. Choose a display mode ranging from **Lean**, a low-noise review, to **Robust**, an information-rich one, or select **Custom** to configure each setting yourself. Changing any individual setting after selecting a display mode switches the selection to **Custom**. Display modes are a different layer from [review presets](/configuration/review-presets), which apply settings across every tab of the Configurations page, including the display mode above. Selecting a review preset sets this display mode for you. Changing the display mode here does not affect your review preset. | Display mode | Purpose | | - | - | | **Lean** | Lighter reviews with fewer comments and less noise. | | **Balanced** | Focused reviews that keep the standard comment structure visible. | | **Robust** | Every label and group visible, with color-scale badges. | | **Custom** | Your own combination of settings. | ## Counters | Setting | Description | Options | | - | - | - | | **Count by** | Which dimension the findings count in the comment header is broken down by. | • Severity
• Finding type (default)
• Finding category
• Relevance | | **Show finding counters** | Shows the finding count chips at the top of the review comment. | Enable (default) / Disable | | **Show zero counters** | Keeps counter chips that have no findings, showing them as zero instead of hiding them. | Enable (default) / Disable | ## Labels | Setting | Description | Options | | - | - | - | | **Displayed labels** | Chooses which labels appear on each finding in the review comment. Multi-select. | • Severity
• Finding type (default)
• Finding category (default)
• Relevance | | **Label style** | How finding type and category labels appear in review comments. | • Icon & Text (default)
• Icon only | ## Groups | Setting | Description | Options | | - | - | - | | **Group by** | How findings are grouped in the review summary comment. | • Severity (default)
• Finding type
• Finding category
• Relevance | | **Severity terminology** | The words used for the three severity tiers in the review comment. | • High, Medium, Low (default)
• Critical, Warning, Informational
• Required, Recommended, Optional
• P0, P1, P2 | | **Group badge** | How group badges look in the review comment. | • Qodo brand (default): Purple badge, no icon
• Color scale: Yellow, orange and red reflect increasing importance, no icon
• Grayscale with Emoji: Gray badge with the group's emoji | ## Ordering | Setting | Description | Options | | - | - | - | | **Order by** | How findings are ordered within each group. | • Severity
• Finding type
• Finding category
• Relevance (default) | | **Always show new findings first** | New findings from the latest review run stay at the top of each group. | Enable (default) / Disable | ## Overflow
GitHub GitLab Azure DevOps
| Setting | Description | Options | | - | - | - | | **Findings visible per group** | How many findings stay visible in each severity group before the rest collapse behind a **View** link. (No default: stays unset until you configure it.) | Set per severity tier: None, 1, 3, 5, All | | **Show empty groups** | Keeps a group in the comment when it has no findings, showing its badge with a short empty-state line. | Enable / Disable (default) | | **Include group badge in overflow** | When enabled, the group's badge collapses along with its findings. Disable to keep the badge visible even when none of the group's findings are shown. | Enable (default) / Disable | ## Resolved findings | Setting | Description | Options | | - | - | - | | **Show resolved findings** | Shows findings that were fixed, dismissed, or outdated in the review comment. Disable to leave them out entirely. | Enable (default) / Disable | | **Placement** | Where resolved findings appear in the review comment. | • Resolve in place (default): Struck through in their original group
• Move to resolved section: In a separate section after the open findings, numbered from 1 | | **Resolved findings overflow** | How much of the resolved section is shown. Applies only when Placement is Move to resolved section. On Bitbucket and Gerrit, findings that aren't shown are summarized as a count. | • None (default): Section collapsed behind its title
• 1, 3, 5: That many shown, the rest behind **View resolved**
• All: Every resolved finding shown | See [Track resolved findings](/code-review/track-resolved-findings). ## Findings
GitHub GitLab Azure DevOps
| Setting | Description | Options | | - | - | - | | **Finding content sections** | For each content section of a finding, choose whether it's hidden, shown collapsed, or shown expanded in the PR code review comment. | Each section set individually to Hidden / Collapsed / Expanded:
• **Description**: Expanded (default)
• **Code**: Collapsed (default)
• **Relevance**: Collapsed (default)
• **Evidence**: Collapsed (default)
• **Agent prompt**: Collapsed (default) | | **Show content section titles** | Shows the section titles (Description, Code, Agent Prompt) above each finding part. Currently supported on Bitbucket and Gerrit only. | Enable / Disable (default) | Inside the same Finding content card, the **Inline findings** block controls the inline comment attached to the code line, separately from the settings above: | Setting | Description | Options | | - | - | - | | **Inline findings** | For each content section of a finding, choose whether it's shown in the inline comment attached to the code line. | Each section set individually to Enable / Disable:
• **Description**: Enable (default)
• **Code**: Disable (default)
• **Relevance**: Disable (default)
• **Evidence**: Disable (default)
• **Agent prompt**: Enable (default) | ## Comments | Setting | Description | Options | | - | - | - | | **Comment type** | The comment types used to display review findings. | • Inline only
• Summary only
• Summary & Inline (default) | | **Inline comment severity threshold** | Inline comments are published only for findings at or above the selected severity. | • High (default)
• Medium
• Low | | **Advanced comment routing overrides** | Routes findings to inline or as a summary comment based on their severity grouping. (No default: stays unset until you configure it.) | Set per severity tier (High, Medium, Low): Inline / Summary / Both / Drop | | **Link finding summary to inline findings** | When a finding is shown in both the summary and inline comment, shows the summary finding's title as a link to its inline comment. Currently supported on Bitbucket and Gerrit only, disabled elsewhere. | Enable (default) / Disable | ## Comment parts | Setting | Description | Options | | - | - | - | | **Divider lines** | Shows divider lines between the parts of the review comment. When disabled, parts stay separated by a single blank line. | Enable (default) / Disable | | **Show context** | Disable to hide the "Context sources" section from the review comment. | Enable (default) / Disable | | **Show tip of the day** | A rotating Qodo tip, shown just above the footer of the review summary comment. | Enable (default) / Disable | | **[Show previous reviews](/code-review/comment-anatomy#previous-reviews-formerly-audit-trail)** | Shows the collapsible history section, with one entry per reviewed commit. | Enable (default) / Disable | | **Show comment footer** | Shows the Qodo footer at the bottom of the review comment. | Enable (default) / Disable | The toggles are listed in the order the parts appear in the review comment. ## Notification comments | Setting | Description | Options | | - | - | - | | **[Persistent comment notification](/code-review/persistent-review-comments#how-persistent-review-comments-are-updated)** | Posts a "Code review by qodo was updated up to the latest commit" message in the pull request each time Qodo updates the persistent review comment for a new commit. | Enable (default) / Disable | | **In-progress comment** | Publishes a temporary "review in progress" comment while the review runs, then removes it when the review is posted. | Enable (default) / Disable | | **Show images and animations** | Shows Qodo's illustrations and animations in the loading and empty state review comments. Disable to hide these visuals. | Enable (default) / Disable | ## Display live preview
GitHub GitLab Azure DevOps
The **Live Preview** pane shows a real-time visual of how review comments will appear in the target Git provider. Changes to display settings update the preview immediately, with no save or refresh required. The preview reflects the Git provider selected under **By Git provider**, or the Git provider of the selected Git organization or repository, and matches how findings will actually render for that provider. See [Configuration levels](/configuration/portal-configuration#configuration-levels-workspace-git-organization-and-repository). The top right of the preview includes: * A **Summary / Inline** dropdown that switches between the full review comment and the inline comment. It switches automatically when you change a setting that affects inline comments. * A light/dark mode toggle that switches the preview's color scheme. Useful for checking how the review renders on providers that default to light mode.
Live preview showing how review findings appear in the target Git provider
# Enable a repository wiki for configuration Source: https://docs.qodo.ai/configuration/enable-a-repository-wiki-for-configuration Enable a repository wiki on GitHub, GitLab, Bitbucket, or Azure DevOps to store Qodo configuration files without committing changes to the codebase. **Supported platforms:** GitHub, GitLab, Bitbucket (Not supported on Bitbucket Data Center), Azure DevOps. For the best experience with the Qodo Git interface, Qodo recommends enabling a wiki for each repository where it is installed. ### What is a wiki? Set configurations by creating a page named `.pr_agent.toml` in the repository [wiki](https://github.com/Codium-ai/pr-agent/wiki/pr_agent.toml). This approach allows configuration changes without committing new content to the repository, simply edit the wiki page and save. ### Benefits of creating a wiki * Storing your Qodo Git interface configuration file. * Tracking accepted code suggestions over time. * Improve your Qodo experience over time by creating a `auto_best_practices.md` file to capture learning and best practices automatically. ### Enable a wiki ### GitHub Go to your repository’s **main page** on GitHub. Click **Settings** in the top navigation bar. Scroll to the **Features** section. Check the box to **Enable Wikis**. Return to the repository’s main page and click the new **Wiki** tab. Click **Create the first page** and save it. The wiki must have at least one page to be fully active. ### Azure DevOps Azure DevOps Wikis are created at the **project level**, not per repository. Each repository is represented by a **wiki sub-page**. #### **Step 1: Create a project wiki** Sign in to the Azure DevOps portal (for example: `https://dev.azure.com/`). Open your project and go to **Overview** → **Wiki**. Click **Create Project Wiki**. Set the page title to `**home**`, then **Save** and **Close**. Refresh the page. You should now see a **house icon** next to the `home` page. #### **Step 2: Create repository sub-pages** Create a **sub-page for each repository** where Qodo is installed. Hover over the **three dots (⋮)** next to `home` and select **Add sub-page**. Name the page **exactly as the repository name,** then **Save** and **Close**. You can repeat this step to create **additional sub-pages** for other repositories in the project. #### **Step 3: Add Qodo configuration and data files** Under the repository sub-page, create wiki pages for Qodo configuration and related data files. To add files: Hover over the repository sub-page. Click the **three dots (⋮)**. Select **Add sub-page**. Add the required files as wiki pages. Wiki page names **cannot start with a dot (**`.`**)**. Remove the leading dot when creating files (for example, `.pr_agent.toml` → `pr_agent.toml`). ### Writing wiki content Surround the configuration content with triple-quotes ` ``` ` to allow better presentation when displayed as markdown. Qodo will remove the surrounding quotes when reading the configuration content. # Configure Finding types settings in the Qodo portal Source: https://docs.qodo.ai/configuration/finding-types Controls which specialized agents review each pull request, from the Finding types tab of the Qodo portal's Configurations page. The **Finding types** tab controls which specialized agents review each Pull Request (PR). Select which agents are used in the selected repositories' PR code reviews. Enabled agents produce findings on the PR. Disabled agents don't, but they keep collecting context in the background. Finding types tab of the Configurations page, showing Bugs and correctness, Rule enforcement, Skill insights, Cross-repo impact, Spec gaps, and Design gaps with their toggles | Setting | Description | Options | | - | - | - | | **Bugs and correctness** | The issue finding agent detects defects in the changed code. This is the core of every Qodo review, included in every preset. | Always on | | **[Rule enforcement](/governance/rule-enforcement)** | The compliance agent flags violations of your organization's standards in the changed code. Shows the number of active standards, with a link to [Review standards](/governance/review-standards). | Enable / Disable (default) | | **[Skill insights](/governance/manage-skills-across-repositories)** Research Preview | The skills agent flags issues defined by your team's imported skills in the changed code. | Enable / Disable (default) | | **[Cross-repo impact](/governance/cross-repo-code-review)** Beta | The cross-repo agent reports breakage that a code change causes in related repositories. Select a repository in the dropdown at the top of this page to see its relationship map. | Enable (default) / Disable | | **[Spec gaps](/code-review/view-requirement-gaps-in-findings)** Research Preview | The spec agent reports requirements in the linked spec that the code does not satisfy. Click **Connect specs** to set up. | Enable (default) / Disable | | **[Design gaps](/code-review/view-ux-deviations-in-findings)** Research Preview | The UI agent compares the changed front-end code against the linked Figma design. Click **Connect Figma** to set up. | Enable (default) / Disable | # Configure Qodo using the portal Source: https://docs.qodo.ai/configuration/portal-configuration The recommended way to manage organization-wide and repository-level code review configuration, including which finding types run, from the Configurations page in the Qodo portal. The **Configurations** page in the Qodo portal is organized into seven tabs: [Finding types](/configuration/finding-types), [Display](/configuration/display), [Workflow](/configuration/workflow), [Context](/configuration/context), [Remediation](/configuration/remediation), [Prompts](/configuration/prompts), and [Agentic toolbox](/configuration/agentic-toolbox). Each tab groups related settings so you can quickly find and manage what you need. To access it, select **Configurations** from the left navigation menu in the [Qodo portal](https://app.qodo.ai/). ## Configuration levels: workspace, Git organization, and repository By default, settings on this page apply to all repositories connected to Qodo. At the top left of the Configurations page, select **Workspace**, **Git organization**, or **Repository** to switch between three levels: * **Workspace** (default): Settings apply to all connected repositories. * **Git organization**: Settings apply to all repositories in the selected Git organization and override the workspace settings. * **Repository**: Settings apply only to the selected repository and override the Git organization and workspace settings. Each level uses the settings of the level above it until you change a setting at that level. For example, a repository uses its Git organization's settings until you change a setting for that repository. To configure a Git organization or repository: Select **Git organization** or **Repository**. Select the Git organization or repository from the dropdown that appears next to them. Type in the search box to filter the list. Change the settings you need, then save your changes. The Git organization level is available even when your workspace has a single Git organization. In the dropdown, an **Overridden** badge marks Git organizations and repositories that have their own settings. At the workspace level, select a Git provider icon under **By Git provider**, at the right end of the tab row, to view the Configurations page through that provider's lens: settings the provider doesn't support appear disabled, and settings that behave differently for it show a tooltip explaining the difference. Leave no icon selected to see every setting as it applies across all connected providers. When you select a Git organization or repository, the Git provider icons are hidden. The page shows settings as they apply to that Git organization's or repository's Git provider. These levels apply only within the portal and do not change where portal settings sit in the overall hierarchy. Portal settings have the lowest precedence overall: configuration defined in the repository wiki, repository root, or organization settings repository (`pr-agent-settings`) takes precedence over any portal setting. See [Customize the code review experience](/configuration#configuration-precedence). ### Overridden settings When you change a setting at the Git organization or repository level, an Overridden badge appears next to that setting. The setting also shows the value it would inherit, for example: Workspace: On. To return a setting to its inherited value, select **Reset** next to the inherited value. Some settings, such as free-text settings, show **Reset to workspace** or **Reset to Git organization** instead. A reset is added to your unsaved changes. Save your changes to apply it. Agentic Toolbox access always applies to the whole workspace. At the Git organization and repository levels, this setting shows a **Workspace setting** badge. ## Search settings across configurations Quickly find the setting you need across configuration tabs and navigate directly to it, without browsing through each tab. Navigate to the **Configurations** page in the [Qodo portal](https://app.qodo.ai/). Select **Search settings** in the top-right corner of the page, or use the keyboard shortcut: * macOS: `⌘K` * Windows and Linux: `Ctrl+K` Scroll the list of settings, or type to filter it. Each setting shows its tab name, for example: Workflow > PR summary trigger. Select a setting to navigate to it. Each setting opens with its own URL. Copy it from your browser to share a link to that setting. ## Save or reset your changes Once you have unsaved changes, a bar appears at the bottom of the Configurations page: * **Save changes**: Applies your changes. * **Discard**: Discards every unsaved change and reverts to the last saved settings. * **Review changes**: Lists each changed setting with its before and after value, and an **Undo** button for that one setting. Unsaved changes bar at the bottom of the Configurations page, showing the unsaved change count, Review changes, Discard, and Save changes * **[Revert to preset](/configuration/review-presets#customize-settings-after-applying-a-preset)**: Appears next to a setting that no longer matches the selected review preset, and in the top-right corner of the page. Selecting it next to a single setting undoes that one change. Selecting it in the top-right corner undoes every customized setting, back to the preset's values. **Undo** and **Revert to preset** undo different things: Undo returns a setting to its last saved value, while Revert to preset returns it to the active review preset's value, which can differ from what you last saved. ## Configuration tabs Controls how findings and review comments are structured and presented in your pull requests. Controls when and how Qodo runs code reviews and generates PR summaries, plus the chat agent. Controls review standards, spec and design context, cross-repository context, and web search grounding. Lets Qodo resolve review findings for you, either on demand through chat or automatically with the Remediation Agent. Add free-text instructions to guide how Qodo behaves during reviews. Controls which users in your workspace can access the Qodo Agentic Toolbox. # Configure Prompts settings in the Qodo portal Source: https://docs.qodo.ai/configuration/prompts Add free-text instructions to guide how Qodo behaves during reviews, from the Prompts tab of the Qodo portal's Configurations page. The **Prompts** tab lets you add free-text instructions to guide how Qodo behaves during reviews. Click **Save** after completing your instructions. Prompts tab of the Configurations page with text fields for the Issue finding agent, Compliance agent, and Review effort mode | Setting | Description | Options | | - | - | - | | **[Issue finding agent](/code-review/extra-instructions#configure-extra-instructions-in-the-qodo-portal-recommended)** | Custom instructions to guide issue detection and reporting behavior. | Free text (empty by default) | | **[Compliance agent](/code-review/extra-instructions#configure-extra-instructions-in-the-qodo-portal-recommended)** | Custom instructions to guide compliance checks and policy enforcement. | Free text (empty by default) | | **[Review effort mode](/code-review/extra-instructions#configure-extra-instructions-in-the-qodo-portal-recommended)** | Custom instructions that guide the review effort agent evaluation. | Free text (empty by default) | # Configure Remediation settings in the Qodo portal Source: https://docs.qodo.ai/configuration/remediation Lets Qodo resolve review findings for you, either on demand through chat or automatically with the Remediation Agent, from the Remediation tab of the Qodo portal's Configurations page. The **Remediation** tab lets Qodo resolve review findings for you, either on demand through chat or automatically with the Remediation Agent. Remediation tab of the Configurations page showing the remediation agent, auto fix, auto-fix severity, open a fix PR, close fix PR when done, and suggest committable fixes settings | Setting | Description | Options | | - | - | - | | **[Remediation agent](/code-review/remediate-findings-in-prs)** Research preview | Turns on remediation. Lets the chat agent fix findings on a pull request. | Enable / Disable (default) | |     ↳ **Auto fix** | Sub-setting of Remediation agent. Automatically generates fixes for review findings. | Enable / Disable (default) | |         ↳ **Auto-fix severity** | Sub-setting of Auto fix. Automatically fixes findings at or above the selected severity. | • **High** (default)
• **Medium**
• **Low** | | **Open a fix PR** Research preview | When on, fixes are delivered as a separate PR. When off, fixes are pushed directly to the PR's source branch. | Enable (default) / Disable | |     ↳ **Close fix PR when done** | Sub-setting of Open a fix PR. Closes the auto-fix PR once the fixing loop concludes. The branch is preserved for reopening. | Enable (default) / Disable | | **[Suggest committable fixes](/code-review/commitable-code-suggestions)** Beta

GitHub
GitLab | Enables committable code suggestions within inline comments. | Enable (default) / Disable | # Configure code review with Qodo presets Source: https://docs.qodo.ai/configuration/review-presets Apply a review preset to configure Finding types, Workflow, Context, Remediation, and Display settings out of the box. A review preset is a predefined set of code review configurations built for a specific reviewing goal. Qodo offers several, each suited to a different code review experience, covering which finding types run, how and when reviews trigger, which context sources are used, whether Qodo remediates findings automatically, and which display mode presents them in pull requests. Applying one is optional. Your team can keep its current setup, or customize settings individually. Existing organizations start on the Customization preset. Your current settings are preserved exactly as they were before review presets existed, and nothing changes until you choose to switch. New organizations choose a review preset as part of onboarding, and start from that preset's values on day one. Either way, you can switch presets at any time. Workflow tab with Review every push marked Customized and its Revert to preset button, alongside the Revert to preset button in the top-right corner of the page ## Types of review presets | Preset | Focus | Description | | - | - | - | | **Recall** | Catch what is missed | Bugs slip through. Find what other reviewers and tools miss, including the critical ones. | | **Precision** | Cut the noise | Other tools overload PRs with nits. Only display comments worth acting on. | | **Velocity** | Get through PRs faster | Too many PRs, not enough reviewers. Clear the backlog. | | **Automation** | Let the agent work | Hand off tasks. Reviewed, fixed, merged. | | **Customization** | Set it up myself | No preset. Every setting is yours to choose. | ## Switch to a preset that suits your needs 1. Navigate to the **Configurations** page in the [Qodo portal](https://app.qodo.ai/). 2. Under **Review preset**, at the top of the page, select a preset card. 3. Review the **Switch to \[Preset]?** confirmation dialog. It names each finding-type agent the preset turns on or off, and summarizes how many other settings change and across which tabs, for example Context and Remediation. 4. Select **Switch preset** to apply the change, or **Cancel** to keep your current configuration. Switch to Velocity? confirmation dialog, naming the finding-type agents that change and summarizing additional settings updated across Context and Remediation Background knowledge, including relationship discovery, standards extraction, and rule mining, keeps running regardless of which preset is selected. Findings already published on open pull requests are not affected by a preset switch. Switching a preset applies at whichever configuration level you're currently viewing: workspace, Git organization, or repository. See [Configuration levels](/configuration/portal-configuration#configuration-levels-workspace-git-organization-and-repository). ## Configurations by preset Selecting a preset applies the values below. Any setting not listed here keeps its current value, unaffected by the preset. ### Finding types tab | Setting | Recall | Precision | Velocity | Automation | | - | - | - | - | - | | **Bugs and correctness** | Always on | Always on | Always on | Always on | | **[Rule violations](/governance/rule-enforcement)** | ✓ | ✓ | ✓ | ✓ | | **[Skill insights](/governance/manage-skills-across-repositories)** | ✓ | ✗ | ✗ | ✓ | | **[Cross-repo impact](/governance/cross-repo-code-review)** | ✓ | ✓ | ✗ | ✓ | | **[Spec agent](/code-review/view-requirement-gaps-in-findings)** | ✓ | ✗ | ✗ | ✓ | | **[Design gaps](/code-review/view-ux-deviations-in-findings)** | ✓ | ✗ | ✗ | ✓ | ### Workflow tab | Setting | Recall | Precision | Velocity | Automation | | - | - | - | - | - | | **[Code review trigger](/configuration/workflow#code-review)** | Published PRs | Published PRs | Published PRs | Published PRs | | **[Review every push](/code-review/persistent-review-comments)** | ✓ | ✓ | ✓ | ✓ | | **[Chat with Qodo](/code-review/chat-with-qodo-in-your-pull-requests)** | ✓ | ✓ | ✓ | ✓ | ### Context tab | Setting | Recall | Precision | Velocity | Automation | | - | - | - | - | - | | **[Use cross-repo knowledge as review context](/governance/cross-repo-code-review)** | ✓ | ✓ | ✗ | ✓ | | **[Mine rules from code review history](/governance/rule-enforcement/rule-miner)** | ✓ | ✓ | ✓ | ✓ | | **[Native skills](/governance/manage-skills-across-repositories)** | ✓ | ✗ | ✗ | ✓ | ### Remediation tab | Setting | Recall | Precision | Velocity | Automation | | - | - | - | - | - | | **[Remediation agent](/code-review/remediate-findings-in-prs)** | ✗ | ✗ | ✓ | ✓ | | **[Auto fix](/code-review/remediate-findings-in-prs#automatically-remediate-findings-at-scale)** | ✗ | ✗ | ✗ | ✓ | | **[Suggest committable fixes](/code-review/commitable-code-suggestions)** | ✓ | ✓ | ✓ | ✓ | ### Display tab | Setting | Recall | Precision | Velocity | Automation | | - | - | - | - | - | | **[Display mode](/configuration/display#display-modes)** | Balanced | Lean | Lean | Robust | **Customization** is not in the tables above because it applies no preset. Every setting keeps its existing value, and you configure Finding types, Workflow, Context, Remediation, and Display individually. See [Configure Qodo using the portal](/configuration/portal-configuration) for the full list of settings on each tab. ## Customize settings after applying a preset Each setting in the **Configurations** page shows whether its value comes from the selected preset or a manual change. A gray badge with the preset's name means the setting still matches it. Changing an individual setting after choosing a preset switches that badge to purple **Customized**, without changing the rest of the preset's values. Review preset selector at the top of the Configurations page, showing the Recall, Precision, Velocity, Automation, and Custom cards See [Save or reset your changes](/configuration/portal-configuration#save-or-reset-your-changes) for how unsaved changes are tracked and saved. ## Next steps * [Configure Qodo using the portal](/configuration/portal-configuration): The full tab-by-tab settings reference, including display modes. * [Customize the code review experience](/configuration): The full configuration hierarchy and all available configuration methods. # Configure Workflow settings in the Qodo portal Source: https://docs.qodo.ai/configuration/workflow Controls when and how Qodo runs code reviews and generates PR summaries, plus the chat agent, from the Workflow tab of the Qodo portal's Configurations page. The **Workflow** tab controls when and how Qodo runs code reviews and generates PR summaries, plus the chat agent and which pull requests to skip entirely. Code review section of the Workflow tab, showing preset badges on Code review trigger and Review every push ## Code review Settings governed by a [review preset](/configuration/review-presets) show a badge with the preset's name, or **Customized** if you've changed the value yourself. | Setting | Description | Options | | - | - | - | | **Code review trigger** | Automatically triggers AI-generated code reviews and displays findings when a PR is published, or as soon as it is opened as a draft. | • **Manual only**: Reviews run only when triggered manually using `/agentic_review`
• **Published PRs**: Reviews run automatically when a PR is published (default)
• **Draft and published PRs** GitHub GitLab Azure DevOps: Reviews run automatically as soon as a PR is opened as a draft, and again when it is published | |     ↳ **[Review every push](/code-review/persistent-review-comments)** | Re-runs the code review and updates the existing review comment on every new commit pushed to the pull request, instead of only at publish time. Disabled when **Code review trigger** is set to **Manual only**. | Enable (default) / Disable | | **[Review effort mode](/code-review/use-qodo-in-prs/control-review-effort)** Beta | Sets the depth and speed of the review based on the complexity of the PR. Auto mode includes the deep review at no additional cost during the preview period. | • **Auto**: Dynamically selects the most appropriate review depth based on risk (default)
• **Fast**: Performs a fast review for simple or low-risk changes
• **Balanced**: Applies the default review process for typical code changes
• **Deep**: Performs a more comprehensive review using the most advanced model selection and agentic architecture. Disabled in Research Preview | | **[Publish blast radius label](/code-review/assess-risk-with-blast-radius)** Research Preview

GitHub
GitLab
Azure DevOps | Adds the change's estimated blast radius as a native pull request tag (Azure DevOps) or label (GitHub, GitLab) (for example, "Large blast radius"). | Enable / Disable (default) | ## Ignore PRs The **Ignore PRs** settings skip Qodo's automatic code review and PR summary generation for pull requests that match a pattern. | Setting | Description | Options | | - | - | - | | **[Skip pull requests by title](/code-review/ignore-content-from-analysis#ignore-prs-with-specific-titles)**

GitHub GitLab Bitbucket Gerrit | Pull requests whose title contains any of the listed phrases are not reviewed. | List of phrases | | **[Skip pull requests by author](/code-review/ignore-content-from-analysis#ignore-prs-from-specific-users)**

GitHub GitLab Bitbucket Gerrit | Pull requests are not reviewed when the login of the user who opened or pushed them is one of the listed logins. | List of logins | | **[Skip pull requests by label](/code-review/ignore-content-from-analysis#ignore-prs-containing-specific-labels)**

GitHub GitLab Bitbucket Gerrit | Pull requests carrying any of the listed labels are not reviewed. Labels are matched exactly and are case-sensitive. On Gerrit, hashtags are matched. | List of exact labels | | **[Skip pull requests by source branch](/code-review/ignore-content-from-analysis#ignore-prs-between-specific-branches)**

GitHub GitLab Bitbucket | Pull requests opened from a branch whose name contains any of the listed names are not reviewed. | List of branch names | | **[Skip pull requests by target branch](/code-review/ignore-content-from-analysis#ignore-prs-between-specific-branches)**

GitHub GitLab Bitbucket Gerrit | Pull requests targeting a branch whose name contains any of the listed names are not reviewed. | List of branch names | ## Ignore files The **Ignore Files** settings exclude specific files from the review diff based on their path. | Setting | Description | Options | | - | - | - | | **Exclude files by path** | Files whose path contains any of the listed paths are left out of the review. | List of file paths | ## PR summary | Setting | Description | Options | | - | - | - | | **[PR summary trigger](/code-review/pr-summary)** | Automatically triggers an AI-generated PR summary when a PR is published. | • **Manual only**: Generated using `/agentic_describe`
• **Published PRs**: Generated automatically when a PR is published (default) | | **[Comment location](/code-review/comment-location)** | Determines where Qodo publishes the PR summary. | • **Dynamic location**: Posts a comment if the author wrote a pull request description, otherwise updates the pull request body
• **Native PR description**: Updates the pull request body, adding User Description and AI Description headings
• **Standalone comment**: Posts the summary as a standalone comment, separate from the pull request description (default) | | **[Publish review time estimate label](/code-review/pr-summary#publish-the-review-time-estimate-as-a-native-label-or-tag)**
GitHub GitLab Azure DevOps | Applies the estimated review effort (for example, "10-20 Minutes") as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), and in the pull request list. | Enable / Disable (default) | ## Chat agent The [Chat agent](/code-review/chat-with-qodo-in-your-pull-requests) lets Qodo answer questions and run commands directly on your pull requests. | Setting | Description | Options | | - | - | - | | **Chat with Qodo** Beta | Enables the Qodo chat agent to answer questions and run commands on pull requests. | Enable (default) / Disable | # Understanding the Context Engine Source: https://docs.qodo.ai/core-concepts/context-engine The Context Engine is the core technology layer of the Qodo platform, enabling agents to gather, connect, and reason over context from across repositories, pull requests, organizational rules, and development workflows. The Context Engine is the core technology layer of the Qodo platform. It serves as the platform's knowledge layer, enabling Qodo agents to gather, connect, and reason over context from across repositories, pull requests, organizational rules, and development workflows. By combining code intelligence, historical review data, organizational standards, and repository knowledge, the Context Engine builds a unified, continuously evolving understanding of how an organization writes, reviews, and governs code. All Qodo agents are powered by the Context Engine. ## Why context matters Effective code review depends on more than analyzing isolated changes. Reviews need to account for: * Organizational coding standards * Existing architectural patterns * Historical review decisions * Team-specific practices and workflows * The broader system surrounding a code change Without this context, AI reviews produce generic findings, inconsistent guidance, and low-confidence suggestions. The Context Engine addresses this by continuously gathering and applying contextual knowledge across the development lifecycle. ## Core capabilities ### Organization-aware reviews Qodo agents use organizational context to generate reviews aligned with internal standards, engineering practices, and repository-specific conventions. This produces: * Reviews aligned with organizational rules and best practices * Consistent enforcement of engineering standards * Findings grounded in existing codebase patterns ### High signal-to-noise issue detection The Context Engine helps agents prioritize relevant findings and reduce non-actionable output. This improves: * Detection precision * Finding relevance * Confidence in review output * Reduction of hallucinated or non-actionable issues Findings are prioritized by severity and relevance so developers address the most important issues first. ### System-level reasoning The Context Engine enables agents to reason about the broader system surrounding a code change, not just the changed lines. This includes: * Repository-level context * Cross-file relationships * Historical implementation patterns * Dependencies between components and services As a result, reviews can account for architectural consistency and operational impact beyond the diff. ### Evidence-backed findings Review findings are supported by contextual evidence and surfaced directly within the Git workflow. This provides: * Clear explanations for each finding * Traceable reasoning developers can evaluate * Faster review and remediation ### Continuous learning and evolution The Context Engine evolves as codebases, workflows, and standards change. The platform automatically discovers and refines rules using: * Historical PR decisions * Agent interactions * Repository patterns * `SKILL.md` definitions and organizational guidance This enables continuous rule enforcement without manually maintaining review rules over time. # Understanding PR history indexing Source: https://docs.qodo.ai/core-concepts/pr-history PR history indexing is a core capability of the Context Engine, Qodo's mechanism for learning from your team's pull request activity to judge what actually matters in a review.
Beta GitHub GitLab
Support for additional Git providers is coming soon. PR history indexing is a core capability of the [Context Engine](/core-concepts/context-engine), Qodo's knowledge layer. It indexes and analyzes pull request activity across the repositories connected to Qodo, transforming those repositories from static snapshots into an evolving record of how your team actually reviews and ships code. Qodo uses this record to judge whether something is likely to matter to your team, rather than relying only on generic best practices. ## Why PR history indexing matters AI code review tools often surface many findings, but it can be difficult to know which ones are genuinely important for a specific repository. Without historical context, automated reviews typically suffer from: * **Disconnected suggestions** that don't reflect a team's actual standards * **Invisible past decisions**, causing the same suggestions to resurface repeatedly * **Low signal-to-noise ratio**, making it harder to identify what truly matters PR history indexing addresses this by analyzing how similar issues were handled in the past, so Qodo can distinguish between a pattern your team actively enforces and one that's already been considered and dismissed. ## How it works When reviewing a pull request, Qodo analyzes past pull requests with similar findings and code patterns, along with the comments, discussions, and outcomes that followed. This helps answer questions such as: * Is this issue actually important for this repository? * Does your team usually fix this type of finding? Based on how similar findings were handled previously: * If similar issues were usually fixed, Qodo treats the new finding as likely relevant. * If similar issues were often dismissed, Qodo indicates that the finding may not require attention. ## How PR history indexing works Before Qodo can use a repository's PR history, it indexes that history in the background. The initial indexing run starts automatically during installation, when the repository connects to Qodo, then continues incrementally as new pull requests are merged. Indexing can also be started, retried, or updated manually. Check a repository's indexing progress, and which features it currently unlocks, on the [Monitor and manage repositories](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status) page. ## Continuous learning PR history indexing isn't a one-time snapshot. Qodo evolves with your codebase, learning from accepted suggestions and pull request comments to stay aligned with how your team's standards change over time. As new pull requests are merged and new review decisions are made, Qodo's understanding of what matters updates with them, so relevance judgments stay current instead of drifting out of date. ## What PR history indexing powers PR history indexing is a core capability of the Context Engine that powers other parts of the platform: * **In code review findings:** Every finding gets a relevance classification based on how similar issues were handled in the past. See [Relevance](/code-review/relevance) for how to read it. * **In governance rule generation:** Recurring patterns across your pull request history are mined into enforceable rules. See [Rule Miner](/governance/rule-enforcement/rule-miner) for how that works. ## Related resources * [Understanding the Context Engine](/core-concepts/context-engine): See how PR history indexing fits alongside codebase and organizational context as a source Qodo reasons over. * [Qodo platform core capabilities](/core-concepts/qodo-platform-core-capabilities): See where PR history indexing fits among the platform's other capabilities. * [Monitor and manage repositories](/governance/repositories/manage-repositories): Check PR history indexing status for a repository. # Qodo platform architecture Source: https://docs.qodo.ai/core-concepts/qodo-platform-architecture An overview of the Qodo platform architecture, including ingestion, knowledge storage, and the research and review agents that power code analysis. At a high level, Qodo operates through three interconnected layers: ingestion, knowledge storage, and agentic research, all surfaced through an MCP interface that integrates with your existing tools and agents. Qodo is built around a persistent, structured understanding of your codebase, not just the diff in front of it. The platform connects three layers. Ingest agents parse your repositories into structured knowledge. A rigid knowledge layer stores relationships, history, and embeddings. Deep research agents reason across that knowledge to answer queries and power code review. Everything is surfaced through an MCP interface, making Qodo's capabilities composable with your existing agents, CI pipelines, and developer tools. Qodo platform architecture diagram showing ingestion, knowledge storage, and agentic research layers Qodo platform architecture diagram showing ingestion, knowledge storage, and agentic research layers ## Core components ### Ingest agents Before Qodo can reason about your code, it needs to understand it. Ingest agents crawl connected repositories and process them through two complementary lenses: * Parsing agents: Analyze source files at the syntactic level, extracting structure, interfaces, and relationships between components. * Abstract Syntax Tree (AST) chunking: Breaks code into semantically meaningful units using ASTs rather than arbitrary token windows. This preserves logical boundaries across functions, classes, and modules. Supporting tooling handles auxiliary artifacts, such as configs, CI definitions, and documentation, to give the system a full picture of how each repo fits together. ### Rigid knowledge layer The output of ingestion flows into a structured, multi-modal knowledge layer: | Store | What it captures | | - | - | | Graph DB | Relationships between components, such as call graphs and dependency chains | | Vector DB | Semantic embeddings for similarity search and fuzzy concept matching | | PR & Commit history | Historical context on how and why the codebase evolved | | Auto-generated `.md` | Structured summaries of modules, APIs, and architectural patterns | This layer is what makes Qodo different from approaches that analyze diffs in isolation. Rather than evaluating a change against itself, Qodo evaluates it against the full structure and history of the system. Embeddings are generated using Qodo-7b (Qodo's code-specialized model) and text-embedding-3-large, enabling both deep code comprehension and broad semantic retrieval. ### Deep research agents When a query arrives, whether from a developer, a code agent, or a CI pipeline, it is routed through an MCP server to a set of specialized research tools: * `deep-research`: Performs multi-step reasoning across the knowledge graph to answer questions that require understanding system-wide context. Used for architectural questions, impact analysis, and root cause investigation. * `find-similar`: Locates semantically or structurally similar patterns elsewhere in the codebase. Useful for detecting duplicated logic or finding prior art for a proposed approach. * `deep-issue`: Investigates specific bugs, regressions, or quality concerns with full traceability across PRs, commits, and dependent modules. * `ask`: A general-purpose interface for targeted questions about the codebase. These agents share access to a Context Ranking / Judge layer that scores and filters retrieved evidence before it reaches the final response. This is what keeps output relevant and precise rather than noisy. ### Multi-agent review system On top of the research layer, Qodo runs a suite of specialized review agents, each responsible for a specific quality dimension: * Critical Issue Agent: Detects bugs, logic errors, and edge-case failures * Breaking Changes Agent: Identifies whether a change breaks upstream or downstream consumers * Ticket Compliance Agent: Validates that code matches requirements and acceptance criteria * Duplicated Logic Agent: Flags repeated code across a repository * Rules Agent: Enforces organizational coding standards and best practices ## Related resources * [Qodo platform overview](/core-concepts/qodo-platform-overview): A high-level overview of the platform. * [Qodo platform core capabilities](/core-concepts/qodo-platform-core-capabilities): An overview of capabilities powered by this architecture. # Qodo platform core capabilities Source: https://docs.qodo.ai/core-concepts/qodo-platform-core-capabilities An overview of the Qodo platform's capabilities, including multi-agent review, PR history indexing, governance, and support for complex codebases. Qodo 2.x marks a new generation of the platform, expanding beyond code review into code governance with a suite of advanced capabilities designed for complex engineering environments. Qodo takes a multi-agent approach to AI code review, grounded in deep codebase context. Code review encompasses many responsibilities simultaneously: finding bugs, enforcing standards, assessing risk, and understanding system-level implications. Traditional single-agent approaches often trade depth for coverage, leaving gaps. Qodo addresses this with a system designed to reason across multiple dimensions simultaneously. ## Multi-agent expert review Qodo breaks code review into specialized responsibilities handled by multiple review agents. Each agent focuses on a specific area: * Logic correctness and bug detection * Standards compliance and maintainability * Architectural and system-level reasoning * Risk assessment across changes Agents operate in parallel with dedicated context, enabling deeper analysis without slowing reviews. A judge agent consolidates findings, removes duplicates, resolves conflicts, and filters results by confidence and relevance. Only actionable, high-signal feedback reaches you, ensuring efficient, reliable reviews. ## Deep codebase context High-quality code review requires understanding the entire repository and related modules, not just a pull request diff. Qodo's Context Engine indexes and reasons over complex codebases to: * Detect cross-module issues * Recognize architectural patterns and dependencies * Identify risks that span multiple services or components This deep context ensures subtle, system-level issues are detected and that recommendations are accurate and actionable. ## PR history indexing and continuous learning Introduced in Qodo 2.2, PR history indexing transforms code review from treating repositories as static snapshots into understanding their evolutionary story. Qodo indexes your repository's full pull request history to understand how your team evaluates code. It analyzes patterns across thousands of merged PRs. ### Finding recommendation agent The **Finding Recommendation Agent** evaluates every potential issue against your team's historical behavior before surfacing it. It analyzes signals from past PRs including: * Whether similar issues were raised previously * How reviewers responded to those findings * Whether the flagged code was actually changed as a result * Which suggestions sparked discussion versus which were silently ignored By comparing new findings against this history, the agent prioritizes suggestions your team is likely to act on, and deprioritizes findings that have historically received little attention. ### Problems it solves Without PR history context, automated reviews typically suffer from: * **Disconnected suggestions** that don't reflect your team's actual standards * **Invisible past decisions** causing the same suggestions to resurface repeatedly * **Low signal-to-noise ratio** making it harder to identify what truly matters Over time, this learning improves the precision and relevance of every review, helping you maintain consistent quality without review fatigue. See [Understanding PR history indexing](/core-concepts/pr-history) for more on how this works, and where it shows up across the platform. ### Availability Currently in Beta for GitHub and GitLab, with Bitbucket and Azure DevOps support coming soon. ## Structured, actionable findings Each issue surfaced by Qodo includes: * A clear explanation of the problem and why it matters * The relevant code snippet and context * Semantic quality labels (e.g., reliability, maintainability) * Evidence and reasoning supporting the finding * Suggested remediation steps This structure helps you prioritize fixes efficiently and reduces unnecessary back-and-forth in reviews. ## Governance and rule enforcement Qodo provides a centralized rules system to define and enforce organizational standards across the repository. This includes: * Security policies * Coding and style standards * Architectural conventions * Compliance requirements Rules are applied consistently to all pull requests, ensuring you maintain quality and compliance at scale. ## Agentic quality workflows Beyond individual reviews, Qodo supports custom agentic workflows that automate quality checks and validation across projects. You can configure workflows to enforce standards, detect risk, and surface actionable insights consistently for all changes. This approach allows you to scale quality and compliance practices without adding manual review overhead. ## Support for complex and codebases Qodo is designed to handle large, distributed codebases. Its agents reason across multiple services, evaluating changes in the context of the broader system. This enables detection of: * Architectural and system-level risks * Multi-service dependency issues By understanding the structure and relationships within large engineering environments, Qodo ensures consistent, reliable, and high-quality review outcomes. # AI codebase quality and governance platform Source: https://docs.qodo.ai/core-concepts/qodo-platform-overview An overview of the Qodo AI codebase quality and governance platform, including how it works, its core components, and how it integrates into your development workflow. Qodo is an AI code review platform that provides automated, context-aware review across IDEs, pull requests, CLI, and Git workflows. It builds a persistent understanding of your repositories, including their structure, history, and dependencies, so reviews are based on the full system rather than isolated changes. Qodo is designed for complex environments, where understanding context is required to identify issues and enforce standards consistently. Qodo is an AI code review platform that brings automated, context-aware review into your IDE, pull requests, CLI, and Git workflows. It's built for complex codebases, with deep context, to surface critical issues early, enforce standards, shorten feedback cycles, and ship better code faster. In Qodo, AI code review, code quality, and SDLC governance come together in one platform for teams that care as much about how code is reviewed as how fast it ships. Unlike tools that evaluate a diff in isolation, Qodo builds a persistent understanding of your repositories, their structure, history, and dependencies, so every review is grounded in how the full system works. ## How it works Qodo analyzes code in the context of the entire codebase. Instead of evaluating diffs in isolation, it maintains a continuously updated representation of repositories and their relationships. This allows it to: * Identify issues that depend on cross-file or repository context * Apply rules and standards consistently in environments * Provide feedback directly within existing development workflows Qodo integrates with IDEs, pull requests, and command-line tools, so reviews happen where code is written and reviewed. ## Platform components Qodo consists of several core components: * Context engine: Builds and maintains an understanding of repository structure and dependencies * Review engine: Analyzes code changes and generates feedback based on context * Integrations layer: Connects Qodo to IDEs, Git providers, and CLI workflows ## Next steps [Platform architecture](/qodo-platform-architecture): A detailed description of system design and data flow. [Core capabilities](/core-concepts/qodo-platform-core-capabilities): A full breakdown of what Qodo can do. # Understanding the Agentic Toolbox Source: https://docs.qodo.ai/core-concepts/understanding-agentic-toolbox A CLI-powered quality counterpart for coding agents. Extend your coding agent with Qodo capabilities for codebase understanding, standards, and review. The Agentic Toolbox gives coding agents access to Qodo’s code understanding, team rules, code review, and finding resolution capabilities. Agents can use these capabilities while planning, writing, and reviewing code. The Agentic Toolbox helps coding agents: * **Understand the codebase:** Analyze code, dependencies, and the potential impact of changes. * **Apply team rules:** Use your organization’s coding standards and guidelines while working on code. * **Review changes:** Check changes before a pull request and identify issues that need attention. * **Resolve findings:** Help fix issues identified during review. ## How the Agentic Toolbox works The Agentic Toolbox works across coding agents, developer environments, and custom engineering systems. * **Coding agents and IDEs:** Access Qodo through plugins, CLI, and MCP in tools such as Claude Code, Codex, and Kiro. * **Natural-language requests:** Ask your coding agent to perform a task, and the agent can select and run the appropriate Qodo capability. * **Custom workflows:** Connect Qodo through APIs and MCP to CI/CD pipelines, internal tools, and automations. * **Local CLI:** Use the CLI to install the Agentic Toolbox, manage authentication and credentials, run commands, and work with structured output. Every access point connects to the same managed Qodo core, so teams can apply consistent capabilities and standards across their development environments. ## Give agents the context they need AI coding agents need more than the files they are currently editing to understand the potential impact of a change. Qodo’s Context Engine brings connected repositories, pull request history, specifications, and live Git state into the coding session. It helps agents understand relationships across repositories, services, and workflows before they plan or change code. With this broader context, agents can identify dependencies and reason about the potential blast radius of a change. ## Build quality into the agentic workflow The Agentic Toolbox adds an independent quality layer to the agentic workflow. Agents can review their work before a pull request is opened, giving them an opportunity to identify and fix issues while they are still working on the code. For example: * **Reviewer:** Reviews committed and uncommitted local changes directly in the coding session and returns structured findings. * **PR Resolver:** Resolves issues identified during pull request review. It works with findings from the pull request review rather than reviewing the local coding session. This allows agents to check their work against codebase context, dependencies, blast radius, and team rules before changes reach human reviewers. Human reviewers can then focus on risks, architectural decisions, and issues that require human judgment rather than reviewing every line. ## Govern agentic development at scale Enterprise engineering teams need a central source of truth for their standards. They also need control over who can use those standards, where they apply, and how they change over time. Qodo’s Agentic Toolbox provides centralized governance so enterprises can: * **Version rules:** Maintain and update engineering standards over time. * **Set permissions:** Control who can access and apply rules. * **Scope standards:** Apply rules to specific teams, repositories, or workflows. * **Enforce standards:** Apply consistent checks across coding agents and development environments. * **Audit governance:** Track how standards are managed across the organization. This means teams can give developers flexibility to use the coding agents and environments they prefer while maintaining a consistent quality standard across the organization. ## Start using the Agentic Toolbox The Agentic Toolbox is available through multiple interfaces and integrations. Choose the environment you use to get started. **[Explore the Agentic Toolbox](/agentic-toolbox)** # Deployment models Source: https://docs.qodo.ai/deployment-models An overview of Qodo’s three deployment models, multi-tenant, single-tenant, and on-premises, and guidance on choosing the right one for your security and infrastructure requirements. ### Multi-tenant The default cloud option. Connect your repository, configure your review settings, and start immediately. No infrastructure to manage, no setup overhead. Best for teams that want instant access without operational complexity. ### Single-tenant A dedicated Qodo instance running within your own VPC. You get the simplicity of a managed service with the isolation of private infrastructure. Ideal if you need data residency or want to keep code off shared infrastructure. ### On-premises A dedicated Qodo instance running within your own VPC. You get the simplicity of a managed service with the isolation of private infrastructure. Ideal if you need data residency or want to keep code off shared infrastructure. For more information, see [On-premises](/on-prem). ## Check your deployment type Qodo supports three deployment types: Multi-tenant (MT), Single-tenant (ST), On-premises. * **Multi-tenant (MT)**: Used for Free, Team, and some Enterprise plans. Your instance is multi-tenant if the portal URL does not include your organization’s domain. * **Single-tenant (ST)**: Available for Enterprise plans. Your instance is single-tenant if the portal URL includes your organization’s domain. Example: app.companyname.st.qodo.ai * **On-premises**: Hosted inside your organization’s infrastructure. On-premises environments typically use a custom internal URL provided by your organization. # Quickstart: From sign-up to your first code review Source: https://docs.qodo.ai/get-started Create your Qodo account, link your Git account, and get automated code reviews on your pull requests. Create your Qodo account and start receiving automated code reviews on your pull requests. **Are you an organization admin?** Set up your organization first. See [Set up your Qodo organization as an admin](/set-up-your-qodo-organization). ## Step 1: Create your account Go to [app.qodo.ai/signin](https://app.qodo.ai/signin) and choose how you'd like to sign in. Select your Google account and you'll be redirected back to Qodo automatically. Enter your GitHub credentials, click **Authorize**, and you're in. Enter your email, check your inbox for a verification link, and click to activate. **Invited by your team?** Open the email with subject **"Join your team – enjoy Qodo"**, click **Accept the invite**, then sign in with the same email address that received the invitation. ## Step 2: Link your Git account Linking your Git account lets Qodo identify your pull requests and commits. Click your name at the bottom of the left sidebar. Select **Link your Git user account**. See [Account management](/account-management/manage-your-qodo-account#additional-settings). ## Step 3: Open a pull request Qodo automatically reviews every pull request in your organization's connected repositories. Open a pull request and Qodo will: Your team's standards enforced on every change, automatically. Bugs, risks, and standard violations, explained and prioritized. Multi-agent review across your entire codebase, not just the diff. ## Next steps * [The Qodo Code Review experience](/code-review): Learn how Qodo reviews your pull requests. * [Qodo portal quick tour](/qodo-portal-quick-tour): Find your way around the Qodo portal. # Qodo code review analytics Source: https://docs.qodo.ai/governance/code-review-analytics Analyze how your team responds to Qodo findings across pull requests, repositories, and PR authors. Requires Admin permissions. The **Analytics** dashboard in the Qodo portal shows how your team responds to Qodo findings across pull requests, repositories, and PR authors. Each finding is tracked through its response. An **acted-on finding** is one with a final outcome: accepted, not accepted, or dismissed. Findings still pending a decision aren't included. An **accepted finding** is one that resulted in an accepted code change. Keeping these metrics separate shows both whether findings reach a decision and whether those decisions lead to code changes. Break down the data by repository, PR author, severity, category, and finding type. Finding types include bugs and security issues, as well as violations of your organization's rules, gaps against PR requirements, team insights, skills, and changes that affect related repositories. Use the dashboard to understand Qodo's impact over time, identify high-severity findings that remain unaddressed, and compare finding activity and response across repositories and PR authors. To find the view that answers a specific question, see the [Analytics cheat sheet](#analytics-cheat-sheet). Code review analytics dashboard ## Filter analytics You can filter analytics by: * **Time range:** Today, Last 7 days, Last 30 days, Last 90 days, or a custom range. The time range filters by when Qodo raised the finding. Today starts at midnight UTC. A custom range can cover up to 365 days. * **Severity:** Low, Medium, High, or All levels. * **Category:** Accessibility, Architecture, Compliance, Correctness, Maintainability, Observability, Performance, Quality, Reliability, Security, and Testability. For more information, see the [Finding categories](#finding-categories) table. * **Type:** Bug, Rule violation, Requirement gap, Team insight, Skill, Cross-repo, and Security. * **Bug:** Logic errors, edge cases, and anti-patterns in the change. * **Rule violation:** Code that breaks one of your organization's rules. * **Requirement gap:** The pull request does not fully implement a requirement from its linked ticket or specification. * **Team insight:** A finding raised from a team profile, which reviews the pull request the way the most relevant teammates would. * **Skill:** A finding raised by a skill defined in your repository. * **Cross-repo:** A change that breaks code in a related repository. * **Security:** A vulnerability in the change, such as an OWASP or CWE-class issue. * **Repository:** One or more indexed repositories. * **PR author:** One or more PR authors. ## Finding categories | **Category** | **What it covers** | **Examples** | | - | - | - | | Accessibility | Issues that make UI unusable for people with disabilities | Missing alt text, missing ARIA labels, poor keyboard navigation | | Architecture | Design and structural problems across modules or services | Layer violations, tight coupling, circular dependencies | | Compliance | Violations of organizational policies, standards, or regulatory requirements | Breaking coding standards, license issues, PII handling rules | | Correctness | Logic errors that produce wrong results | Off-by-one errors, wrong conditions, unhandled edge cases | | Maintainability | Code that's hard to change or extend safely | Large functions, duplication, hidden dependencies | | Observability | Gaps in the ability to monitor and debug in production | Missing logs, swallowed errors, no metrics on critical paths | | Performance | Inefficiencies affecting speed or resource use | N+1 queries, unnecessary loops, missing caching | | Quality | General code hygiene and readability | Unclear naming, dead code, inconsistent style | | Reliability | Code that can fail or behave unpredictably under real conditions | Unhandled errors, missing retries or timeouts, resource leaks | | Security | Vulnerabilities that could be exploited | Injection, hardcoded secrets, missing authorization checks | | Testability | Code that is hard to test or not covered by tests | Hidden dependencies, untestable side effects, no tests for new logic | ## Understand analytics metrics Analytics metrics are calculated from Qodo findings data. The dashboard counts findings raised on a pull request or linked to one. Local findings and findings detected after merge are excluded. ## Measure the impact of Qodo findings The **Impact** view gives you an organization-wide view of how Qodo findings affect pull requests. Use it to understand how often findings lead to action, how many result in accepted code changes, and how broadly Qodo findings reach across your organization. | **Metric or view** | **What it shows** | | - | - | | **PRs impacted** | Pull requests with at least one accepted finding. | | **Accepted findings** | Qodo findings that resulted in an accepted code change. | | **High-severity acceptance rate** | Accepted high-severity (action-required) findings as a percentage of high-severity findings acted on: accepted, not accepted, and dismissed, with pending findings not counted. The rate appears once at least 5 high-severity findings have an outcome, and the rate for all findings shows under it. | | **PR authors** | PR authors whose pull requests received at least one Qodo finding. | | **Median time to merge** | The median time from pull request opened to merged, for pull requests merged in the selected time range. Not available when a Category, Type, or Severity filter is applied. Note that data collection started from 29 September, 2026. | | **What was raised and acted on** | The findings Qodo raised and how authors responded to them. | | **Impact across PRs** | How findings are distributed across impacted pull requests. | | **Accepted findings: count and rate over time** | The number of accepted findings and the acceptance rate over time. | | **Qodo reach over time** | How the number of pull requests, repositories, and PR authors with at least one finding changes over time. | | **Where findings were raised** | How many findings Qodo raised locally, before a pull request existed, and how many it raised on the pull request. | ## Identify where findings have the most impact by repository The **By repository** view breaks down finding activity by repository. Use it to understand how findings are acted on across repositories and where acceptance rates differ. Analytics dashboard by repository The table includes: * **Repository:** The repository where findings were raised. * **Findings acted on:** The number of findings with a final outcome: accepted, not accepted, or dismissed. * **Findings accepted:** The number of findings that resulted in an accepted code change. * **Acceptance rate:** The percentage of findings that were accepted. You can view all findings or focus on high-severity findings. Select a repository to drill down into its analytics. ## Understand finding response by PR author The **By PR author** view shows how authors respond to Qodo findings across their pull requests. Use it to understand response patterns, track changes over time, and identify findings that remain unaddressed. Analytics dashboard by PR author ### Weekly engagement Track finding response across PR authors week by week. The view shows: * **Acted on pull request findings:** PR authors who accepted at least one finding. * **High-severity acceptance rate:** The percentage of high-severity findings that resulted in an accepted code change. * **Received only:** PR authors who received findings but accepted none. * **High-severity unaddressed:** High-severity findings that were not addressed. ### Author table See finding activity and response for each PR author. The table includes: * **PR author:** The author of the pull requests where findings were raised. * **Findings acted on:** The number of the author's findings with a final outcome: accepted, not accepted, or dismissed. * **Findings accepted:** The number of findings that resulted in an accepted code change. * **Acceptance rate:** The percentage of the author's findings that were accepted. Select an author to drill down into their findings and activity. ## Export and share analytics Use the **⋯** menu at the top of the dashboard to export or share your analytics. ### Export CSV Download your findings as a CSV file named `findings.csv` for reporting, audits, or analysis in your own tools. Each row represents a single Qodo finding. The export includes up to 10,000 findings. It can also include outdated findings and findings detected after merge, which the dashboard excludes, so CSV totals may not match the dashboard. | **Column** | **Description** | | - | - | | Finding ID | Unique identifier for the finding | | Title | Short summary of the finding | | Description | Full explanation of the issue Qodo raised | | Category | The finding category, such as Correctness or Compliance | | Action level | The finding's severity, as a raw value: `action_required` (High), `remediation_recommended` (Medium), or `informational` (Low) | | Finding type | The finding type, such as `bug`, `rule_violation`, or `cross_repo` | | Attribution status | How the author responded to the finding: `implemented` (accepted), `not_implemented`, `dismissed`, `pending`, `outdated`, or `detected_after_merge` | | Git organization | The organization that owns the repository | | Git repository | The repository where the finding was raised | | PR URL | Link to the pull request | | PR author | The author of the pull request | | Git provider | The Git platform, such as GitHub or GitLab | | Branch | The branch the pull request comes from (the source branch, not the target) | | Created at | When Qodo raised the finding | ### Share dashboard Share the current view of the dashboard with others in your organization. ## Analytics cheat sheet Use this cheat sheet to quickly find the analytics section that answers your question. ### Impact | **Question** | **Where to look** | | - | - | | Is Qodo making a difference in our pull requests? | Accepted findings, Acceptance rate | | How many findings did Qodo raise, and how many did developers act on? | What was raised and acted on | | Is Qodo reaching most of our pull requests, or just a few? | Impact across PRs | | Are developers accepting more findings over time? | Accepted findings: count and rate over time | | Is Qodo adoption growing across the organization? | Qodo reach over time | | How many findings are caught before a pull request exists? | Where findings were raised | | Are developers following our rules? | Accepted findings, filtered by Type: Rule violation | | Are pull requests meeting their stated requirements? | What was raised and acted on, filtered by Type: Requirement gap | | Are changes breaking other repositories? | What was raised and acted on, filtered by Type: Cross-repo | | How are we handling security findings? | Acceptance rate, filtered by Type: Security | ### By repository | **Question** | **Where to look** | | - | - | | Which repositories get the most findings? | The repository table, ranked by findings acted on | | Which repositories have the most findings with a final outcome? | Findings acted on | | Which repositories turn findings into code changes? | Findings accepted | | Where do acceptance rates differ the most? | Acceptance rate | | Which repositories have high-severity findings that remain unaddressed? | High-severity only | | Which repositories have the most compliance issues? | Repository, filtered by Category: Compliance | | Where is architectural drift showing up? | Repository, filtered by Category: Architecture | ### By PR author | **Question** | **Where to look** | | - | - | | How is finding response changing week to week? | Weekly engagement | | Which authors accept at least one finding? | Acted on pull request findings | | Are authors addressing high-severity findings? | High-severity acceptance rate | | Which authors received findings but accepted none? | Received only | | What high-severity findings remain unaddressed? | High-severity unaddressed | | Where are finding response patterns different across authors? | Received only, Acceptance rate | | Which authors have the most accepted findings? | Findings accepted, Acceptance rate | # Cross-repository code review Source: https://docs.qodo.ai/governance/cross-repo-code-review Detect breaking changes across repository boundaries before they reach production. Define relationships between repositories and let Qodo review every relevant pull request automatically.
Beta
Cross-repository code review extends Qodo's code review to catch breaking changes across repository boundaries before they reach production. In distributed systems, these are the hardest bugs to find: a function signature change in a shared library, an API contract shift, or a schema evolution can all pass single-repository review cleanly because the reviewer has no visibility into the other repositories in the relationship. Relationships between repositories are discovered automatically by Qodo or defined manually by your team, and every relevant pull request (PR) is reviewed across repository boundaries automatically. Relationships can span Git providers, so teams working across multiple platforms are covered by a single review process. ## How cross-repository code review works 1. **PR opens**: A developer opens a PR in a repository with a defined relationship. 2. **Qodo identifies connected repositories**: Qodo identifies the connected repositories in the relationship. 3. **Agent traces impact**: The agent reads the related repositories and traces the impact in both directions: code that depends on the change, and code in the PR that may conflict with the other repository (for example, by passing the wrong parameters). 4. **Finding surfaces**: If a breaking change is detected, a `Cross-repo` conflict finding appears in the PR with a direct link to the affected lines in the related repository. 5. **Developer acts**: The developer reviews the impact and decides how to proceed: update their changes, coordinate with the affected team, or accept the breaking change. **Target a specific branch or PR in the other repository** By default, Qodo targets the main branch of each connected repository. To point the review at a different branch or pull request, include a link to that branch or PR (in the other repository) in your PR description, or in a ticket linked to the PR. The cross-repository agent extracts the target branch from the branch or PR URL. ## When a cross-repository code review runs When you add a relationship, Qodo analyzes both repositories and classifies the type automatically. It uses that context to determine what to check on every subsequent PR. You do not need to configure triggers. A review runs when a PR modifies a component covered by a defined relationship, for example: * An exported function or class in a shared library or SDK. * A REST API endpoint signature or response contract. * A database schema or data model consumed by other services. * An infrastructure or configuration file used across repositories. * A pipeline or build artifact consumed downstream. The review runs on any PR in a repository that has at least one active relationship. ## Relationship types When Qodo classifies a relationship, it assigns one of the following types. The type is informational and does not change what the agent checks. The agent uses the full relationship context to detect breaking changes. | Type | Description | | - | - | | **Code** | One repository imports, calls, or depends on code exported by the other, such as a shared library, SDK, or utility package. | | **Service** | One repository calls an API or service exposed by the other, such as a frontend calling a backend REST API. | | **Data** | Both repositories share a database, schema, or data store, such as two services reading from the same database. | | **Pipeline** | One repository depends on a build artifact, container image, or pipeline output produced by the other. | | **Docs** | One repository holds the documentation for the other. | | **Other** | The relationship does not fit one of the above types. | ## Where cross-repository findings appear Cross-repository findings appear alongside standard Qodo review findings in the PR, tagged as `Cross-repo`. Qodo PR summary comment showing a Cross-repo conflict finding tagged Cross-repo conflict with a description and the affected code They also appear on the Findings page in the Qodo portal with the same tag. To view how cross-repository conflicts are displayed in the pull request, see [View cross-repository conflicts in your findings](/code-review/view-cross-repo-conflicts-in-findings). ## Related resources * [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships): Define relationships between your repositories. * [Manage code review across repositories](/governance/repositories): View and manage your repositories and installations. * [Monitor organization-wide PR findings](/governance/view-all-findings-in-organization): Monitor cross-repository findings across your organization. # Manage cross-repository relationships Source: https://docs.qodo.ai/governance/cross-repo-code-review/repository-relationships Define relationships between repositories to enable cross-repository code review. Discover them automatically, on demand, or add them yourself, then view and remove relationships from the Repositories page.
Beta
Repository relationships define which repositories depend on each other. Qodo can discover them automatically, you can trigger discovery for a specific repository, or you can define them manually. Once defined, Qodo automatically uses them to detect breaking changes across repositories when a pull request (PR) is opened. This runs by default. See [Disable Cross-repo impact](#disable-cross-repo-impact) to turn it off. ## Prerequisites * Repositories must be installed using the Qodo installation wizard. Repositories installed using a previous method will not appear until reinstalled. See the [migration guide](/install-qodo/migration-guide) for your Git provider. ## Where to manage relationships The **Repositories** page has two entry points for managing relationships: * **Relationships tab**: View and manage all relationships across your organization. * **Repository sidebar**: View and manage relationships scoped to a specific repository. Repositories tab listing repositories with their installation, provider, repository status, Active relationships count, and code review toggle ## View all relationships 1. Go to the **Repositories** page and select the **Relationships** tab. The tab shows all relationships defined across your organization. Toggle between **Table** and **Graph** view using the controls at the top left. Use this view to audit relationship coverage across your organization. Relationships tab in Graph view showing repositories connected by lines, with a Type filter for Code, Service, Data, Pipeline, and Other ## View relationships for a specific repository 1. Go to the **Repositories** page and select the **Repositories** tab. 2. Click the row of the repository you want to inspect. 3. The sidebar opens on the right. The **Cross repository relationships** section shows all relationships defined for that repository, including the linked repository, relationship type, description, and status. Repository sidebar showing the Cross repository relationships section with linked repositories, their type, description, status, and Created and Updated dates ## Discover and add relationships Qodo discovers relationships automatically for key repositories. You can also trigger discovery on demand for a specific repository, or add relationships yourself. These are displayed in the repository sidebar's **Cross repository relationships** section or the **Relationships** table, and used the same way during review. Relationships are non-directional. The order of Repository A and Repository B does not affect how the agent uses the relationship. ### Automatic discovery across your organization Qodo discovers relationships automatically, without any action from you. Any relationships found are displayed in the **Cross repository relationships** section. When discovery happens depends on which installation wizard connected your Git provider to Qodo: | Installation method | When relationships are discovered | | - | - | | Wizard, Qodo 2.10 or later | Automatically, for key repositories, whether selected during installation or added later | | Wizard, before Qodo 2.10 | Automatically, the first time a pull request merges in a repository with no relationships yet | | Legacy method (before the installation wizard) | Not available until the repository is reinstalled using the wizard. See [Prerequisites](#prerequisites) | ### Auto-discover relationships per repository Trigger Qodo to scan a specific repository and find its related repositories. 1. Go to the **Repositories** page and select the **Repositories** tab. 2. Click the row of the repository you want to analyze to open its sidebar. 3. In the **Cross repository relationships** section, click **Auto-discover**. Qodo runs the discovery in the background and adds the relationships it finds. While discovery is running, the section shows a **Discovering** state, which usually takes a few minutes. You can keep working until it finishes. Cross repository relationships section showing the empty state with an Auto-discover button and a confirmation that auto-discovery has started Discovered relationships appear in the **Cross repository relationships** section as Qodo finds them, labeled **Auto-discovered** to distinguish them from relationships you added manually. If auto-discovery does not find any relationships, Qodo shows a **No relationship found** message. Cross repository relationships panel listing discovered related repositories with their status Only one discovery run can be active per repository at a time. If you start auto-discovery while a run is already in progress, Qodo shows that auto-discovery is already in progress for the repository. ### Add relationships manually You can also add relationships yourself from a repository's sidebar. 1. Go to the **Repositories** page and select the **Repositories** tab. 2. Click the row of one of the repositories to open its sidebar. 3. In the **Cross repository relationships** section, under **Add related repositories**, select the **Select repositories to create a relationship** field. 4. Select the repositories to link. Each repository supports up to 100 relationships. 5. Click **Add relationships**. Cross repository relationships panel in the sidebar with a repository picker, several repositories selected, and an Add relationships button ### Keep relationship information current Regardless of how a relationship was created, later activity keeps the information about the relationship current. You can see when that happened from its **Updated** date, and which pull request caused it from a link to that PR. See [Relationships tab reference](/governance/repositories/relationships#relationships-tab-reference) for the full list of fields shown for each relationship. ## Relationship statuses Whether a relationship is auto-discovered or added manually, Qodo processes it and shows one of the following statuses: | Status | Description | | - | - | | **Pending** | Qodo is analyzing the repositories and building the relationship context. This typically takes a few minutes. | | **Active** | The relationship is confirmed and in use. Qodo checks this relationship on every relevant PR. | | **Not found** | Qodo could not determine a connection between the two repositories. You can add custom instructions to guide the analysis and retry. See [Retry a relationship connection](#retry-a-relationship-connection). | | **Error** | Something went wrong during processing. [Retry the relationship connection](#retry-a-relationship-connection) from the three-dot menu, or delete and recreate it. | For a description of each relationship type, see [Cross-repository code review](/governance/cross-repo-code-review#relationship-types). Once a relationship is active, Qodo checks it on every subsequent PR. By default, Qodo targets the main branch of each connected repository. To point the review at a different branch or pull request, include a link to that branch or PR (in the other repository) in your PR description, or in a ticket linked to the PR. Existing open PRs are not retroactively updated. When a PR triggers a review, Qodo analyzes the 10 active relationships most relevant to that PR. ## Retry a relationship connection If a relationship shows **Not found** or **Error**, Qodo could not establish the connection on its own. You can provide additional context to guide the analysis and retry: 1. Click the three-dot menu on the relationship. 2. Select **Retry with custom instructions**. 3. In the **Retry with custom instructions** dialog, describe the dependency between the two repositories. These instructions give the agent additional context to guide the relationship analysis. 4. Click **Retry**. Retry with custom instructions dialog with a text field for describing the dependency between the repositories and a Retry button Qodo reprocesses the relationship using your instructions. If it establishes a connection, the status changes to **Active**. ## Remove a relationship Qodo doesn't automatically remove a relationship once the dependency no longer applies, delete it manually to keep coverage accurate. Deleting a relationship means Qodo will no longer use it to trace impact between the two repositories. If you delete a relationship by mistake, you will need to recreate it from scratch. ### From the Relationships tab 1. Go to the **Repositories** page and select the **Relationships** tab. 2. Click the three-dot menu on the relationship you want to remove. 3. Select **Delete relationship**. 4. In the confirmation dialog, click **Delete relationship** to confirm. ### From the repository sidebar 1. Go to the **Repositories** page and select the **Repositories** tab. 2. Click the row of the relevant repository. 3. In the sidebar, click the three-dot menu on the relationship you want to remove. 4. Select **Delete**. 5. Confirm the deletion. ## Export relationship details Each relationship has a markdown file that describes the dependency in detail. To download it, click the three-dot menu on any relationship and select **Download markdown**. Use this to review what Qodo has inferred about the relationship or to share it with your team. ## Disable Cross-repo impact Cross-repo impact is enabled by default. To turn it off: ### Disable using the Qodo portal (Recommended) Navigate to **Configurations** > **Finding types** and disable the **Cross-repo impact** toggle. See [Configure Finding types in the Qodo portal](/configuration/finding-types). ### Disable using .pr\_agent.toml ```toml theme={null} [review_agent] enable_cross_repo_agent = false ``` Default: `true`. ## Next steps * [Cross-repository code review](/governance/cross-repo-code-review): Understand how Qodo uses relationships to detect breaking changes. * [Manage code review across repositories](/governance/repositories): View and manage your repositories and installations. # Managing governance in Qodo Source: https://docs.qodo.ai/governance/governance-management How the Qodo portal serves as the central point for managing rules, teams, and governance settings across your organization. The Qodo portal is where organization-level governance is configured and managed. Rules defined in the portal apply across all connected repositories by default, with scoping controls that allow settings to be overridden at the team or repository level where needed. ## Rules and enforcement Rules are created, scoped, and managed from the portal. Organization-level rules apply across all repositories. Rules can be scoped to specific teams or repositories, allowing stricter enforcement in areas that handle regulated data or follow different coding conventions. The portal also surfaces rule health: the Rules Expert Agent continuously identifies conflicts, duplicates, and outdated rules, and flags them for review in the portal so rule sets stay current as codebases evolve. ## Review behavior Organization-level defaults for code review behavior are configured from the portal. This includes which review commands are available, whether reviews trigger automatically or manually, and timing controls such as whether reviews run on draft PRs or only on published PRs. Feedback presentation is also configurable: whether findings appear as conversation summaries or inline annotations, the severity threshold for inline comments, and the volume of findings surfaced per review. ## Review scope Inclusion and exclusion rules control which repositories, branches, folders, and files are in scope for review at the organization level. Pull requests can be filtered by ticket, label, or other criteria to reduce noise from changes that do not require full governance coverage. ## Teams and access Administrators manage teams, team membership, and access controls from the portal under Platform > Organization. Team-level configuration allows rules and settings to be scoped to a subset of repositories without affecting the broader organization. ## Analytics The portal provides organization-wide visibility into governance outcomes: rule adoption rates, violation trends, and improvement metrics across all repositories. These analytics are available at the organization, team, and repository level, and can be used to identify where standards are being applied consistently and where rule sets need refinement. For details on how rules are created and maintained, see [Rules and governance](/governance/rules). # Guidelines for implementing governance at scale Source: https://docs.qodo.ai/governance/implementing-governance-in-organization Eight steps for implementing code review governance across engineering organizations, with ownership assigned at each stage. Implementing code review governance is most effective when done systematically. Each step addresses a specific failure mode common across engineering organizations at scale. The steps can be implemented independently, but they are most effective in order: accountability is established before automation, and the feedback loop closes last. ## 1. Measure current behavior Who owns: Platform team, engineering leadership Track baseline metrics before making any changes: average time to first review, time to merge, how often PRs are reopened after merge, and how many issues surface post-merge as fixes. Without these baselines, it is impossible to evaluate whether the steps that follow are having measurable impact. ## 2. Define what approval means Who owns: Engineering leadership, tech leads An approval should certify specific things: that the code is correct, that tests cover the change, that it complies with security and policy rules, and that it is architecturally aligned with the system. Document this explicitly. When approval means different things to different reviewers, enforcement becomes inconsistent and standards degrade over time. ## 3. Separate blocking from optional Who owns: Tech leads, reviewers Not every finding should prevent a merge. Categorize findings into three levels: blocking (must be resolved before merge), important (should be addressed), and optional (suggestions for improvement). This prevents low-signal findings from creating noise and gives developers clear signal on what actually needs to change. ## 4. Automate baseline enforcement Who owns: Platform and DevOps team Push tests, linting, ownership validation, and security checks into CI gates. These run automatically and block merge on violations before human review begins. Automating this layer removes mechanical checks from the reviewer's workload and ensures they are applied consistently on every pull request. ## 5. Move design decisions out of PRs Who owns: Architecture group, tech leads Architectural decisions made during pull request review are expensive to change and create inconsistency. Require design documentation for changes that affect system architecture and block merges on changes that lack it. Pull requests then contain implementation detail only, making governance checks more precise. ## 6. Make reviewer responsibility explicit Who owns: Engineering leadership An approval is a statement of ownership: the reviewer owns the correctness and maintainability of what is merged, not just that it looks acceptable. Making this explicit changes how reviewers engage with changes and creates accountability for what escapes into production. ## 7. Optimize for fast first feedback Who owns: Engineering leadership Set a response SLA for first review and escalate when no reviewer has responded. Slow first response is the most common cause of PR queue buildup. Defining ownership and escalation paths keeps review moving without requiring individual reviewers to monitor PR queues manually. ## 8. Use escaped issues to improve Who owns: Platform, reliability, and security teams When production incidents occur, trace them back to the pull requests that introduced the issue. Identify which check was missing or which guarantee was not enforced. Add the missing check to the CI gate or governance rule set. This creates a feedback loop between production failures and the governance process. # Manage skills across repositories Source: https://docs.qodo.ai/governance/manage-skills-across-repositories Use the Skills page in the Qodo portal to monitor and manage how skills are applied across repositories. Beta Qodo treats skills as first-class inputs for coding agents and code review. A skill is a markdown capsule (a `SKILL.md` file plus optional supporting files) stored directly in the repository. It can encode coding standards, architectural decisions, ownership maps, workflow checklists, or other context that helps agents work with your code. Skills can be applied in two ways: Rules enforcement during pull request review, or Skill steering allowing the skill's instructions to steer the review agent on how to navigate and check the code. Rules enforcement uses rules extracted from a skill to identify violations during review, while Skill steering gives coding agents the skill instructions for code review guidance. The **Skills** page, under **Review standards** in the Qodo portal, lets administrators manage how skills are applied across repositories. You can review skill coverage, control repository scope, switch application methods, activate or deactivate skills, and monitor skill activity. ## Before you begin To use skills, you need: * At least one `SKILL.md` file in one of these repository directories: `.qodo/skills`, `.claude/skills`, `.cursor/skills`, `.agents/skills`, or `skills`. Qodo checks them in that order and uses the first match. * Admin access to the Qodo portal. ## How Qodo discovers skills Qodo discovers new skill files when they're pushed to a repository that has already been imported through **Import rules and skills**. A repository that hasn't been imported yet doesn't get its skills discovered until it is. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). Discovery happens on push, not during pull request review itself, so only skills already discovered are available when a review runs. ## View skills and repository coverage Skills page in portal ### Find and filter skills Use the filter bar to find a specific skill, or filter skills by Status, Category, Source and Scope. This helps you quickly locate skills, understand where they are applied, and review their current application status across repositories. ## View skill coverage and activity For each skill, the following information is available: | Field | Description | | - | - | | **Skill name** | The name of the skill. | | **Date added** | When Qodo first discovered the skill. | | **Category** | Groups skills by categories: Coding standards, Guideline, and Context Retriever. | | **Source** | The repositories where the skill file is stored. | | **Scope** | The repositories where the skill is applied. | | **Applied as** | Indicates how the skill is applied. **Rules enforcement** means the compliance agent checks rules extracted from the skill during pull request review. **Skill steering** means the coding agent reads the skill instructions to steer the review agent on how to navigate and check the code. | | **Triggered** | The number of pull requests in which the skill was executed during review. | | **Detected violations** | The number of violations of this skill identified during pull request reviews. | | **Merged violations** | The number of pull requests merged that still include unresolved rule violations at the time of merge. | This information helps administrators understand which skills are actively contributing to code quality, where they are applied, and how widely they are used across the organization. ## Skill application methods Skills can be applied in two ways: **Rules enforcement** during pull request review, or **Skill steering** allowing the skill's instructions to steer the review agent on how to navigate and check the code. ### Rules enforcement When a skill is applied as Rules enforcement, Qodo extracts rules from the skill and evaluates those rules during pull request review. If the code does not comply with an extracted rule, Qodo can raise a finding and show context explaining why the violation was detected. Use Rules enforcement when you want to: * Enforce specific standards during pull request review. * Trace review findings back to the skill that defined the rule. * Use the skill as a bundle of rules. A skill contains a concentrated collection of standards and invariants that you want your code to comply with. * Atomizing the skill's context into independently verifiable bullet points makes sense. The skill should not affect the review agent's workflow. It should only tell the agent what to look for. ### Skill steering When a skill is applied as Skill steering, the skills agent reads the skill instructions in full and uses them to steer how it navigates and checks the code during pull request review. Use Skill steering when you want to: * Use the skill to control the review agent's workflow. * The instructions in the skill are not independent. They need to be followed in a specific order. * The skill supplies context for the review rather than rules to follow or standards to comply with. ### Switch the skill application method By default, skills are applied as **Rules enforcement**. You can switch a skill between **Rules enforcement** and **Skill steering** at any time. 1. Log in to the Qodo portal and navigate to **Review standards** in the left navigation bar. 2. Click the **Skills** tab. 3. Find the skill you want to update. 4. Under **Applied as rules enforcement**, click **Switch method**. The **Applied as** dialog opens.
Skills switch method
5. Select the application method you want to use. 6. Click **Switch**. The skill is now applied as Skill steering. ## Manage repository assignments You can change the repositories associated with the skill based on your needs. 1. Log in to the Qodo portal and navigate to **Review standards** in the left navigation bar. 2. Click the **Skills** tab. 3. Select a skill in the table.\ The right-side panel opens. 4. Click **Edit**. The Skill details pane opens. Under **Scope**, the repositories associated with the skill are displayed. Edit skill scope, showing Global and Specific repositories radio options with a repository selector 5. Select **Global**, or select **Specific repositories** to add or remove. 6. Click **Save**. This edits the scope for a single skill at a time from the skill's side panel. To edit scope for multiple skills at once, see [Manage skills in bulk](#manage-skills-in-bulk). ## Deactivate a skill Skills are automatically activated once Qodo detects, analyzes, and adds them to the Skills list. To stop a skill from being applied, set its status to **Inactive**. The skill remains available in the Skills list and can be reactivated at any time. 1. Log in to the Qodo portal and navigate to **Review standards** in the left navigation bar. 2. Click the **Skills** tab. 3. Select a skill in the table.\ The left navigation tab opens. 4. Select the **Active** drop-down and select **Inactive**. ## Manage skills in bulk Multiple skills can be activated, deactivated, or rescoped at once from the **Skills** table. Select the checkbox next to each skill, or select the checkbox in the table's top row to select every skill at once. Skills table with multiple rows selected, showing the bulk actions toolbar with Deactivate, Activate, and Define scope options * **Activate** or **Deactivate**: Update the enabled state for all selected skills. * **Define scope**: Set the scope for all selected skills at once. Select **Global** to apply the selected skills organization-wide, or **Specific repositories** to select a total of 25 entities (organizations and repositories), with an optional path pattern for each selected repository. A confirmation dialog appears before the action is applied. Confirm to apply the change to all selected skills. Defining a scope in bulk replaces the current scope on every selected skill. This cannot be undone. ## Understand skill analytics The analytics section at the top of the Skills page provides a high-level view of rule activity and effectiveness during pull request reviews for the selected time period. | Metric | Description | | - | - | | Triggered | The number of times a rule-related skill was executed during a review. | | Detected violations | The number of rule violations identified by Qodo. | | Merged violations | The number of pull requests merged that still include unresolved rule violations at the time of merge. | These metrics help teams understand how frequently rules are applied, measure their effectiveness, and identify opportunities to improve review standards and code quality. A high number of merged violations can indicate that rule violations are reaching the main branch despite being flagged during review. Use this metric to identify which skills are generating the most merged violations and determine whether additional review processes or enforcement measures are needed. ## Related resources * [View skill-related findings](/code-review/view-skill-related-findings): View skill-related findings in your pull request. # Manage pull request bottlenecks with PR Triage Source: https://docs.qodo.ai/governance/pr-triage PR Triage helps teams manage and prioritize open pull requests across their organization, identify review bottlenecks, set their own triage policies, and take action with review and codebase context. Research Preview **Research Preview**: PR Triage is set as Research Preview and is under active development. Functionality and results may evolve as we continue to improve the feature. Research Preview features are not covered by any SLA. We recommend reviewing and validating outputs before use, and advise against relying on them in business-critical workflows. Code review can become a bottleneck when more pull requests are waiting for review than your teams have capacity to handle. Reviewers need to decide what to review first, identify pull requests that are blocking progress, and understand how related changes affect the work ahead. When pull requests are spread across repositories and Git providers, getting a complete view of the review backlog and organizing it for action is difficult. PR Triage in the Qodo portal brings your organization's open pull requests across GitHub, GitLab, Bitbucket, and Azure DevOps into one shared queue. Your triage policies define the signals Qodo uses to prioritize this work, including SLA, priority, and Blast radius. Qodo combines triage signals with review findings, codebase relationships, and your Git organization's policies to help you understand which pull requests need attention and why. Main PR Triage page ## Access PR Triage in the Qodo portal By default, PR Triage is accessible to **Admins only**. You can allow admins and team owners or all members to access PR Triage. ### Set access to PR Triage 1. Log in to the Qodo portal. 2. Navigate to **Account Management > Settings**. 3. Under **Grant PR Triage access**, select the access level: * **Admins only**. * **Admins and team owners**. * **All members**. To open PR Triage, click **PR Triage** from the navigation panel. ## Set your own triage policies Click **Policies** on the main menu bar to configure how the queue decides **priority**, **SLA**, and **Next action**. Git organizations and repositories inherit triage policies from the workspace unless you override a setting. Use the **Workspace**, **Git organization**, and **Repository** tabs to choose where a setting applies. PR Triage Policies PR Triage applies a default triage policy when you first open it, so you can start prioritizing pull requests without configuring anything. Customize the policy to reflect how your organization manages review work, and apply different settings at the workspace, Git organization, or repository level. Select the arrow next to a setting to view and configure its parameters. Set how long a requested review can wait before it is considered stale. | Parameter | Description | | - | - | | **Review SLA** | Set the number of days a requested review can wait before it reaches its SLA. | | **Far overdue: days after the SLA** | Set the number of additional days that can pass after the review SLA before the pull request is considered far overdue. Far overdue is calculated from the end of the review SLA, not from when the review was requested. For example, if the review SLA is 7 days and Far overdue is set to 2 days, the pull request reaches the far overdue level on day 9 after the review was requested. | Define the conditions that determine whether a pull request is **High or Medium priority**. A pull request that does not meet any configured High or Medium priority rule is assigned **Low** priority. **Priority: High** A pull request is assigned High priority when any enabled High priority rule applies. | Parameter | Description | | - | - | | **High-severity findings with a wide blast radius** | The pull request has at least the minimum number of high-severity findings and its measured blast radius meets the selected minimum size. | | **Minimum high-severity findings** | Set how many high-severity findings make this rule apply. | | **Minimum blast radius** | Select the minimum blast radius size required for this rule to apply. Medium reaches another repository rated Critical or High. Large reaches several, or blocks other PRs. Only a measured blast radius counts. | | **Long SLA breach on a severe change** | A requested review that has waited well past the SLA on a pull request that also has a severity signal. | | **Days waiting before High** | Set how many days a review must wait beyond its SLA before this rule applies. | **Priority: Medium** A pull request is assigned Medium priority when it does not meet a High priority rule and any enabled Medium priority trigger applies. | Parameter | Description | | - | - | | **Review overdue** | A requested review is at least one day past its review SLA. | | **High-severity findings** | Qodo found at least the minimum number of high-severity findings. | | **Minimum findings** | Set how many high-severity findings make this trigger apply. | Define when a quiet pull request stops competing for attention. | Parameter | Description | | - | - | | **Inactive after** | Set the number of days without activity before a pull request drops to Low priority and its next action becomes **Consider closing**. | | **Suggest closing after** | Set the number of days without activity before a pull request is flagged as safe to close. | To apply your changes, click **Save policy**. You can select **Restore Qodo defaults** to reset the triage policy to Qodo's default settings. ## Manage review bottlenecks centrally Once your policies are configured, use the shared queue to see open pull requests across your organization and investigate the work that needs attention. ### Find where review work is accumulating Open PR Triage to see your organization's open pull requests in one shared queue. Use the queue to identify pull requests that need attention and filter the list to focus on specific states, review conditions, or types of work. The queue shows the signals that help you prioritize review work: * **Priority:** The priority level assigned according to your organization's triage policies. * **Blast radius:** A measure of how broadly the pull request affects your codebase, showing the repositories reached and any critical repositories involved. * **SLA:** Where the requested review stands against its review deadline. * **Time open:** How long the pull request has been open. * **Next action:** The current state of the pull request and the action needed to move it forward, such as reviewing it, addressing findings, resolving checks, or merging. ### Focus the queue on what matters to you Use **Filter** on the menu bar to narrow the queue to the pull requests you want to review. Filter the queue by: * **Priority:** High, Medium, or Low. * **State:** Needs review, In review, Waiting for author, Blocked by checks, Conflict, Ready to merge, or Inactive. * **Focus On:** By default, **Focus On** is set to you and shows pull requests where you are the author or an assigned reviewer. Select another user to focus on their pull requests. * **Repository**: Shows the pull requests from a specific repository. * **Organization**: Shows pull requests from a specific Git organization. By default, pull requests are grouped by **By PR Stacks**. From the **Groups** menu, select **No grouping** to show pull requests individually. Combine filters to quickly find the pull requests that need attention. For example, set **Focus On** to yourself and **Priority** to **High** to see your highest-priority pull requests. ### Explore PR stacks When related pull requests are part of a PR stack, Qodo shows them together in the queue. * Expand a PR stack to see its related pull requests and understand how the changes are connected. * Select a pull request to investigate it in detail, including its relationships across the codebase. ## Investigate a pull request Select a pull request to open the pull request details pane. The pane gives you the signals and context behind the pull request’s position in the queue, so you can understand why it was prioritized and what may need attention. PR Triage Details Panel The pull request details pane brings together the relevant triage signals, findings, checks, and codebase relationships, with links to the corresponding details so you can investigate further without leaving the context of the pull request. ### Understand why it ranks here The **Priority** card shows the signals used to determine the pull request’s ranking and the source of each signal. Review: * **Blast radius:** How broadly the change reaches across your codebase, including critical or high-impact repositories. * **SLA:** The pull request’s position relative to its review deadline. * **Findings:** Findings that may affect the pull request’s priority, including action-required findings and violations of review standards. * **Effort:** The estimated effort required to address the pull request when available. * **Reviewer:** The reviewer assigned to the pull request if a reviewer was assigned. * **Confidence:** The confidence in the signals used to rank the pull request. The card also shows when the ranking was last updated. ### Review pull request status The **Status** card shows the current review state, assigned reviewers, and review progress. When information from the Git provider is unavailable, the pane indicates which data is unknown, such as merge state, checks, or approvals. ### Review findings and checks The **Findings** card shows open findings identified during review, including their severity and links to the relevant findings. Click **Open all findings for this pull request** to view all findings for the pull request. The **Checks** card shows the current check status. When check results are unavailable, merge readiness is shown as unknown. ### Explore cross-repository relationships The **Cross-repo impact** shows how the pull request’s repository relates to other repositories in your codebase. Use the map to understand which repositories are affected or connected to the change. Hover over a repository or relationship to see more detail. Open the full relationships graph when you need to investigate the complete set of relationships. ### Take action Once you understand the pull request and its context, you can: * Open the pull request in your Git provider. * Assign the work to yourself. * Continue investigating related pull requests in the PR stack. * Open the full relationships graph for deeper analysis. #### Take action Once you understand the bottleneck, continue from the pull request details. You can: * Open the pull request in your Git provider. * Assign the work to yourself. * Continue investigating related pull requests in the PR stack. * Open the full relationships graph for deeper analysis. Refresh the queue to retrieve the latest pull request status, findings, checks, and triage information. ## Capture context for an agent using Copy as prompt Coding agents work from the context you give them. A pull request diff alone may not tell an agent which findings are open, which organizational standards apply, or how the changed code relates to other parts of your codebase. **Copy as prompt** creates a prompt containing relevant Qodo context for a pull request. You can copy this prompt and provide it to a coding agent such as Claude Code, Cursor, or GitHub Copilot. Because Qodo gathers this context independently of the coding agent, you can give different agents the same review findings, standards, and codebase context when working on the pull request. #### What's included The prompt can include: * **Pull request summary:** The pull request title, description, author, target branch, and changed files. * **Open findings:** Issues identified by Qodo's review agents, including their severity, location, and applicable rule. * **Applicable rules:** Organizational standards relevant to the changed code. * **Check status:** Failing or pending repository checks and relevant check information. * **Cross-repository relationships:** Related repositories and components that may be affected by the change. * **PR stack:** Related pull requests and their relationships within the stack. * **Ownership:** Ownership information for affected code. #### When to use it Use the prompt when an agent needs more than the pull request diff to make an informed change. * **Resolve findings before review:** Give an agent the findings that need to be addressed so the author can work through them before review. * **Fix failing checks:** Give the agent relevant check information and codebase context when a pull request is blocked by checks. * **Unblock a stalled pull request:** Give the agent the context it needs to address remaining work when a pull request is approaching or exceeding its SLA. * **Make cross-repository changes safely:** Give the agent relationship context so it can account for affected repositories and components. #### Copy and use the prompt 1. In PR Triage, select a pull request to open its details. 2. Select **Copy as prompt**. 3. Review the generated prompt, if available. 4. Copy the prompt. 5. Paste it into your coding agent and add an instruction describing the change you want the agent to make. # Manage code review across repositories in the Qodo portal Source: https://docs.qodo.ai/governance/repositories Manage Git installations, repository connections, and code review configuration across your organization from the Qodo portal.
GitHub GitLab Bitbucket Cloud Azure DevOps
**Who can view and manage repositories?** * Available on all plans. * All users can view this page. * By default, only organization admins (Enterprise plans) can add, delete, or modify installations, repositories, and relationships; team owners and other members have view-only access. * Organization admins can configure **[Grant edit permissions](/configuration/portal-configuration#account)** in the Qodo portal to extend edit access to team owners or all members. The **Repositories** page provides engineering leads and admins a centralized view of Qodo's coverage across the organization. See every Git installation connected to Qodo, monitor connection health across all repositories, track PR history indexing, turn code review on or off per repository, and manage cross-repo relationships, all without touching configuration files or involving individual developers. To access it, select **Repositories** from the left navigation menu in the Qodo portal. **Installed Qodo before version 2.2.1?** If you connected your Git provider using a method prior to the Qodo installation wizard, your installations and repositories will not appear here. Migrate to the new wizard to manage them from this page. See the [migration guide](/install-qodo/migration-guide) for your Git provider. ## Manage repositories centrally As organizations scale across more teams, more repositories, and multiple Git providers, keeping track of where Qodo is active becomes increasingly difficult. Connections can degrade silently, and teams add new repositories without enabling code review. The Repositories page gives you the visibility and control to stay on top of this: * **Visibility:** See every Git installation and repository Qodo is connected to, across all providers, in one place. Know exactly where Qodo is running and where it isn't. * **Connection health:** Monitor the health of every installation and repository connection. Spot errors before they cause gaps in review coverage. * **PR history indexing:** Track indexing progress of each repository's pull request history, which powers Rule Miner and Relevance. * **Centralized control:** Enable or disable code review per repository without touching repository-level settings, configuration files, or involving the development team. ## Main components of the repository page View and manage every Git installation, add new installations, and resolve connection errors. View and manage individual repositories, connection health, PR history indexing, and code review status. View and audit cross-repository relationships across your organization. # Gain insight with Software Map Source: https://docs.qodo.ai/governance/repositories/gain-insight-with-software-map Explore how your repositories connect, assess change impact, and monitor code review findings with Software Map.
Beta
Software Map gives you a live view of your software system across repositories. Qodo automatically discovers your repositories and maps how they connect, helping you understand your system, assess the potential impact of changes, and identify where code review findings are concentrated. The map updates as pull requests land, so it reflects your system as it changes without requiring you to create or maintain architecture diagrams. For more background on Software Map, see [Introducing the Software Map in Qodo](https://www.qodo.ai/blog/introducing-qodos-software-map/). Software Map showing repositories as an interactive graph with connections and code review findings Use Software Map to: * Understand how repositories connect and identify system hubs. * See the potential impact of changes across downstream repositories. * Follow service contracts to their consumers. * Identify where code review findings are concentrated. * Find repositories with unresolved findings. * Give Qodo's agents system-level context when reviewing changes. ## View the Software Map in the Qodo portal ### Grant access to the Software Map Organization admins can control which role level is required to view the Software Map. The selected role and all higher roles can view the Software Map. 1. In the Qodo Portal, from the left navigation pane go to **Account Management**. 2. Select **Settings** > **Access & permissions** 3. Under **Grant software map access**, select the role that can view the Software Map: * **Admin**: Only organization admins can view the Software Map. * **Team owner**: Organization admins and team owners can view the Software Map. * **Members**: All organization members can view the Software Map. This is the default. If no access level is configured, **Members** is set by default, so all organization members can view the Software Map. ### View the Software Map 1. Log in to the Qodo portal. 2. Select **Repositories** from the left navigation pane. 3. Select the **Relationships** tab. 4. Select the **Graph** tab. ## Understand your software system Software Map shows how your repositories are connected and helps you identify the parts of your system that are central to other repositories. The map shows: * Repository connections through relationships such as Service, Pipeline, and Code. * Highly connected repositories, peripheral repositories, and clusters of related repositories. * Contracts between services and the repositories that consume them. * Downstream dependents that may be affected by a change. * Code review findings across your repository relationships. Software Map works at the repository level, giving you a view of the system at the level where you work. ## Explore the repository relationships Map view displays repositories as an interactive graph. Repositories are sized by connection tier and connected according to their relationship type. Use the layout switcher to change how the graph is arranged: | Layout | Description | | - | - | | Radial | The most connected repositories pull toward the center. | | Grouped | Each cluster of related repositories gets its own area. | | Busiest first | Repositories with the most pull requests carrying findings move to the center, while clusters keep their relationship-based direction. | | Ranked disc | Repositories are evenly spread by pull requests carrying findings, with the busiest repositories at the center. This layout ignores relationships. | Use the canvas controls to: * Zoom in or out. * Select **Fit view** to fit the entire graph to the screen. * Select **Expand to fullscreen** to fill the screen with the graph. ### Narrow the map Use the interactive map to focus on the parts of the system you want to examine. Scope the map to a team, filter to a service, or follow a service contract to its consumers. ## Assess change impact Software Map helps you understand the potential impact of a change before you merge it. View the downstream repositories that depend on a repository and follow service contracts to identify their consumers. This can help you determine the scope of review and testing for changes to shared services or APIs. Qodo derives relationships and contracts from your code and updates the map as pull requests land. This keeps the map aligned with the current state of your system. ## Monitor code review findings To view code review findings on the repository graph, select **Monitor** in the top-right corner of the graph. Monitor view shows findings across related repositories. Use it to identify where findings are concentrated and where unresolved findings are accumulating. Each repository is segmented to show its findings breakdown. The **Findings** panel lets you filter the findings displayed on the graph. ### Filter findings Select a time range to control which findings are included: * Today. * Last 7 days. * Last 30 days. * Last 90 days. Use the following filters: | Control | Options | | - | - | | **Group by** | Severity, Category | | **Severity** | Low, Medium, High. Select any combination. | | **PR state** | Open, Merged, Closed. Select one at a time. | The Findings panel displays matching findings by status, including: * **Shipped unfixed**. * **Dismissed**. * **Fixed before merge**. Counts in the Findings panel represent findings, not repositories. When a findings filter is active, the sidebar also shows how many repositories match the current selection. ## Keep the map current There is nothing to configure or maintain. Qodo automatically discovers your repositories and builds the map. The initial build can take a few hours while Qodo analyzes the system. After the initial build, Qodo re-derives the map as pull requests land, keeping the relationships and contracts aligned with changes in the code. # Manage Git repositories by installation Source: https://docs.qodo.ai/governance/repositories/installations View and manage every Git installation connected to Qodo, add new installations, and resolve connection errors. The **Installations** tab lists all Git integrations connected to Qodo. A Git installation is the fundamental connection unit, representing a single connection that grants Qodo access to a defined set of repositories. Once an installation is complete, Qodo automatically tests the connection to verify both API access and webhook delivery. Installations tab showing installation name, provider, repository count, last connection test time, and last connection state, including a Suspended example ## Installations tab reference | Field | Description | | - | - | | **Installation** | The installation name. | | **Provider** | The Git provider. | | **Repositories** | Number of repositories Qodo has access to under this installation. May update incrementally while the installation is syncing. For more information, see [Connection states](#connection-states). | | **Last connection test** | When Qodo last tested the connection to this installation. | | **Last connection state** | Current connection status. See [Check installation connection status](#check-installation-connection-status) below. | ## Check installation connection status Check connection status to detect a broken installation before it stops Qodo from reaching any of the repositories under it. Connection tests run automatically on a regular schedule, and the last result is displayed for each installation. ### Connection states | Status | Description | | - | - | | **Connected** | Qodo can reach the installation and everything is working as expected. | | **Pending** | Qodo is still setting up this installation, before the initial sync begins. | | **Syncing** | Qodo is running the installation's initial sync. For GitLab and GitHub, the repository count updates as repositories are found. For Bitbucket and Azure DevOps, the count reflects the repositories selected during setup. Once the sync completes, the installation moves to Connected, even if it resolves to zero repositories. | | **Error** | Qodo could not connect to this installation. See [Resolve installation connection errors](#resolve-installation-connection-errors) for details. | | **Suspended** | *(GitHub only)* The GitHub App installation has been suspended and cannot access any resources. Only the party that suspended it can reverse this: the account owner via the GitHub website, or the app manager via the GitHub REST API. See [Suspending a GitHub App installation](https://docs.github.com/en/apps/maintaining-github-apps/suspending-a-github-app-installation) in GitHub Docs. | ## Resolve installation connection errors When an installation shows an Error status, identify the error type below to see what went wrong and who can resolve it. | Error type | Description | Action | | - | - | - | | **Authentication** | Your credentials are no longer valid. | Reconnect or reauthorize the app to resume syncing. | | **Transient** | The Git provider is temporarily unavailable. | Retry the connection later. | | **Permanent** | The Git provider returned a client error. | Check your installation settings and try again. | | **Invalid installation** | There is a configuration issue with your Qodo installation. | Contact your Qodo Account Manager. | | **Internal** | An internal error occurred. | Contact your Qodo Account Manager. | ## Search or filter installations Use the **Search** bar to find a specific installation by name. Use the **Filters** menu to narrow the list by provider, useful when auditing installations across multiple Git providers. ## Add a new installation Connect an additional Git account or organization to expand Qodo's coverage. * Click **New Installation**. This takes you to the [Integrations page](https://app.qodo.ai/integrations), where you can set up a new installation using the guided wizard. ## Manage the repositories in an installation Review which repositories under an installation Qodo can access, and control code review for each one, without leaving the installation's context. * Click the installation row, or select **Manage repos** from its three-dot menu, to open the **Repositories** tab filtered to that installation. For GitHub, Bitbucket, and Azure DevOps installations, this lets you review the repositories Qodo can access and toggle code review per repository. See [Monitor and manage repositories](/governance/repositories/manage-repositories) for details. GitLab differs, see below. For GitLab installations, **Manage repos** opens a **Manage repositories** dialog instead of the **Repositories** tab, where you can edit which repositories Qodo can access. Since Qodo does not store your GitLab personal access token, you re-enter it here to load the installation's groups and repositories. Update your connected repositories step showing the personal access token field Reuse the token created during installation, if it hasn't expired, or generate a new one: * Click **Create a token in GitLab**. * For a GitLab Server installation on GitLab 16.6 or earlier, click **Create a token in GitLab 16.6 or earlier** instead. Required scope: `api`, preselected. Used once, never stored. Short expiry recommended, e.g., 1 day. Paste the token and click **Next** to load the installation's groups and repositories. Repository selection step showing the group tree with Connected labels on already-connected repositories Use the search bar to find a repository by name, or browse the group tree. Already-connected repositories are marked **Connected**. Select or clear a repository or group to add it to or remove it from the installation. Click **Save** to apply your changes, or **Cancel** to discard them. Confirmation step showing "Scope updated" with the count of repositories added and removed Qodo confirms the change with a count of items added and removed, and lists the status of each. Click **Done**. ## Delete an installation Remove an installation entirely when you no longer want Qodo connected to that Git account or organization. * From the three-dot menu, select **Delete installation** to permanently remove it. Qodo displays a confirmation dialog before deleting. Deleting an installation cannot be undone. All repositories connected under that installation will be disconnected from Qodo. For GitLab installations, deleting also removes Qodo's webhooks and bot from the connected GitLab repositories and groups. The confirmation dialog asks for a personal access token to do this. Delete installation dialog showing the personal access token field Generate a token to authorize the removal: * Click **Create a token in GitLab**. * For a GitLab Server installation on GitLab 16.6 or earlier, click **Create a token in GitLab 16.6 or earlier** instead. Paste the token and click **Delete** to confirm. Required scope: `api`. Used once to remove the webhooks and Qodo bot, then discarded. Short expiry recommended, e.g., 1 day. If you are deleting your last Qodo installation from an Azure DevOps organization, deleting it in Qodo is not enough to fully remove Qodo from your organization. You must also manually remove the Qodo service principal user. Go to `https://dev.azure.com/{org_id}/_settings/users` and remove the user from there. Azure DevOps organization settings Users page showing where to remove the Qodo service principal user Deleting a Bitbucket Data Center installation also removes the webhooks Qodo created. Since your administrator credentials are never stored, the confirmation dialog asks for them again to complete the removal. Enter your **administrator username** and **administrator password**, then click **Delete** to confirm. Your credentials are used only for this step and not stored. ## Troubleshoot repository sync Check repository sync progress and fix sync problems from **Background activity** in the top-right corner of the portal. For more information, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). ## Next steps * [Monitor and manage repositories](/governance/repositories/manage-repositories): View and manage individual repositories, connection health, and PR history indexing. * [View cross-repository relationships](/governance/repositories/relationships): View and audit cross-repository relationships across your organization. # Monitor and manage repositories Source: https://docs.qodo.ai/governance/repositories/manage-repositories Monitor each repository's connection health and PR history indexing, both of which affect code review coverage, and control code review status per repository. The **Repositories** tab lists all repositories Qodo has access to, across all your installations and providers. Each repository belongs to a single installation. Repositories tab showing repository name with provider icon, code review toggle, connection health, PR history indexing, and active relationships for each repository ## Repositories tab reference | Field | Description | | - | - | | **Repository** | Repository name and organization, with a provider icon and connection health indicator next to the name. Hover over the name to see its provider and installation. | | **Code review** | Toggle to enable or disable Qodo code review for this repository. When disabled, code review is turned off but indexing continues, keeping the repository available for [cross-repository code review](/governance/cross-repo-code-review). | | **Connection health** | The current connection health for this repository, shown as a status badge and as a status indicator on the repository's provider icon. Hover over a badge for details on its status. See [Connection health](#check-repository-connection-health) below. | | **PR history indexing** | Indexing progress of the repository's merged pull request history, shown as a status badge. This history powers Rule Miner and Relevance. See [PR history indexing](#check-repository-pr-history-indexing-status) below. | | **Active relationships** | Number of active cross-repo relationships defined for this repository. | ## Check repository connection health Check connection health to catch a broken connection before it stops Qodo from reviewing pull requests in that repository. The status is shown both as an indicator on the repository's provider icon and in its own **Connection health** column. | Status | Description | | - | - | | **Healthy** | Events are flowing normally. | | **Degraded** | Delivery is auto-retrying after recent failures. | | **Disabled** | Connection is off. Reconnect the installation. | | **Pending** | Qodo is verifying the connection. Shown for a newly added repository even under an already-healthy installation, until its own connection check completes. | | **Unknown** | Connection health isn't available for this provider yet. | ## Check repository PR history indexing status Qodo indexes a repository's merged pull request history in the background to power learning features such as [Rule Miner](/governance/rule-enforcement/rule-miner) and [Relevance](/code-review/relevance). The **PR history indexing** column is the visibility into that process, showing whether history has finished indexing, is still catching up, or failed. Some statuses also offer a manual action, like starting, retrying, or updating indexing directly from this column. See [Understanding PR history indexing](/core-concepts/pr-history) for how Qodo uses this history once indexed. All users can see the status badge. The **Start indexing**, **Retry**, and **Update** buttons are visible only to organization admins. | Status | Description | Action | | - | - | - | | **Not started** | No indexing run has started yet for this repository. Qodo starts the initial run automatically when the repository connects during installation. | Select **Start indexing** to trigger it right away. Disabled if code review is off for the repository, until it's turned on. | | **Queued** | Indexing is waiting for a free slot in the manual indexing queue, and starts automatically once one is available. | None. | | **Indexing** | The initial indexing run is in progress, including any retry attempts. | None. | | **Active** | At least one full indexing run has completed successfully. Indexed history is available. | Select **Update** to trigger an incremental run immediately, without waiting for new merged pull requests to trigger one automatically. Right after a successful run, **Update** is disabled for a short period; hover over it to see the remaining time. | | **Active, Updating** | An incremental run, triggered by new merged pull requests or by selecting **Update**, is in progress. Previously indexed history remains available. | None. | | **Active, Queued** | An incremental run is waiting for a free slot in the manual indexing queue, and starts automatically once one is available. Previously indexed history remains available. | None. | | **Active\*** | Shown with a warning icon. Indexed history is available, but the most recent incremental run failed. | Select **Update** to retry. Contact [Qodo support](https://help.qodo.ai/hc/en-us/requests/new) if it keeps failing. | | **Failed** | The initial indexing run failed after all retries. | Select **Retry** to try again. Contact [Qodo support](https://help.qodo.ai/hc/en-us/requests/new) if it keeps failing. | Each workspace can have up to 10 manual indexing runs queued or running at once. Selecting **Start indexing**, **Retry**, or **Update** past that limit shows a "Manual indexing queue is full" message instead of queuing the run. Check this status to confirm a repository has enough indexed history for Rule Miner and Relevance to work. If a repository isn't producing results, see [Rule Miner or Relevance isn't producing results](/code-review/troubleshooting/rule-miner-or-relevance-not-producing-results). ## Search or filter repositories Use the **Search** bar to find a specific repository by name. Use the **Filters** menu to narrow the list by installation, provider, connection health, or code review status, useful for auditing coverage, for example to confirm every repository in a newly added installation has code review enabled. ## Enable or disable code review for a single repository When a new installation is added, code review is disabled for all repositories by default. You control which repositories Qodo actively covers. * Toggle **Code review** on or off in the repository's row. The change applies immediately. ## Manage code review in bulk Enable or disable code review for multiple repositories at once from the **Repositories** tab, useful when onboarding several repositories together or rolling out a coverage change without toggling each one individually. Select the checkbox next to each repository, or select the checkbox in the table's top row to select every repository at once. Repositories tab with multiple rows selected, showing the bulk actions bar with Disable code review and Enable code review options Select **Enable code review** or **Disable code review** from the bar that appears at the bottom of the table. The action applies immediately to every selected repository. ## Add or remove cross-repository relationships for a repository Define relationships between related repositories to let Qodo detect breaking changes across them during code review. * Select **Add repositories** from a repository's three-dot menu to open the sidebar, where you can create, edit, or delete relationships. See [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships) for more details. ## Customize configuration for a single repository Apply configuration changes to just one repository instead of your entire organization. * Select **Configuration** from a repository's three-dot menu to open the Configurations page with that repository already selected, applying your changes at the repository level. See [Configure Qodo using the portal](/configuration/portal-configuration#configuration-levels-workspace-git-organization-and-repository) for the available settings. ## View repository information Click any row, or select **Edit repo** from its three-dot menu, to open the sidebar for a closer look at a single repository, with more detail on its indexing, findings, and relationships. The sidebar has four sections: * **Overview:** Enable or disable code review for the repository, and open it directly in your Git provider. * **PR history indexing:** Indexing detail for the repository's pull request history. See [PR history indexing detail](#pr-history-indexing-detail) below. * **Findings:** Summary of findings for the repository. See [Findings](#findings) below. * **Cross repository relationships:** All relationships defined for that repository. See [Cross repository relationships](#cross-repository-relationships) below. ### PR history indexing detail The repository sidebar's **PR history indexing** section shows the same status badge and action button as the Repositories tab, along with more detail once expanded: | Field | Description | | - | - | | **Status** | The current indexing status for this repository. See [PR history indexing](#check-repository-pr-history-indexing-status) above. | | **Last updated** | When this repository's indexing status was last updated. | | **Pull requests** | Number of merged pull requests indexed. | | **Findings learned** | Number of things Rule Miner and Relevance have learned from the indexed pull request history. | | **History covered** | Date range from the first to the most recently indexed merged pull request. | | **What this unlocks** | Which learning features (Rule Miner, Relevance) have enough indexed history to run for this repository. | ### Findings The sidebar's **Findings** section summarizes findings for the repository: * A dropdown scopes the count to one PR state at a time: **Open**, **Merged**, or **Closed**. * A bar chart breaks down the findings. Select **Open in Findings** to go to the [Findings page](/governance/view-all-findings-in-organization) filtered to this repository. ### Cross repository relationships For each relationship, you can see the linked repository, relationship type, description, and status. ## Best practices for managing code review coverage * **Check connection health regularly:** A repository showing an error means Qodo cannot review pull requests in it. Scanning the **Connection health** column as part of your operational review helps catch a broken connection before it causes gaps in coverage. * **Use filters to audit coverage:** Filter by installation, provider, or code review status to verify that all expected repositories are connected and have code review enabled. This is especially useful after adding a new installation. * **Be deliberate about what you enable:** New installations default to code review disabled. Onboard repositories intentionally rather than activating Qodo everywhere at once, so you can track rollout and keep your connection inventory accurate. When code review is disabled, indexing continues so the repository remains available for cross-repo context. ## Next steps * [Manage Git repositories by installation](/governance/repositories/installations): Add installations and resolve connection errors. * [View cross-repository relationships](/governance/repositories/relationships): View and audit cross-repository relationships across your organization. * [Rule Miner](/governance/rule-enforcement/rule-miner): See how PR history indexing turns into rules. * [Relevance](/code-review/relevance): See how PR history indexing helps prioritize findings. # View cross-repository relationships Source: https://docs.qodo.ai/governance/repositories/relationships View and audit cross-repository relationships across your organization from the Relationships tab.
Beta
The **Relationships** tab shows all cross-repo relationships defined across your organization. Use it to audit coverage, check relationship status, and manage connections between repositories. ## Toggle between Table and Graph view The Relationships tab has two views: **Graph**, which opens by default, and **Table**. Switch to Table view to see every relationship listed with full detail, useful for filtering, searching, or acting on a relationship from its three-dot menu. * Toggle between **Table** and **Graph** view using the controls at the top left of the tab. Relationships tab in Table view showing relationship pairs with type, status, description, created, and updated columns, plus Filters and Search controls ## Check relationship status Check relationship status to confirm Qodo has successfully mapped the dependency and will trace impact between the two repositories on future pull requests. | Status | Description | | - | - | | **Pending** | Qodo is analyzing the repositories and building the relationship context. This typically takes a few minutes. | | **Active** | The relationship is confirmed and in use. Qodo checks this relationship on every relevant PR. | | **Not found** | Qodo could not determine a connection between the two repositories. See [Reestablish relationship connections](#reestablish-relationship-connections) below. | | **Error** | Something went wrong during processing. See [Reestablish relationship connections](#reestablish-relationship-connections) below, or remove and recreate the relationship. | Once active, Qodo checks the relationship on every subsequent pull request (PR). See [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships#relationship-statuses) for how Qodo targets which branch or PR to review. ## Search or filter relationships Use the **Search** bar to find relationships by repository name, available in both Table and Graph view. Use the **Filters** menu to narrow the list by **Type**, **Organization**, or **Provider**, available in both Table and Graph view, or by **Status**, available in Table view only. ## Table view Table view lists every relationship in a flat table, with actions available from each relationship's three-dot menu. ### Relationships tab reference | Field | Description | | - | - | | **Relationship** | The two connected repositories. | | **Type** | The kind of dependency between the repositories, for example Pipeline, Code, or Docs. See [Cross-repository code review](/governance/cross-repo-code-review#relationship-types) for the full list. | | **Status** | The current processing status of the relationship. See [Check relationship status](#check-relationship-status) above. | | **Description** | A short summary of the dependency, generated automatically or added manually. | | **Created** | When the relationship was first created. | | **Updated** | When the relationship was last processed or edited. See [Keep relationship information current](/governance/cross-repo-code-review/repository-relationships#keep-relationship-information-current) for how later activity updates this. | To add a new relationship, see [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships). ### Reestablish relationship connections If a relationship shows **Not found** or **Error**, Qodo could not establish the connection on its own. Provide additional context to guide the analysis and retry. Click the three-dot menu on the relationship and select **Retry with custom instructions**. In the **Retry with custom instructions** dialog, describe the dependency between the two repositories. These instructions give the agent additional context to guide the relationship analysis. Click **Retry**. Qodo reprocesses the relationship using your instructions. If it establishes a connection, the status changes to **Active**. ### Remove relationships Remove a relationship when Qodo should no longer trace impact between two repositories. Deleting a relationship means Qodo will no longer use it to trace impact between the two repositories. If you delete a relationship by mistake, you will need to recreate it from scratch. * Click the three-dot menu on the relationship you want to remove, select **Delete relationship**, then confirm in the dialog. ### Export relationship details Each relationship has a markdown file describing the dependency in detail, useful for reviewing what Qodo inferred or sharing context with your team. * Click the three-dot menu on any relationship and select **Download markdown**. ## Graph view Graph view has two modes: **Map**, which opens by default and is useful for exploring how repositories connect, and **Monitor**, for reviewing findings across related repositories. Click any repository to open its sidebar, where you can view its relationships and add new ones. Relationships tab in Map view showing repositories sized by connection tier and connected by relationship type, such as Service, Pipeline, and Code **Repository tiers:** In Graph view, each repository is sized by how many relationships it has: | Tier | Relationships | | - | - | | **Hub** | 8+ | | **Connected** | 3-7 | | **Peripheral** | 1-2 | Select any combination of tiers in the **Repos** legend, or any combination of types in the **Relationship type** legend, to show only matching repositories or connections. For example, select both **Hub** and **Connected** to hide peripheral repositories. See [Gain insight with Software Map](/governance/repositories/gain-insight-with-software-map) to explore the graph, including layout options, and to monitor code review findings across your repository relationships. ## Troubleshoot cross-repo discovery Check cross-repo discovery progress and fix discovery problems from **Background activity** in the top-right corner of the portal. For more information, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). ## Next steps * [Manage Git repositories by installation](/governance/repositories/installations): Add installations and resolve connection errors. * [Monitor and manage repositories](/governance/repositories/manage-repositories): View and manage individual repositories, connection health, and PR history indexing. * [Cross-repository code review](/governance/cross-repo-code-review): Understand how Qodo uses relationships to detect breaking changes across repositories. # Review Standards in code review Source: https://docs.qodo.ai/governance/review-standards Review Standards are how Qodo defines and enforces your organization's engineering standards consistently across code reviews.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Review Standards are how Qodo turns your organization's engineering conventions into something that can actually be enforced: consistently, at scale, and in context. Modern teams rely on a mix of linters, reviewer habits, and tribal knowledge to maintain code quality. Over time, those standards drift. Some live in documentation no one reads, others exist only in the heads of senior engineers. As AI accelerates code creation, these gaps become more visible. Review Standards address this with a central, living system for defining and enforcing how code should be written and reviewed. ## Breakdown of Review Standards Review Standards bring together the ways Qodo captures and enforces how your team writes and reviews code: * **Rules:** explicit, enforceable conventions Qodo checks on every pull request. See [Rule enforcement](/governance/rule-enforcement). * **Skills:** reusable review capabilities you can manage and enforce across repositories. See [Manage skills across repositories](/governance/manage-skills-across-repositories). No rules or skills yet? Import them directly from your existing repositories. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Explore Review Standards See how Qodo builds your Review Standards from your repositories. Define and enforce explicit rules on every pull request. Review and activate rules Qodo surfaces from your code and review history. Monitor and enforce skills across your repositories. In cases where Review Standards are not applicable, Qodo applies its established best practice checks and configured compliance files. See [Rule enforcement without Review Standards](/governance/rule-enforcement/without-rule-system). # Rule enforcement in code review Source: https://docs.qodo.ai/governance/rule-enforcement An overview of how Qodo rules define and enforce your organization's engineering standards consistently across code reviews.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Rules are the explicit, enforceable conventions Qodo checks during code review. Each rule captures a single engineering standard: how code should be written, structured, or reviewed, so Qodo can apply it consistently across every pull request. Rules can be added in three ways: | Method | How it works | | - | - | | **[Manual](/governance/rule-enforcement/generate-and-manage-rules)** | Generate a rule from a natural language description in the portal. | | **[File-based](/governance/rule-enforcement/building-review-standards#supported-file-names-and-types)** | Import from AGENTS.md, CLAUDE.md, and other supported files, automatically on push or manually from the Rules page. | | **[Rule Miner](/governance/rule-enforcement/rule-miner)** | Discover patterns automatically from your organization's pull request history. Generated rules appear in Active Rules or Pending rules depending on your configuration. | In cases where Review Standards are not applicable, Qodo applies its established best practice checks and configured compliance files. See [Rule enforcement without Review Standards](/governance/rule-enforcement/without-rule-system). ## Next steps * [How Qodo builds your Review Standards](/governance/rule-enforcement/building-review-standards): See how Qodo builds your Review Standards from your repositories. * [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules): Create rules manually and manage existing ones. * [Review and activate pending rules](/governance/rule-enforcement/suggested-rules): Review and approve the rules Qodo surfaces before they are enforced. * [Analyze rule performance across pull requests](/governance/rule-enforcement/analytics): Track how often rules are violated and resolved before merge. # Analyze rule performance across pull requests Source: https://docs.qodo.ai/governance/rule-enforcement/analytics Rules analytics provides visibility into how rules are applied across pull requests in the Qodo portal. It helps teams understand rule effectiveness, monitor violations, and track how often issues are resolved before code is merged.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Rule analytics are available at two levels in the Qodo portal. All metrics reflect activity from the last 30 days. ## Aggregated rules analytics Aggregated rules analytics provide a high-level view of how rules are applied across pull requests in the Qodo portal. These analytics reflect rule activity from the last 30 days and are available at the top of the Review Standards page. Aggregated rules analytics showing passed evaluations, detected violations, and merged violations To access aggregated analytics: Open the [**Qodo portal**](https://app.qodost.st.qodo.ai/). Select **Review Standards** from the left navigation. View the analytics summary displayed at the top of the Review Standards page. The metrics are shown as summary cards: * **Passed (no violations)** – The number of evaluations where no rule violations were detected * **Detected violations** – The total number of rule violations identified during pull request reviews * **Merged violations** – The number of PRs that were merged with one or more unresolved rule violations These metrics help teams understand how frequently rules are triggered, how often violations are resolved before merge, and where rule enforcement may need attention. ### Exporting analytics Merged violations analytics can be exported as a CSV file using the **⬇︎ download icon** in the top-right corner of the Review Standards page. The exported file includes merged violations metrics from the last 30 days and can be used to perform offline analysis, share insights with stakeholders, and track trends over time outside the portal. ## Individual rule analytics Individual Rule Analytics provide detailed insights into how a specific rule behaves across pull requests. Individual rule analytics page showing detailed violation statistics and resolution trends To access individual rule analytics: Open the [**Qodo portal**](https://app.qodost.st.qodo.ai/). Select **Review Standards** from the left navigation. Click a rule from the **Rules** tab. This opens the rule’s full definition along with rule-level analytics. Each rule’s analytics show: * How often the rule was found compliant * How often the rule is violated * How frequently violations are merged These insights help teams identify noisy or ineffective rules, understand developer behavior around specific rule types, and decide whether a rule requires tuning, disabling, or stronger enforcement. # Best practices for setting rules Source: https://docs.qodo.ai/governance/rule-enforcement/best-practices-for-setting-rules Best practices for creating clear, impactful, and maintainable code review rules in Qodo.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Effective rules are the foundation of scalable, high-quality code review. The goal isn’t just to enforce standards but mainly to create rules that are clear, measurable, and adaptable as your codebase evolves. This guide outlines best practices for setting rules in Qodo. ## 1. Start with discovery: know what needs a rule Before creating rules, identify patterns and standards that are already effective in your codebase: * Review past pull requests to see recurring good practices. * Look for common mistakes or violations that slow down reviews. * Use Qodo’s suggestions to uncover implicit patterns that should become formal rules. Best Practice: Only create rules for standards that are frequent, actionable, and valuable to your team. Avoid overloading the workflow with unnecessary rules. ## 2. Make rules clear and specific A rule is only effective if it’s understandable and unambiguous: * Define what the rule checks, why it matters, and when it applies. * Include examples of compliant vs. non-compliant code. * Avoid vague phrasing like “code should be clean”. Instead, specify exactly what “clean” means in context. Best Practice: Each rule should have a single, measurable goal so developers know when it passes or fails. ## 3. Prioritize rules by impact Not all rules are equally important. Prioritize rules based on: * **Frequency of violations**: Rules catching repeated mistakes should come first. * **Impact on maintainability**: Enforce rules that prevent bugs or technical debt. * **Team consensus**: Rules that reflect team priorities will see higher adoption. Best Practice: Start with a small set of high-impact rules and expand gradually. ## 4. Implement rules in the workflow Rules only work if they are enforced consistently: * Integrate rules into your PR review workflow using Qodo automation. * Ensure violations are visible to reviewers and authors. * Track resolved and unresolved violations for learning and improvement. Best Practice: Treat rules as checkpoints in your workflow, not optional recommendations. ## 5. Measure and evolve rules over time Rules should not be static. Your codebase and team practices evolve: * Monitor rule adoption, violation trends, and false positives. * Retire or adjust rules that create friction or no longer add value. * Encourage periodic review sessions with your team to refine the ruleset. Best Practice: Make rule evolution part of your regular engineering standards review cycle. ## 6. Document and communicate rules Transparency is key: * Maintain a centralized rule documentation in Qodo or your team wiki. * Explain why rules exist and provide context for exceptions. * Ensure new team members can quickly understand and follow the rules. Best Practice: Clear documentation reduces confusion and increases adoption across the team. ### Summary Setting effective rules in Qodo isn’t just about enforcement. It’s about discovery, clarity, prioritization, implementation, measurement, and evolution. By following these best practices, teams can: * Reduce review friction and prevent recurring mistakes. * Maintain high-quality code consistently. * Build a living rules system that scales with the team. For more on rule implementation and Qodo workflow integration, see [Rule Enforcement in Qodo](/governance/rule-enforcement/generate-and-manage-rules). # How Qodo builds your Review Standards Source: https://docs.qodo.ai/governance/rule-enforcement/building-review-standards Learn how Qodo builds your Review Standards by importing existing standards, enriching rules, and generating rules from pull request history.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Enabled by default for new customers. Existing customers may need to upgrade to the new installation wizard to enable it. See [Enable Review Standards for existing customers](/governance/rule-enforcement/enable-rules-existing-customers). This page explains how Qodo builds the Review Standards for your organization's repositories. As it builds your Review Standards, Qodo helps teams establish a baseline rule set by importing existing standards, enriching them with additional context, and generating rules based on real development activity. ## How Qodo builds your Review Standards Qodo performs the following steps to build the Review Standards. ### Importing rules and skills From the **Rules**, **Pending rules**, or **Skills** tab, click **Import rules and skills** at the top of the page to discover and activate rules and skills from your organization's repositories. Import rules and skills button at the top of the Rules page In the dialog, select one or more Git organizations or individual repositories to scan, or use the search box to find one. Selecting an organization selects all of its repositories. Import rules and skills dialog showing the organization and repository checkbox tree Click **Import** to scan the selected repositories. The button is disabled and shows a loading icon while the import runs. If a repository was already imported, it appears pre-selected in the dialog, and importing it again picks up any changes since the last run. After import: * Rules are extracted from full or partial documents, normalized, and enriched with category, severity, scope, and examples, so they behave the same as rules created directly in the portal. * Imported skills are active immediately in the **Skills** tab. For organizations that started using Qodo since September 30, 2026, imported rules are also active immediately, in the **Rules** tab. Organizations onboarded before that date see imported rules in the **Pending rules** tab for review before activation. * Qodo continues to monitor imported files for changes. See [Automatic rule updates from files](/governance/rule-enforcement/generate-and-manage-rules#automatic-rule-updates-from-files). Track import progress from the **Background activity** panel. If an import needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). ### Supported file names and types * `AGENTS.md` * `CLAUDE.md` * `GEMINI.md` * `copilot-instructions.md` * `best_practices.md` * `RULE.md` * All files in the Skills directories (e.g. `skills//SKILL.md`) * All files in the `.cursor/rules/` directory (including `.cursorrules` and `.mdc` files) * `pr_compliance_checklist.yaml` ### Folder-level scoping in monorepos Rules are automatically scoped to the folder containing the source file, at any depth. For example, rules extracted from `src/payments/AGENTS.md` are only applied to changes made to files under `src/payments/` and any nested subfolders. A file placed at the root of a repository scopes its rules to that repository only, not across the entire organization. You can place supported files at different levels of your repository to control where rules apply, without any additional configuration in the portal. Different folders can have different rules, making it especially useful in monorepos where different services or packages follow their own conventions. The inferred scope is visible on the **Rules** page, where each rule displays the path it was scoped to. ## Rule discovery As part of building your Review Standards, [Rule Miner](/governance/rule-enforcement/rule-miner) analyzes your organization’s pull request history to generate an initial set of rules. * Based on retroactive analysis of recent PRs. * Identifies repeated review patterns and behaviors. * Rules activate automatically by default for organizations that started using Qodo since September 1, 2026. Organizations onboarded before September 1, 2026 see these rules in the **Pending rules** tab by default for review before activation. See [How rules are activated after generation](/governance/rule-enforcement/rule-miner#how-rules-are-activated-after-generation) to change this. ## What to expect once your Review Standards are built Once you import rules and skills from a repository, you'll start to see the following: * Imported rules and skills appear in the **Rules**, **Skills**, or **Pending rules** tab. See [Importing rules and skills](#importing-rules-and-skills) for when each applies. * Active rules are enforced on future pull request reviews. Rule Miner starts analyzing your pull request history after the repository's initial PR history indexing finishes. Indexing starts automatically during installation. Mined rules take longer to appear than imported rules. See [How Rule Miner generates rules over time](/governance/rule-enforcement/rule-miner#how-rule-miner-generates-rules-over-time) for timing details. ## Next steps * [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules): Review what Qodo generated, create rules manually, and manage existing ones. * [Rule Miner](/governance/rule-enforcement/rule-miner): Understand how Qodo continues to generate rules from your pull request history going forward. # Enable Review Standards for existing customers Source: https://docs.qodo.ai/governance/rule-enforcement/enable-rules-existing-customers Existing Bitbucket and Azure DevOps customers enable the Review Standards by migrating to the new Qodo installation wizard. GitHub customers need no action.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Review Standards are available through the new Qodo installation wizard. If you installed Qodo before the wizard was introduced, you enable Review Standards by migrating your existing installation to it. **GitHub:** No action is required. Qodo enables Review Standards for existing GitHub customers automatically. ## Bitbucket and Azure DevOps Existing Bitbucket and Azure DevOps customers who installed Qodo before version 2.2.1 enable Review Standards by migrating to the new installation wizard. Migrating also unlocks findings and other advanced code review features, and adds your installation to the [Repositories page](/governance/repositories). Follow the migration guide for your Git provider: * [Bitbucket: Migrate to the new installation wizard](/install-qodo/bitbucket/migration) * [Azure DevOps: Launch the wizard for advanced code review](/install-qodo/azure-devops/migration) Once migration is complete, Qodo begins building your Review Standards. See [How Qodo builds your Review Standards](/governance/rule-enforcement/building-review-standards) for details on what happens next. # Generate and manage rules Source: https://docs.qodo.ai/governance/rule-enforcement/generate-and-manage-rules This page explains how to generate and manage rules in the Qodo portal, including rule lifecycle operations such as editing, disabling, and deletion.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
**Who can view and manage rules?** * **Admins** can create, edit, enable, approve, and delete rules. * **Members** can generate rules in the portal. However, these rules appear in the **Pending rules** tab and require admin approval before becoming active. Members can also view active rules, pending rules, and review rule outcomes during code reviews. ## View your rules In the Qodo portal, navigate to **Review Standards** from the left menu. Qodo portal Rules page showing the grouped rules table, summary analytics cards, grouping controls, and filter controls The summary cards at the top show rule performance for the last 30 days. See [Analyze rule performance across pull requests](/governance/rule-enforcement/analytics). ## Change how rules are grouped Use the grouping controls above the table to change how rules are organized: | Grouping | What it shows | | - | - | | **Origin repo** | Grouped by where each rule comes from: its repository, then its source file. | | **List** | Every rule in one flat list, with no grouping. | Rules table grouping controls showing Origin repo and List options ## Anatomy of a rule A rule consists of the following fields: | Field | Description | Details | | - | - | - | | **Rule name** | Short, descriptive title summarizing the rule’s intent. | Shown in the table in the **Rules** tab and in code review findings. | | **Rule content** | Enforcement description used during reviews. | Explains what to check and what behavior is expected. | | **Examples** | Compliant and non-compliant code examples. | Displayed to developers when violations occur. | | **Category** | Type of issue the rule addresses. | Security, Correctness, Quality, Reliability, Performance, Testability, Compliance, Accessibility, Observability, Architecture. | | **Severity** | Priority level of a violation. | Error (action required), Warning (recommended), Recommendation (informational). | | **Scope** | Where the rule is enforced. | **Global** by default, applying organization-wide, or limited to specific Git organizations, repositories, and optional path patterns. | | **Source type** | The category of origin: how this rule was created or added. | User, Repository File, Qodo Library, Mined Pattern, Compliance File | | **Source** | The exact location the rule came from. | A file path, URL, or identifier pointing to the original source. For a rule mined from the same pattern across multiple pull requests, shows the pull request count instead, linking to each contributing pull request. | **Rule scope** Scope defines where the rule is enforced. You can narrow the scope to limit enforcement: * **Global** (default): applies the rule to all repositories across all Git organizations. * **Git organization**: applies the rule to selected Git organizations. * **Repository**: applies only to selected repositories. * **Path patterns**: applies to specific directories or files within a repository. Path patterns are optional and can only be added after selecting a repository, and are especially useful for monorepos where different projects or services live under the same repository. Rules extracted from supported files (such as AGENTS.md) are automatically scoped to the folder containing that file, with no additional portal configuration needed. Scope can be edited for a single rule at a time from the rule's side panel (see [Edit rule](#manage-existing-rules)), or for multiple rules at once (see [Manage rules in bulk](#manage-rules-in-bulk)). ## Generate a rule Use this flow to describe a rule in natural language and let Qodo agent generate a structured draft. Generate rule button at the top of the Rules page 1. From **Rules**, click **Generate**. 2. Enter a short description of the rule’s intent. 3. Click **Generate rule**. Example prompts: * "Disallow `console.log` in production builds" * "Avoid SQL string concatenation with user input" Generate rule dialog in Qodo portal with natural language description input field Qodo generates a complete rule draft that can be edited before activation. Before activation, Qodo checks for: * Conflicts * Duplicates * Overlapping scope You can review related rules or revise the draft. Generated rule draft preview showing name, content, and examples ready for review The rule is added to the table in the **Rules** tab and enforced automatically according to its defined scope (repositories and optional path patterns). If you are a member (non-admin), your rule appears in the **Pending rules** tab for admin review before activation, unless an admin has enabled [**Auto-approve user suggestions**](/configuration/context#review-standards). See [Review and activate pending rules](/governance/rule-enforcement/suggested-rules). ## Manage existing rules Management actions for existing rules are available from the **actions menu (⋮)** in the table in the **Rules** tab. These actions are optional and can be performed at any time by admins or team admins. To open the rule behind a specific finding, click the rule link in the finding's Evidence section in the pull request. See [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#unpack-a-code-review-finding). | Action | Description | | - | - | | Edit rule | Update the rule name, content, examples, scope, or severity from the rule's side panel. | | Deactivate or Activate | Pauses enforcement while retaining the rule and its history. | | Delete rule | Permanently removes the rule. This cannot be undone. | ## Manage rules in bulk Multiple rules can be activated, deactivated, or rescoped at once from the **Rules** tab. Select the checkbox next to each rule, or select the checkbox in the table's top row to select every rule at once. Rules table with multiple rows selected, showing the bulk actions toolbar with Deactivate, Activate, and Define scope options * **Activate** or **Deactivate**: Update the enabled state for all selected rules. * **Define scope**: Set the scope for all selected rules at once. Select **Global** to apply the selected rules organization-wide, or **Specific repositories** to select a total of 25 entities (organizations and repositories), with an optional path pattern for each selected repository. See [Rule scope](#anatomy-of-a-rule) for more details on scopes. A confirmation dialog appears before the action is applied. Confirm to apply the change to all selected rules. Define scope for selected rules dialog, showing Global and Specific repositories options with Cancel and Apply buttons Defining a scope in bulk replaces the current scope on every selected rule. This cannot be undone. ## Automatic rule updates from files Qodo continuously monitors files that have already been imported. When changes are merged to one of these files, Qodo processes them and automatically updates the Review Standards to reflect the file's current contents. The scope of extracted rules is automatically determined by the file's location in the repository. If a new supported file is added to a repository after that repository was imported, Qodo doesn't detect it automatically. Re-import the repository from **Import rules and skills** to pick it up. New rules extracted from supported files are: * Added directly as active rules. * Enriched with category, severity, scope, and examples. Only new rules are added this way. Changes to or deletions of existing rules in these files aren't reflected. Manage those directly from the **Rules** tab. **Single-tenant customers** If you installed Qodo before the new setup wizard was introduced, your GitHub App may not have the Push event subscription enabled. Without it, Qodo cannot detect changes to supported rule files. To enable it: 1. Go to your GitHub App settings page. 2. Select **Permissions & events**. 3. Scroll to **Subscribe to events**. 4. Check **Push**. 5. Click **Save changes**. For more details, see [GitHub's documentation](https://docs.github.com/en/apps/maintaining-github-apps/modifying-a-github-app-registration). ## Fetch rules using `get-qodo-rules` skill Supported AI coding agents can access your Review Standards directly using the `get-qodo-rules` skill. The skill fetches repository specific rules from the Qodo platform API, including organization, repository, and path-level rules, and loads them into the agent context. This allows the agent to reference the same rules that are defined in Qodo. This capability is optional and does not replace Qodo’s rule enforcement. It enables agents to use the rules already configured for the repository. Using the skill requires a Qodo API key and rules configured in the Qodo platform. For more information, see: * To set up the Rules Skill, see the [open-source installation instructions](https://github.com/qodo-ai/qodo-skills). * For an overview on Qodo Agent Skills, see [Agent Skills](/agent-skills). ## Troubleshoot rules and skills import Check rules and skills import progress and fix import problems from **Background activity** in the top-right corner of the portal. For more information, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). ## Next steps * [Best practices for setting rules](/governance/rule-enforcement/best-practices-for-setting-rules): Get guidance on writing clear, impactful, and maintainable rules. * [Analyze rule performance across pull requests](/governance/rule-enforcement/analytics): Track how often rules are violated and resolved before merge. # Generate rules from pull request history with Rule Miner Source: https://docs.qodo.ai/governance/rule-enforcement/rule-miner Rule Miner analyzes your organization's pull request history to automatically discover recurring review patterns and generate rules from them.
Beta GitHub GitLab Azure DevOps Multi-tenant Single-tenant
Every engineering team has standards that live outside any document: patterns that senior engineers flag consistently, conventions enforced through repeated review comments, and practices that exist only in reviewer memory. Most of these never make it into formal rules. Rule Miner analyzes your organization's pull request history to surface these patterns automatically and generate rules from them, turning tribal knowledge and informal, repeated feedback into enforceable standards without requiring manual rule creation. ## How Qodo learns from your pull request history Qodo scans pull request discussions across your connected repositories and identifies recurring review patterns: comments that were accepted by developers and led to code changes, recurring behaviors that reviewers consistently flag, and the accept/reject patterns that follow. From these patterns, Qodo generates rules and either activates them directly or adds them to the **Pending rules** tab for approval before activation, depending on your configuration. After the initial analysis, Qodo continues to scan new pull requests at regular intervals, adding new rules as patterns emerge. ### What signals shape the rules Only comments that were accepted by developers and led to code changes are considered. Among those, the following factors determine which patterns become rules: | Signal | How it works | | - | - | | **Reviewer code ownership** | Qodo estimates each reviewer's ownership of the changed code and weights their comments accordingly, so rules reflect the standards of those most familiar with it. | | **Recurring comments** | Feedback that appears repeatedly across pull requests rises into a rule candidate. A single comment can also qualify when it comes from a reviewer with strong ownership of the affected code. | | **Pattern clustering** | Qodo maps where feedback concentrates to produce area-specific rules, scoped to the paths they govern. | | **Rejected suggestions** | Once a rule is active, dismissed suggestions it generates reduce its signal over time, so noise fades on its own. | ## Configure Rule Miner To configure Rule Miner, go to the [portal configuration page](/configuration/context#review-standards), open the **Context** tab, and find the **Review standards** section. Use the repository selector to apply settings to all repositories or a specific one. Rule Miner is enabled by default. For organizations that started using Qodo since September 1, 2026, generated rules activate automatically. For organizations onboarded before that date, generated rules first appear as suggestions in the **Pending rules** tab for review before they are enforced. You can change this behavior using the settings below. The following settings are available: | Setting | Description | | - | - | | **Mine rules from code review history** | Turn Rule Miner on or off for the organization or a specific repository. | | **Auto-approve rule miner suggestions** | Controls what happens to generated rules. See [How rules are activated after generation](#how-rules-are-activated-after-generation) below. | ### How rules are activated after generation | Setting | What happens | When to use | | - | - | - | | **Auto-approve on** (default for organizations that started using Qodo since September 1, 2026) | Generated rules are activated automatically. They are visible in the **Rules** tab on the Review Standards page and are enforced on the next pull request review. | You trust the quality of generated rules and want enforcement without manual review steps. | | **Auto-approve off** (default for organizations onboarded before September 1, 2026) | Generated rules appear in the **Pending rules** tab for review before activation. No rules are enforced until an admin explicitly accepts them. | You want to review generated rules before they affect pull request reviews. | If auto-approve is off, review and activate generated rules from the **Pending rules** tab. See [Pending rules](/governance/rule-enforcement/suggested-rules) for the full flow. ## How Rule Miner generates rules over time Rule Miner is a learning system. The rules it generates reflect your team's actual review behavior, and the output grows more precise as more pull request activity accumulates over time. **On first run:** The first run starts automatically when the repository's initial [PR history indexing](/core-concepts/pr-history) finishes. Rule Miner then analyzes your organization's recent pull request history and generates an initial batch of up to 10 rules per repository, depending on the volume and consistency of your review history. Rules appear in the **Rules** tab on the Review Standards page within a few hours of the first run, with a source type of **Mined Pattern**. Rule Miner draws on an indexed window of up to approximately 1,000 of your repository's most recently merged pull requests, which can include activity from before your repository was connected. This is not your repository's full history, so the size of the first batch depends on how much reviewed, merged activity falls within that indexed window. Rules table on the Review Standards page showing mined rules with the Source type column set to Mined Pattern **On subsequent runs:** Rule Miner continues learning every two weeks, generating up to 5 new rules per repository per run as new patterns emerge from recently merged pull requests. Rules appear in the **Rules** tab or the **Pending rules** tab, depending on your [activation mode](#how-rules-are-activated-after-generation). If your repositories have substantial review history, Rule Miner works through it progressively: established patterns surface first, with rules derived from more recent pull request activity following in later rounds. This means the first few runs may reflect older patterns before newer findings appear, not because recent activity is ignored, but because Rule Miner builds a strong signal base before moving forward. As your team continues reviewing and merging pull requests, the rule set keeps evolving to reflect current standards. Rules that are too similar to existing ones (whether manually created or previously mined) are skipped automatically. ## Understanding rule volume Rule Miner surfaces standards your team has already enforced in code reviews. The number of rules it generates reflects your review activity, not a fixed target. A repository can be perfectly healthy and still produce only a few rules, or none at all. That's normal, and depends on the content and review activity in the repository, not an error. ### Why a repository may produce few or no rules Rule Miner looks for a narrow, high-confidence signal, and each stage filters the available review activity: * The comment must call out a specific code issue or standard. General praise, questions, and minor nitpicks don't count. * The author must have applied the suggested fix for a comment to count as a candidate signal. A comment whose fix was dismissed or ignored doesn't contribute to a new rule, though rejected suggestions from an already-active rule instead reduce that rule's signal over time. * The pattern typically needs to recur, unless it comes from a reviewer with strong ownership of the affected code. See [What signals shape the rules](#what-signals-shape-the-rules). Because each stage narrows the pool, a rule represents a small, high-confidence subset of your team's overall review activity. Repositories with lighter review activity, or where suggestions are rarely applied, may produce few rules or none. ### How to read what you see | What you observe | What it means | | - | - | | A newly connected repository has no rules yet | The first Rule Miner run starts only after the repository's initial PR history indexing finishes. Indexing and analysis take time to complete, and rules may not appear right away, even if the repository has prior review history. Check the repository's [PR history indexing status](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status). | | A repository has had regular merges for a while and still has no rules | The review history likely doesn't contain enough accepted fix suggestions yet. This is common and is not an error. | | Some repositories have rules and others don't | Normal. Repositories with active, constructive reviews produce rules. Lower-activity or newer repositories may not. | | Rules appear gradually over time | Rules reflect your team's review activity as it happens, so they accumulate as your team continues reviewing and merging pull requests. | ### Get more rules Because rules are a by-product of how your team reviews code, more rules come from: * Specific, actionable review comments that identify a concrete issue or standard. * Authors applying suggested fixes instead of resolving threads without making the change. * Consistent review activity so recurring patterns have a chance to emerge. ## View the source pull requests for each rule Each rule includes a link back to the pull request it was generated from. The link appears in the **Source** field in the rules table and in the rule sidebar. When Rule Miner mines the same pattern from more than one pull request, the **Source** field shows the pull request count instead of a single link. Hovering it in the rules table lists each contributing pull request; the rule sidebar lists them under **Mined pattern from \[count] pull requests**. Rule details showing the Source type as Mined Pattern and a Source link to the originating pull request Source links let you: * Verify that a generated rule reflects a real, recurring standard. * Share context with teammates when reviewing or editing a rule. * Understand why a rule was generated before deciding to activate or dismiss it. ## Troubleshoot pull request indexing Check pull request indexing progress and fix indexing problems from **Background activity** in the top-right corner of the portal. For more information, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). ## Next steps * [Pending rules](/governance/rule-enforcement/suggested-rules): Review and activate the rules Rule Miner generates when auto-approve is off. * [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules): Edit, activate, or remove rules after they are generated. * [Rule analytics](/governance/rule-enforcement/analytics): Track how mined rules perform across pull requests over time. * [Rule Miner or Relevance isn't producing results](/code-review/troubleshooting/rule-miner-or-relevance-not-producing-results): Troubleshoot a repository that isn't generating rules. # Review and activate pending rules Source: https://docs.qodo.ai/governance/rule-enforcement/suggested-rules Learn how Qodo surfaces pending rules from your codebase and pull request history, and how to review and activate them.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Suggested rules help you formalize standards that already exist in your codebase and review process. They are not enforced until explicitly reviewed and approved by an admin. Qodo surfaces them as recommendations, giving you visibility into recurring review feedback and best practices, while leaving the decision to review, adjust, and activate each rule in your hands. Pending rules table showing AI-generated rule recommendations awaiting admin approval ## What are pending rules? They appear under the **Pending rules** tab and act as a recommendation layer between informal practices and enforced standards. Suggested rules help teams: * Capture repeated review feedback as formal rules * Align enforcement with real codebase behavior * Reduce reliance on tribal knowledge and reviewer memory ## What you see in the Pending rules table Each suggested rule appears as a pending rule in the **Pending rules** table, along with the key details you need to evaluate it. This information helps you quickly assess context, relevance, and priority before deciding whether to activate the rule. ## Sources of pending rules Suggested rules are generated from your organization’s pull request history in two ways: | Source | How it works | | - | - | | **[Rule Miner](/governance/rule-enforcement/rule-miner)** | Runs automatically on a schedule. Analyzes PR discussions across your repositories and generates suggested rules continuously as new pull requests are merged. | | **[User-created rules](/governance/rule-enforcement/generate-and-manage-rules)** | Users (non-admins) can generate rules in the portal. Their rules appear here for admin review before activation, unless an admin has enabled [Auto-approve user suggestions](/configuration/context#review-standards). | The `/scan_repo_discussions` command has been deprecated and is no longer available. Rule discovery is now handled automatically by [Rule Miner](/governance/rule-enforcement/rule-miner) on a recurring schedule. No manual trigger is required. ## Reviewing and activating pending rules To review suggested rules: Navigate to **Review Standards** > **Pending rules**. Open a pending rule. Review the rule content, examples, and source. Set the scope of the rule. See [Rule scope](/governance/rule-enforcement/generate-and-manage-rules#anatomy-of-a-rule) for the available options. Edit the rule if needed. Click **Accept & activate** or **Dismiss.** They can also be accepted from the **actions menu (⋮)** in the **Pending rules** table. Once accepted, a suggested rule becomes a standard rule and follows the same lifecycle as any other rule. ## Accept or dismiss pending rules in bulk Select the checkbox next to each pending rule in the **Pending rules** table, then choose **Accept & activate** or **Dismiss** to process them all at once. To select every pending rule at once, select the checkbox in the table's top row. When you dismiss pending rules, you must confirm the action in a dialog before it is applied. Pending rules table with multiple rows selected, showing the bulk actions toolbar with Dismiss and Accept & Activate options ## Next steps * [Rule Miner](/governance/rule-enforcement/rule-miner): Understand how suggested rules are generated automatically. * [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules): Create rules manually and manage active rules. # Rule enforcement without Review Standards Source: https://docs.qodo.ai/governance/rule-enforcement/without-rule-system Enforce code quality and organizational standards using repository-based configuration files when Review Standards are not enabled. Qodo enforces code quality and organizational standards even when [Review Standards](/governance/rule-enforcement) are not available or not enabled. In these cases, Qodo uses a repository-based enforcement approach, where standards are defined directly in configuration files within your codebase. Before the introduction of the [Rule System](/governance/rule-enforcement) in version 2.1, this was the primary way teams defined and enforced code review standards. It continues to be used in environments where Review Standards are not applied or where standards are managed at the repository level. ## How enforcement works In this approach, Qodo relies on rule definitions provided through repository files. Supported file names include: * `AGENTS.md` * `CLAUDE.md` * `GEMINI.md` * `copilot-instructions.md` * `RULE.md` * `.cursorrules` * `best_practices.md` * `pr_compliance_checklist.yaml` These files define coding standards, patterns, and requirements such as security checks, ticket validation, and process rules. Qodo uses these files as the source of truth for how code should be reviewed. ## During code review When analyzing a pull request, Qodo: * Scans code changes to identify potential issues such as bugs, logic errors, and anti-patterns * Applies [Best Practices](/governance/rule-enforcement/without-rule-system/best-practices) to check how code is written (patterns, structure, conventions) * Runs [Custom Compliance](/governance/rule-enforcement/without-rule-system/custom-compliance) checks to validate required conditions and policies Suggestions and findings are surfaced directly in the pull request based on these inputs, enabling consistent and customizable code review without requiring centralized rule management. ## Next steps * [Best Practices](/governance/rule-enforcement/without-rule-system/best-practices): Define coding standards and influence code suggestions. * [Custom Compliance](/governance/rule-enforcement/without-rule-system/custom-compliance): Enforce requirements like security checks and validation rules. * [Review Standards](/governance/rule-enforcement): Manage and enforce rules centrally across your organization. # Best practices Source: https://docs.qodo.ai/governance/rule-enforcement/without-rule-system/best-practices Define and enforce coding standards using auto best practices, custom best practices files, and global hierarchical configurations. Best Practices lets Qodo learn from accepted code suggestions and continuously adapt to your team's coding patterns. ## Auto best practices GitHub You must [enable a wiki](/configuration/enable-a-repository-wiki-for-configuration) to use this feature. Auto best practices is a Qodo capability that: 1. Identifies recurring patterns from accepted suggestions. 2. Automatically generates a [best practices page](https://github.com/qodo-ai/pr-agent/wiki/.pr_agent_auto_best_practices) based on what your team consistently values. 3. Applies these learned patterns to future code reviews. This creates an automatic feedback loop where the system continuously learns from your team's choices to provide increasingly relevant suggestions. ### How to enable auto best practices To enable auto best practices, add the following to your [configuration file](/configuration/configuration-file): ```bash theme={null} [auto_best_practices] # Disable all auto best practices usage or generation enable_auto_best_practices = true # Disable usage of auto best practices file in the 'improve' tool utilize_auto_best_practices = true # Extra instructions to the auto best practices generation prompt extra_instructions = "" # Max number of patterns to be detected max_patterns = 5 ``` ## Custom best practices GitHub GitLab Bitbucket Custom best practices allow you to define coding standards specific to your repository. ### Local best practices file Create a `best_practices.md` file in your repository's root directory containing your coding standards and guidelines. Qodo will use this file as a reference during code review. If PR code violates these guidelines, Qodo will generate additional suggestions labeled: `Organization best practice` ### Writing effective best practices files The following guidelines apply to all best practices files: * Write clearly and concisely. * Include brief code examples when helpful (before/after patterns). * Focus on project-specific guidelines that result in relevant suggestions. * Keep files relatively short (under \~800 lines), since: * AI models may not process very long documents effectively. * Long files often include generic guidance already known to AI. * Use a pattern-based structure rather than simple bullet points. ### Example `best_practices.md` #### Error handling You can create a `best_practices.md` file in your repository root with content such as: ```bash theme={null} Add proper error handling with try-except blocks around external function calls. ``` Before: ```bash theme={null} # Some code that might raise an exception return process_pr_data(data) ``` After: ```bash theme={null} try: # Some code that might raise an exception return process_pr_data(data) except Exception as e: logger.exception("Failed to process request", extra={"error": e}) ``` #### Null checks You can create a `best_practices.md` file in your repository root with content such as: ```bash theme={null} Add defensive null/empty checks before accessing object properties. ``` Before: ```python theme={null} def get_pr_code(pr_data): if "changed_code" in pr_data: return pr_data.get("changed_code", "") return "" ``` After: ```python theme={null} def get_pr_code(pr_data): if pr_data is None: return "" if "changed_code" in pr_data: return pr_data.get("changed_code", "") return "" ``` ### Global hierarchical best practices For organizations managing multiple repositories with different requirements, Qodo supports a hierarchical best practices system using a dedicated global configuration repository. #### Set up global hierarchical best practices 1. Create a new repository named `pr-agent-settings` in your organization/workspace. 2. Build the folder hierarchy in your `pr-agent-settings` repository. For example: ```bash theme={null} pr-agent-settings/ ├── metadata.yaml # Maps repos/folders to best practice paths └── codebase_standards/ # Root for all best practice definitions ├── global/ # Global rules, inherited widely │ └── best_practices.md ├── groups/ # For groups of repositories │ ├── frontend_repos/ │ │ └── best_practices.md │ ├── backend_repos/ │ │ └── best_practices.md │ ├── python_repos/ │ │ └── best_practices.md │ ├── cpp_repos/ │ │ └── best_practices.md │ └── ... ├── repo_a/ # For standalone repositories │ └── best_practices.md ├── monorepo-name/ # For monorepo-specific rules │ ├── best_practices.md # Root level monorepo rules │ ├── service-a/ # Subproject best practices │ │ └── best_practices.md │ └── service-b/ # Another subproject │ └── best_practices.md └── ... # More repositories ``` `pr-agent-settings`, `codebase_standards`, `global`, `groups`, `metadata.yaml`, and `best_practices.md` are hardcoded names and must be used exactly as shown. All other names (such as `frontend_repos`, `backend_repos`, `repo_a`, `monorepo-name`, `service-a`, etc.) are examples and should be replaced with your actual repository and service names. * Each folder (including the global folder) can contain a single `best_practices.md` file. * Organize repository best practices by creating subfolders within the `groups` folder. * You can group them by purpose, programming language, or other categories. 3. Define the metadata file `metadata.yaml` that maps your repositories to their relevant best practices paths. For example: ```bash theme={null} # Standalone repos repo_a: best_practices_paths: - "repo_a" # Group-associated repos repo_b: best_practices_paths: - "groups/backend_repos" # Multi-group repos repo_c: best_practices_paths: - "groups/frontend_repos" - "groups/backend_repos" # Monorepo with subprojects monorepo-name: best_practices_paths: - "monorepo-name" monorepo_subprojects: service-a: best_practices_paths: - "monorepo-name/service-a" service-b: best_practices_paths: - "monorepo-name/service-b" ``` 4. Set the following configuration in your global configuration file: ```bash theme={null} [best_practices] enable_global_best_practices = true ``` #### Best practices priority All configured best practices sources are loaded independently and sent to the LLM together. There is no override. If both local and global best practices are configured, the LLM sees both. Sources are combined in the following order: 1. Organization best practices: Global `best_practices.md` from `codebase_standards/global/` in `pr-agent-settings` 2. Organization repository best practices: Repo-mapped files from `metadata.yaml`, or matched subproject paths for monorepos 3. Local repository best practices: Your repository's `best_practices.md`, always included if present, regardless of whether global best practices are configured 4. Wiki best practices 5. Auto-learned best practices The only fallback logic is within the global system: if `metadata.yaml` is missing or cannot be parsed, Qodo falls back to the root-level `best_practices.md` in `pr-agent-settings`. This is a fallback within global, not between global and local. #### Edge cases and behavior * **Missing paths**: If specified paths in `metadata.yaml` don't exist in the file system, those paths are skipped. * **Monorepo subproject matching**: For monorepos, Qodo automatically matches PR file paths against subproject paths to apply relevant best practices. * **Multiple group inheritance**: Repositories can inherit from multiple groups, and all applicable best practices are combined. #### Best practices suggestions label Best practice suggestions are labeled as `Organization best practice` by default. To customize this label: ```bash theme={null} [best_practices] organization_name = "..." ``` The label will become: `{organization_name} best practice` ## How it works #### Exploration phase PR code changes are scanned for potential issues such as bugs, logic flaws, and anti-patterns. #### Tracking accepted suggestions Accepted AI suggestions are tracked in the `.pr_agent_accepted_suggestions` wiki page. #### Learning from patterns Qodo analyzes accepted suggestions and generates a `.pr_agent_auto_best_practices` wiki file with recurring patterns. #### Applying best practices During code review: * Code is checked against learned and defined patterns. * Matching suggestions are labeled as **Learned best practice**. This creates a continuous feedback loop, combining exploratory analysis with pattern-based enforcement. # Custom compliance Source: https://docs.qodo.ai/governance/rule-enforcement/without-rule-system/custom-compliance Define and enforce pull request compliance requirements, such as security checks, ticket validation, and organizational policies, using YAML-based checklists. GitHub GitLab Bitbucket Custom compliance allows you to define and enforce requirements on pull requests, such as security checks, ticket validation, and organizational policies. ## Set up custom compliance Each compliance is defined in a YAML file with the following fields: * `title` (required): A clear, descriptive title that identifies what is being checked. * `compliance_label` (required): Determines whether this compliance generates labels for non-compliance issues (`true` or `false`). * `objective` (required): A detailed description of the goal or purpose of the compliance. * `success_criteria` / `failure_criteria` (at least one required): Define the conditions for compliance. ```bash theme={null} # pr_compliance_checklist.yaml pr_compliances: - title: "Error Handling" compliance_label: true objective: "All external API calls must have proper error handling" success_criteria: "Try-catch blocks around external calls with appropriate logging" failure_criteria: "External API calls without error handling or logging" ... ``` * Avoid overly complex or subjective compliances that are hard to verify. * Keep compliances focused on security, business requirements, and critical standards. * Use clear, actionable language that developers can understand. * Focus on meaningful compliance requirements, not style preferences. For production-ready compliance checklist templates organized by programming languages and technology stacks, check out the [PR Compliance Templates repository](https://github.com/qodo-ai/pr-compliance-templates). ## Local compliance checklists Create a `pr_compliance_checklist.yaml` file in your repository root containing your compliance requirements. Qodo will use this file during code review. If the PR violates these requirements, the results will be surfaced in the code review. ## Global hierarchical compliance For organizations managing multiple repositories with different requirements, Qodo supports a hierarchical compliance system using a dedicated global configuration repository. ### Set up global hierarchical compliance Create a new repository named `pr-agent-settings` in your organization or workspace. Build the folder hierarchy in your `pr-agent-settings` repository. For example: ```bash theme={null} pr-agent-settings/ ├── metadata.yaml # Maps repos/folders to compliance paths └── codebase_standards/ # Root for all compliance definitions ├── global/ # Global compliance, inherited widely │ └── pr_compliance_checklist.yaml ├── groups/ # For groups of repositories │ ├── frontend_repos/ │ │ └── pr_compliance_checklist.yaml │ ├── backend_repos/ │ │ └── pr_compliance_checklist.yaml │ ├── python_repos/ │ │ └── pr_compliance_checklist.yaml │ ├── cpp_repos/ │ │ └── pr_compliance_checklist.yaml │ └── ... ├── repo_a/ # For standalone repositories │ └── pr_compliance_checklist.yaml ├── monorepo-name/ # For monorepo-specific compliance │ ├── pr_compliance_checklist.yaml # Root-level compliance │ ├── service-a/ # Subproject compliance │ │ └── pr_compliance_checklist.yaml │ └── service-b/ # Another subproject │ └── pr_compliance_checklist.yaml └── ... ``` `pr-agent-settings`, `codebase_standards`, `global`, `groups`, `metadata.yaml`, and `pr_compliance_checklist.yaml` must be named exactly as shown. All other names (such as `frontend_repos`, `backend_repos`, etc.) are examples and should be replaced with your actual repository and service names. * Each folder (including the global folder) can contain a single `pr_compliance_checklist.yaml` file. * Organize repository compliance checklists by creating subfolders within the `groups` folder. * Group them by purpose, programming language, or other categories. Define the metadata file `metadata.yaml` in the root of `pr-agent-settings`: ```bash theme={null} # Standalone repos qodo-merge: pr_compliance_checklist_paths: - "qodo-merge" # Group-associated repos repo_b: pr_compliance_checklist_paths: - "groups/backend_repos" # Multi-group repos repo_c: pr_compliance_checklist_paths: - "groups/frontend_repos" - "groups/backend_repos" # Monorepo with subprojects qodo-monorepo: pr_compliance_checklist_paths: - "qodo-monorepo" monorepo_subprojects: frontend: pr_compliance_checklist_paths: - "qodo-monorepo/qodo-github" backend: pr_compliance_checklist_paths: - "qodo-monorepo/qodo-gitlab" ``` Set the following configuration: ```bash theme={null} [pr_compliance] enable_global_pr_compliance = true ``` 1. **Global checklists**: Hierarchical compliance from the `pr-agent-settings` repository. * If the repository is mapped in `metadata.yaml`, it uses the specified paths and the global compliance checklist. * For monorepos, it automatically collects compliance checklists matching PR file paths. * If the repository is not mapped in `metadata.yaml`, global checklists are not loaded. 2. **Local repository checklist**: `pr_compliance_checklist.yaml` file in the repository. * Loaded if present in the repository. * Content is merged with global checklists (if loaded) to create the final compliance checklist. ## Configuration options | Option | Description | | - | - | | `extra_instructions` | Optional extra instructions. For example: "Ensure that all error-handling paths in the code contain appropriate logging statements". Default is empty string. | | `persistent_comment` | If set to true, the compliance comment will be persistent, meaning that every new compliance request will edit the previous one. Default is true. | | `enable_user_defined_compliance_labels` | If set to true, the label `Failed compliance check` will be added for custom compliance violations. Default is true. | | `enable_estimate_effort_to_review` | If set to true, the estimate effort required to review the PR (1–5 scale) is added as a label. Default is true. | | `enable_todo_scan` | If set to true, scans for TODO comments in the PR code. Default is false. | | `enable_update_pr_compliance_checkbox` | If set to true, an update checkbox to refresh compliance status following push events will be added. Default is true. | | `enable_help_text` | If set to true, help text will be displayed in the comment. Default is false. | | Option | Description | | - | - | | `enable_security_compliance` | If set to true, checks for security vulnerabilities. Default is true. | | `enable_compliance_labels_security` | If set to true, a `Possible security concern` label will be added to the PR when security-related concerns are detected. Default is true. | | Option | Description | | - | - | | `enable_ticket_labels` | If set to true, adds ticket compliance labels to the PR. Default is false. | | `enable_no_ticket_labels` | If set to true, adds a label when no ticket is found. Default is false. | | `check_pr_additional_content` | If set to true, checks whether the PR contains content not related to the ticket. Default is false. | ## Use cases ### Blocking PRs based on compliance You can configure CI/CD Actions to prevent merging PRs with specific compliance labels: * `Possible security concern`: Block PRs with potential security issues. * `Failed compliance check`: Block PRs that violate custom compliance checklists. Implement a dedicated [GitHub Action](https://medium.com/sequra-tech/quick-tip-block-pull-request-merge-using-labels-6cc326936221) to enforce these checklists. # Troubleshoot background processes Source: https://docs.qodo.ai/governance/troubleshoot-background-processes Use Background activity to check the status of repository sync, pull request indexing, cross-repo discovery, and rules and skills import, and to fix a process that needs attention. Qodo runs background processes to sync repositories, index pull request history, discover relationships between repositories, and import rules and skills. Use the **Background activity** panel to check process status, understand why a process needs attention, and find the appropriate steps to resolve it. The panel appears in the top-right corner of the portal once processing starts. Use this guide to check whether processes are running as expected and resolve any issues. Background activity panel with a Repository sync row labeled Needs attention, and three finished rows with checkmarks and counts ## What Background activity tracks Each process has its own row in the panel: * **Repository sync**: Syncs each connected repository with Qodo. For more information, see [Manage Git repositories by installation](/governance/repositories/installations). * **Pull request indexing**: Indexes each repository's pull request (PR) history. For more information, see [Monitor and manage repositories](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status). * **Cross-repo discovery**: Finds relationships between your repositories. For more information, see [View cross-repository relationships](/governance/repositories/relationships). * **Rules and skills import**: Imports the rules and skills you select from your repositories. For more information, see [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules). A process appears in the panel only if it applies to at least one repository. ## Troubleshoot a process that needs attention Click **Background activity** to open the panel, then check each row. | What you see | Meaning | What to do | | :- | :- | :- | | and a count, for example 735 imported | The process finished. | Nothing. | | | The process is running. | Nothing. Check again later. | | **Queued** | The process hasn't started yet. | Nothing. Check again later. | | **Needs attention** | Something needs a fix. | Continue to the next step. | | **Failed** | Nothing in the process worked. | Continue to the next step. | | No label, with a description | Something didn't work, but there's nothing for you to fix right now. | Read the description. | When a process needs attention, its row shows a **Needs attention** label, and the **Background activity** button shows a warning icon. The number on the button counts the processes that are running or need attention. When every process has finished, the button shrinks to a checkmark. A row that needs attention includes a short description of the problem and how to fix it, for example: * "payments-service and web-app couldn’t be indexed. Retry indexing in Repositories." * "acme-org and 10 more aren’t syncing. Check their status in Installations." Some rows also show an ⓘ icon. Hover over it to read a note. Notes are informational and require no action from you, for example when Qodo retries a process automatically. If you aren't an admin, the description asks you to contact an admin. Most fixes require admin permissions. Click the row to open the page for that process. When something needs attention, Qodo takes you to the page where the problem appears. | Row | When no action is needed | When something needs attention | | :- | :- | :- | | **Repository sync** | **Repositories**. | **Installations**. When Qodo can identify the installations with a problem, the list is filtered to them. Hover over an installation's status to see what's wrong and how to fix it. | | **Pull request indexing** | **Repositories**, sorted by indexing status. | **Repositories**, filtered to the repositories Qodo couldn't index. | | **Cross-repo discovery** | The **Relationships** table. If no relationships were found, **Repositories**. | The **Relationships** table. | | **Rules and skills import** | The **Rules** page. | The list of repositories that weren't imported, with the reason for each. If you can't edit rules, the **Rules** page. | Follow the description on the row or the item. Common fixes: * **Retry**: Click **Retry** next to the repository or installation. * **Reconnect or complete setup**: Reconnect the installation or complete its setup in Installations. * **Unsuspend**: Unsuspend the Qodo app in your GitHub settings. * **Rescan**: Select the repositories in the import list and rescan them. * **Auto-discover**: Run **Auto-discover** on the repository. For example, if a repository shows **Failed** under PR history indexing in Repositories, click **Retry**. Once indexing completes, the Pull request indexing row in Background activity shows a checkmark. Open Background activity again. When the process finishes, the row shows a checkmark and a count. If the problem persists, contact [Qodo Support](https://www.qodo.ai/contact/). ## Next steps * [Manage Git repositories by installation](/governance/repositories/installations): Check installation status and resolve connection errors. * [Monitor and manage repositories](/governance/repositories/manage-repositories): Check connection health and PR history indexing for each repository. * [View cross-repository relationships](/governance/repositories/relationships): Review the relationships Qodo discovered. * [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules): Review the rules and skills Qodo imported. # Apply REVIEW.md instructions to code review Source: https://docs.qodo.ai/governance/use-review-md Learn how to use REVIEW.md to define repository-specific review guidance that Qodo applies during automated code review, helping review agents prioritize findings, reduce noise, and enforce your team's engineering standards. Research Preview Qodo uses your `REVIEW.md` file to apply repository-specific review guidelines during automated code review. It acts as a repository-level instruction file that influences what the review agents flag, how findings are prioritized, and what feedback is returned on every pull request. ## What is REVIEW\.md? `REVIEW.md` is a file committed at the root of a repository (one per repository) that lets teams define project-specific review guidelines for Qodo's automated code review. It shapes what the review agent flags, how it prioritizes findings, and what findings show up on every pull request. It refines the review process rather than replacing it. Use `REVIEW.md` to define repository-specific review guidance that Qodo's review agents follow during every code review. This guidance refines review output and adjusts review emphasis without affecting coding assistants. Unlike general project documentation, `REVIEW.md` is only used by the code review agents. ## Why use REVIEW\.md? By default, automated reviews are designed to work across a wide range of codebases. However, every codebase is different. `REVIEW.md` helps teams: * Align reviews with internal engineering standards * Avoid irrelevant or low-value comments * Increase the signal-to-noise ratio in pull request feedback * Encode architectural or business rules directly into review behavior * Ensure consistent enforcement across all repositories and reviewers In practice, it turns code review from a generic linting-style system into a team-aware reviewer. ## Enable REVIEW\.md enforcement To enable `REVIEW.md` enforcement for a repository: 1. Log in to the Qodo portal. 2. Navigate to **Configurations** > **Context** > **Review standards**. 3. Enable the **REVIEW\.md instructions** toggle. Once enabled, Qodo will use the repository's `REVIEW.md` file to guide code review findings. ### Set using .pr\_agent.toml ```toml theme={null} [review_agent] enable_review_md = true ``` Default: `false`. ## How it works When a review is triggered: 1. Qodo scans the diff and surrounding code context. 2. The review engine loads `REVIEW.md` from the repository root. 3. All review agents, including issue detection, compliance, skills, specification, and persona analysis, use the repository's `REVIEW.md` instructions when generating findings. 4. Agents analyze the pull request according to those rules. 5. Findings are returned as inline comments and grouped summaries. If `REVIEW.md` is updated, the next pull request review automatically reflects the new rules. ## View REVIEW\.md findings When `REVIEW.md` enforcement is enabled, any violations of rules defined in `REVIEW.md` are surfaced as findings in pull requests. You can view these findings: * As inline comments on the relevant code changes * In the findings panel alongside other code review findings `REVIEW.md` findings are evaluated together with Qodo's standard review checks, helping ensure pull requests comply with your repository-specific review requirements. ## Basic structure of REVIEW\.md `REVIEW.md` is written in plain Markdown and has no required schema. You can organize it using standard Markdown headings and lists. ### Example ```markdown theme={null} # REVIEW.md ## Out of scope Don't raise findings here: `scripts/` (local tooling), `**/*_generated.*`, `tests/fixtures/`. ## Layering & dependency direction Layers are `domain → application → infrastructure`; dependencies point inward only. - `domain/` never imports `infrastructure/` — no DB clients, SDKs, or framework types in business logic. It needs one? That's an interface the outer layer implements. - Framework/vendor types (request objects, ORM entities) stay at the edges; map them at the boundary. ## Extension points ("add one of many") Register-and-wire patterns (handlers, event types, providers). A missed wiring spot degrades **silently**, not with an error. - Mirror every hit: `grep -rn` an existing sibling and match each — registration, routing, serialization, metrics, docs. - The new case honors the same contract as its peers (config, error handling, output shape). ## Abstractions & interfaces Program to interfaces; branching on a concrete type rots the moment a new implementation appears. - Dispatch on capability, **never** on concrete type (`isinstance` / class-name switches). - Advertised ≠ implemented — if an implementation opts out of part of the interface, callers check support and degrade first. ## Trust & data boundaries Validate and authorize where *untrusted data enters*, before it reaches core logic. - Every entry point (API, webhook, queue, imported file) validates shape/range and checks authorization at the boundary. - Authorization is about the *resource*, not just the session — an authenticated caller isn't automatically entitled to this record. - **Fail closed** — on any error or unknown case, deny. ## Cross-service / cross-repo contracts Some changes are only correct if a matching change lands where the diff can't reach. - Shared shapes (API fields, event payloads, schemas) change in lockstep across every producer and consumer — name the counterpart repos. - Roll out compatibly: add before you remove, tolerate both shapes during the transition, then clean up. Shims have a removal plan. ## State, ownership & lifecycle Invariants that span methods and files, so any single hunk looks fine. - **Single source of truth** — derived state isn't cached somewhere it can drift. - Resources (connections, locks, handles) are released on every path, including errors. - Idempotency where delivery isn't exactly-once — retries and replays must not double-apply. ## Reuse before reinvention Duplication passes review because the original is off-screen. - Search shared utilities before adding new parsing/formatting/HTTP logic. - One config key per concept — don't reintroduce a knob under a new name. - Extend the existing helper instead of forking a near-copy. ``` ## Customization areas | Area | Description | Example | | - | - | - | | **Severity mapping** | Define which findings should be treated as critical issues versus minor suggestions. | Security vulnerabilities: **Important**; naming inconsistencies: **Nit** | | **Noise reduction** | Control how much feedback is returned in each review to keep findings actionable. | Limit Nit comments to five per pull request; group similar findings into a summary. | | **File and path exclusions** | Exclude files or directories that should not be reviewed or require reduced scrutiny. | Generated code, lockfiles, vendor dependencies | | **Repository-specific rules** | Enforce engineering standards and requirements unique to your codebase. | Require authentication on new endpoints; require tests for new features | | **Review focus adjustment** | Direct the review system to prioritize specific types of issues. | Focus on security risks, business logic correctness, performance regressions, or architectural consistency | ## Best practices Keep `REVIEW.md`: * **Concise:** Focus on code behavior changes. * **Specific:** Describe what should be flagged. * **Repository-specific:** Avoid guidance already enforced by linters or formatting tools. * **Stable:** Frequent changes can lead to inconsistent review behavior. * **Add separately:** Add `REVIEW.md` in its own pull request rather than adding it to an existing pull request. `REVIEW.md` instructions apply to reviews triggered after the file is added. If you add `REVIEW.md` to an already open pull request, Qodo reviews only the current diff and does not re-review the entire pull request using the new instructions. # Monitor organization-wide pull request findings Source: https://docs.qodo.ai/governance/view-all-findings-in-organization Track and analyze pull request findings across all your repositories from a central location in the Qodo portal.
Beta GitHub GitLab Bitbucket Cloud Azure DevOps
Every time Qodo reviews a pull request, it generates findings: issues identified in the code such as bugs, cross-repo findings, rule violations, and requirement gaps. The Findings page in the Qodo portal tracks these centrally across all your repositories, giving team leads and engineering managers visibility beyond individual reviews. The Findings page displays findings across open, merged, and post-merge pull requests. In the Qodo portal, select **Findings** from the left navigation menu. Findings page showing analytics cards, filters, PR Author column, and the findings table ## Key metrics At the top of the page, Qodo displays aggregated metrics for the last 30 days: * **Total critical findings**: Total number of action-required findings identified across all pull requests. * **Critical findings resolved %**: Percentage of action-required findings that were resolved before merge. * **Average critical findings per PR**: Average number of action-required findings per reviewed pull request. ## How to interpret findings Start with the analytics cards to get a picture of trends over the last 30 days, then use the findings table to drill down by repository, PR, action level, or category. Focus on: * **Findings merged without resolution**, to identify where standards enforcement needs tightening. * **Recurring findings across repositories**, to spot systemic issues that may warrant a new rule or team-wide guidance. * **Resolved critical findings**, to validate that the review process is working as intended. ## Filtering and search Use the filters to narrow findings by PR, Repository, Finding state, action level, category, and type. Use search to find findings from a specific pull request without navigating into the PR directly. ## Findings table The Findings table lists all findings across your repositories. Each row includes: | Column | Description | | - | - | | **Findings** | A short description of the finding. | | **PR** | A link to the pull request where the finding was identified. | | **Repository** | The repository where the finding was identified. | | **State** | Current status of the finding. | | **Action level** | Priority: High, Medium, or Low by default. | | **Category** | Quality dimension: Correctness, Security, Reliability, Performance, Observability, Architecture, Testability, Quality, Accessibility, or Maintainability. | | **Type** | Finding type: Bug, Cross-repo, Rule violation, or Requirement gap. | | **PR author** | The author of the pull request where Qodo identified the finding. | ## Finding states | State | Description | | - | - | | **Pending** | The PR is still open and the finding has not been addressed. | | **Resolved** | The finding was resolved through code changes or a fix prompt. | | **Ignored** | The developer merged the PR without resolving the finding. | | **Dismissed** | The finding was closed without being resolved or fixed, with a reason recorded in the PR chat or the Qodo portal. | | **Outdated** | The finding is no longer relevant because the underlying code changed. | ## Finding details Click any row to open a detail panel showing the full context of that finding: what the issue is, where it appears in the code, and why Qodo flagged it. Each finding is associated with a specific pull request, so you can see whether the issue was resolved before merge. The detail panel includes: * **Full description and code reference**: the exact location in the code where the issue was identified. * **Evidence**: Qodo's reasoning for why this was flagged. If the finding relates to a rule violation, the evidence section links directly to the specific rule in the [Rules page](/governance/rule-enforcement/generate-and-manage-rules). If the finding is a cross-repo conflict, the evidence section links to the repository relationship behind it on the [Relationships](/governance/repositories/relationships) tab. Select **Dismiss** in the detail panel to close a finding without a code change and record why. This is also where a dismissal initiated directly from a PR lands. See [Dismiss a finding](/code-review/dismiss-a-finding). ## View findings by repository If you want to see findings reported across your repositories, useful for spotting where problems are more concentrated, you can use Monitor view on the **Repositories** page. Monitor view shows all finding types grouped by repository, directly on the relationship graph, and lets you filter by severity, category, or PR state. Navigate to **Repositories**, open the **Relationships** tab, and select [**Monitor**](/governance/repositories/relationships#view-code-review-findings-in-monitor-view-alpha) in the top-right corner. ## Best practices * **Start with the big picture**: Check the analytics cards before drilling into individual findings, and filter the table by action level to focus on what matters most. * **Look for patterns, not just volume**: The same finding type appearing across multiple repositories usually signals a systemic gap in team practice rather than an isolated issue. * **Use findings to iterate on your [rules](/governance/rule-enforcement)**: Routinely ignored findings or a rising proportion of findings merged without resolution are a signal that your governance configuration needs adjustment. Refine the rule rather than accepting the noise. ## Next steps * [Anatomy of Qodo findings in a PR](/code-review/comment-anatomy): See how findings appear to developers in individual pull requests. * [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules): Act on recurring findings by creating or refining rules. * [Cross-repository code review](/governance/cross-repo-code-review): Understand how cross-repo findings are generated. * [View cross-repository relationships](/governance/repositories/relationships#view-code-review-findings-in-monitor-view-alpha): See findings by repository directly on the relationship graph, in Monitor view. # Install Qodo on your Git provider Source: https://docs.qodo.ai/install-qodo Set up Qodo for your Git provider and configure it for your organization. Get Qodo reviewing your pull requests in three steps: install on your Git provider, configure for your team, and connect your tools. * Not sure which deployment model or features are available for your Git provider? Check [Deployment models](/install-qodo/deployment-model-support) and [Git provider feature support](/install-qodo/git-provider-feature-support) before getting started. * Deploying on-premises? Deploy Qodo and set up the Git provider integration using the [on-premises documentation](/on-prem) first, then proceed to [Configure code review](/configuration). Install Qodo on your Git provider for the first time using the Qodo installation wizard. Upgrade your existing Qodo installation to unlock the Review Standards, findings, and advanced code review features. ## After installing Qodo Once Qodo is installed or upgraded, configure it for your organization and connect your tools. Set up configuration files, portal settings, and advanced options. Connect Qodo to your ticketing tools including Jira, Linear, and Azure DevOps. # Allowlist Qodo's outbound IP addresses Source: https://docs.qodo.ai/install-qodo/allowlist-qodo-outbound-ip-addresses Allowlist Qodo's outbound IP addresses to allow connections from Qodo to your Git environment. If your Git environment uses an IP allowlist, add Qodo's outbound IP address to allow Qodo to connect to your Git environment. ## Multi-tenant deployments For Qodo multi-tenant deployments, allowlist: ```text theme={null} 35.224.91.187/32 ``` This is Qodo's stable outbound IP address for multi-tenant deployments. ## Single-tenant deployments Single-tenant deployments use a dedicated outbound IP address. The IP address is available after your Qodo environment is provisioned. Contact your Qodo representative or account team to obtain the IP address for your environment. ## How it works Qodo uses these IP addresses for outbound connections to your Git environment. Allowlisting Qodo's outbound IP address lets you restrict access to your self-hosted Git environment. The outbound IP address cannot be used to connect to or access your Qodo environment. # Install Qodo on Azure DevOps Source: https://docs.qodo.ai/install-qodo/azure-devops Install Qodo on Azure DevOps for automated code review. * Available for both single-tenant and multi-tenant Qodo environments. * Not sure which deployment model you need? See [Install Qodo in your Git provider](/install-qodo/install) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). **Already using Qodo on Azure DevOps?** Migrating to the new wizard gives you full access to available Qodo features, better performance and reliability, and ensures your installation appears on the [Repositories page](/governance/repositories). See the [Migration guide](/install-qodo/azure-devops/migration). Qodo works natively with Azure DevOps, using Microsoft Entra ID to authenticate and authorize access to Azure DevOps APIs, pull request workflows, and Azure Boards work items. You can configure Qodo for a single repository or project, or expand it across multiple projects within your Azure DevOps organization. Configuration typically takes around 5–10 minutes. The wizard supports two authentication methods: * **OAuth app registration** (recommended): Best for enterprise environments. Uses Azure AD app registration for automated access. * **Personal access token (PAT)**: Suitable when Azure AD admin access is unavailable. Once installed, Qodo automatically processes pull requests and delivers actionable insights, such as code reviews, descriptions, and improvement suggestions, directly within your Azure DevOps workflow. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * A Qodo environment configured for Azure DevOps (provided by your Qodo Account Manager). Based on your authentication method, you need: * **OAuth**: Azure AD administrator permissions to create app registrations and grant admin consent. Before installing Qodo for Azure DevOps, verify that your organization meets all of the requirements below. Missing any of these prerequisites may cause installation or authorization failures. #### 1. Verify Microsoft Entra ID (Azure AD) permissions Qodo requires authorization through Microsoft Entra ID. The person performing the installation must have one or both of the following roles: * `Global Administrator` (recommended) * `Cloud Application Administrator` **How to check** 1. Open the [Microsoft Entra admin center](https://entra.microsoft.com). 2. Navigate to **Identity > Users > Your User > Assigned Roles**. 3. Verify that one of the required roles is assigned. If the role is missing, contact your Microsoft Entra administrator and request one of the required roles before proceeding. #### 2. Verify Azure DevOps organization permissions The installer must be one of: * `Organization Owner` * `Project Collection Administrator` This role is required only for the user performing the installation. Qodo's own service principal is not granted this role. See [Permissions granted to the Qodo service principal](#permissions-granted-to-the-qodo-service-principal). **How to check** 1. Open Azure DevOps. 2. Go to **Organization Settings > Permissions**. 3. Verify your account belongs to `Project Collection Administrators` or `Organization Owners`. If missing, ask an Azure DevOps administrator to grant the required access. #### 3. Verify application installation permissions Your organization must allow administrators to install Azure DevOps applications. Confirm that you can: * Install marketplace applications * Create service connections * Authorize applications If unsure, ask your Azure DevOps administrator whether marketplace app installation is permitted for your account. #### Permissions granted to the Qodo service principal During installation, Qodo creates a service principal in your Microsoft Entra tenant and adds it to your Azure DevOps organization with the minimum access it needs: | Granted | Purpose | | - | - | | Basic license | Required for any repository access. | | `Project Collection Valid Users` | Authenticated access to the organization. | | `Edit Subscriptions` on Service Hooks, per project | Creating the webhooks that trigger reviews. | The service principal is not added to `Project Collection Administrators`, `Project Collection Service Accounts`, or `Project Collection Build Service Accounts`. `Project Collection Administrator` (or `Organization Owner`) is required only from the user performing the installation, and only to grant the permission above. The service principal never holds it. The permission is granted per project: * **Existing project**: New repositories added to it are covered automatically. * **New project**: No permissions are set yet. Re-run Qodo setup for the organization to grant them, which also covers any projects created since the last run. It requires `Project Administrator` on each project. If the installing user administers only some projects in the organization, installation completes for those and skips the rest. Qodo reports which projects were skipped. Re-running setup as a user with broader access covers the remainder. #### 4. Verify user license availability Qodo requires an Azure DevOps Basic license. 1. In Azure DevOps, go to **Organization Settings > Users**. 2. Verify that at least one `Basic` license is available and that your organization has not reached its user limit. Installation may fail if all Basic licenses are already assigned. #### 5. Verify admin consent policies Your organization may block third-party application authorization. Verify with your Entra administrator that: * Admin consent can be granted for applications * Third-party applications are allowed * No tenant policies block application registration or authorization **Where to check:** In the Microsoft Entra admin center, go to **Identity > Applications > Enterprise Applications > Consent and Permissions**. #### 6. Verify enterprise application restrictions Some organizations use security policies that restrict which applications can be installed. Ask your Entra administrator to confirm: * Qodo applications are allowed by tenant policy * No Conditional Access policy blocks application authorization * No App Governance policy blocks third-party applications #### 7. Verify repository access requirements After installation, Qodo must be able to access Azure DevOps resources. Confirm that the installation account has access to: * Azure DevOps projects * Repositories * Pull requests * Service hooks and webhooks * **PAT**: A personal access token with the required scopes. **Before you begin** * Ensure you are added to the required Azure DevOps organization. * Ensure you have sufficient permissions to create and manage Service Hooks (webhooks), as well as repository and pull request access. **Recommended setup** * To allow access across all projects: Add the PAT user to **Organization Settings > Permissions > Project Collection Administrators**. * To allow access only to specific projects: Add the PAT user to the target project via **Project Settings > Permissions > Project Administrators**, or via **Organization Settings > Users > Manage users**. Project-scoped access is recommended when integration is needed only for selected projects. **Create your personal access token** 1. Go to [Azure DevOps](https://dev.azure.com/). 2. Open **User Settings** in the top-right corner. 3. Select **Personal Access Tokens** from the dropdown. Azure DevOps user settings dropdown showing Personal Access Tokens option 4. Click **New Token**. The **Organization** dropdown controls the token's scope. Selecting a specific organization restricts the token to that organization only. Selecting **All accessible organizations** grants access across all organizations. Azure DevOps Create a new personal access token dialog showing Name field, Organization dropdown with specific organization and All accessible organizations options, and Scopes section with Custom defined selected **Required scopes** PAT scopes alone are not sufficient. The user who creates the PAT must also have project-level permissions (typically **Project Admin**) for webhook creation and PR operations to succeed. | Scope | Access | Purpose | | - | - | - | | Code | Read & Write | Repository and PR access. | | Project and Team | Read & Write | Webhook (Service Hooks) management. | | Pull Request Threads | Read & Write | Commenting on pull requests. | | Wiki | Read & Write | Read, create, and update the project wiki. | ## Access the Azure DevOps integration Log in to your [Qodo portal](https://app.qodo.ai/signin). Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **Azure DevOps**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **Azure DevOps**. ## Install Qodo on Azure DevOps Select the authentication method that fits your environment. OAuth app registration is selected by default. If you are using a personal access token instead, select the **Personal access token (PAT)** tab below. Steps 2 and 3 do not apply. Proceed directly to Step 4. Azure DevOps installation type screen showing OAuth app registration and PAT options This method connects using Azure AD app registration and is best for enterprise security and automated access. **Rules and guidelines** * The Qodo master app is used only for installation and lifecycle management. * Day-to-day Azure DevOps operations use the tenant-specific Qodo-code-review app. * Removing the Qodo master app may prevent reinstall, repair, or uninstall operations. * A Microsoft Entra ID (work or school) account is required. Personal Microsoft accounts are not supported for organizational consent and Azure DevOps app installation. During installation, Qodo will: 1. Use the Qodo master app to securely configure the integration. 2. Create a tenant-specific Azure application named Qodo-code-review. 3. Grant it Azure DevOps access required for PR analysis and webhooks. 4. Store the generated credentials securely for integration management. Click **Continue** to proceed to the manifest review. This method connects using a personal access token and is suitable when Azure AD admin access is unavailable. Enter your personal access token in the field provided. Azure DevOps installation type screen with PAT selected and personal access token input field * **Failed to validate PAT:** the token was copied incomplete. Check that the full token was pasted and try again. Azure DevOps PAT validation showing Failed to validate PAT error * **Invalid Personal Access Token:** the token is expired or revoked. Generate a new token and try again. Azure DevOps PAT validation showing org URL field and Invalid Personal Access Token error If the **Organization URL** field appears, enter your org URL in the format `https://dev.azure.com/{your-organization}`. The field appears in two cases: * **Single-org scoped token**: Your token has limited scope. Enter the URL to proceed. * **Expired or revoked token**: The field appears, but entering the org URL will result in an "Invalid Personal Access Token" error. Regenerate your token and try again. Azure DevOps installation type screen with PAT selected showing Organization URL field Click **Continue** to proceed to repository selection. OAuth only. PAT users: skip to Step 4. Review the application manifest before installation. Azure DevOps review manifest screen showing JSON permissions and scopes The manifest defines the Microsoft Graph permissions Qodo requires: | Permission | Description | | - | - | | `Application.ReadWrite.All` | Allows Qodo to create and manage the webhook app registration, create its service principal, and generate a client secret in the customer's tenant. | | `DelegatedPermissionGrant.ReadWrite.All` | Allows Qodo to grant tenant-wide admin consent for the Azure DevOps delegated permission required by the generated webhook app. | Click **Continue**. OAuth only. PAT users: skip to Step 4. The wizard displays a guide for the two steps that will take place in Microsoft's environment. Review them below, then click **Install** to proceed. Qodo requires temporary Microsoft Graph permissions to: * Create the tenant-specific Qodo-code-review application. * Generate its credentials. * Grant Azure DevOps access required for the integration. * Manage future updates and uninstall operations. An Azure administrator must approve the Qodo master app. The approval process occurs on Microsoft's consent screen and may take up to one minute. Azure DevOps install guide showing Azure Admin step with Microsoft permissions requested preview This step allows Qodo to: * Access repositories selected for code review. * Create and manage webhooks. * Analyze pull requests. * Post review feedback. An Azure DevOps administrator must approve access for the generated Qodo-code-review application. You are redirected to Azure DevOps to complete authorization. This process might take up to a minute. Azure DevOps install guide showing ADO Admin step with Microsoft Pick an account preview * Click **Install** (opens in a new tab) to begin. Use the search bar to find specific repositories, or browse the tree: **Organization > Projects > Repositories**. Azure DevOps connect repositories screen showing org, project, and repository tree with checkboxes This step may take up to a minute to load. Select individual repositories, an entire project, or the full organization. Repositories that already have Qodo installed are not available for selection. To reinstall, remove the existing installation first. Click **Setup** to continue. If you see an error, see [Required OAuth permissions](#required-oauth-permissions). Qodo automatically sets up the required webhooks. Azure DevOps check connection screen showing successful installation confirmation Once complete, a confirmation is displayed. * Click **Sync** to proceed. Qodo is now enabled for the selected repositories. Azure DevOps enable Qodo screen showing connected repositories count and enabled capabilities The confirmation screen shows the number of connected repositories and confirms that AI code review and auto rule generation are active. * Click **Finish installation**. Qodo is now active on the selected repositories. To add repositories, return to this wizard at any time and run a new installation with the updated scope. Repositories that already have Qodo installed are not available for selection. To reduce scope, remove the installation and create a new one. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new pull request in one of the connected repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Next steps * [Repositories page](/governance/repositories): Enable or disable Qodo on individual repositories within your current scope, in the Qodo portal. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Azure DevOps: Launch the wizard for advanced code review Source: https://docs.qodo.ai/install-qodo/azure-devops/migration Migrate your existing Azure DevOps integration to the new Qodo installation wizard for full feature access and better performance and reliability. Launching the wizard gives you access to the Review Standards, findings, and other advanced code review features, improves overall performance and reliability, and ensures your installation appears on the [Repositories page](/governance/repositories). The process involves installing Qodo using the new wizard and then cleaning up your old setup to avoid conflicts. Without migrating, your existing installations will continue to work but you will not have access to advanced features such as rules and findings, and your installation will not appear on the [Repositories page](/governance/repositories). Follow the [installation wizard](/install-qodo/azure-devops) to complete your new Azure DevOps setup. Before removing your old setup, confirm the new installation is active. Open a pull request or use an existing one in any connected repository. Add `/agentic_review` as a comment on the pull request. This runs a full review and can take a few minutes. Confirm the review is triggered from the correct user: * If the installation was created using a Personal Access Token (PAT), the review should appear from the `PAT` user. * If the installation was created using the OAuth app flow, the review should appear from the `Service Principal` user. If two installations are running, you will see two sets of 👀 reactions. Once you see the new installation responding as expected, proceed with the cleanup steps below to remove your old setup. The new installation automatically replaces existing Qodo webhooks when scopes match or expand. Use the table below to understand what happens based on your scope change: | Existing scope | New scope | Result | | :- | :- | :- | | Project | Project | Webhooks are replaced (same scope) | | Repository | Repository (same repos) | Webhooks are replaced (same scope and repo set) | | Repository | Project | Webhooks are replaced (project-level overrides repo-level) | | Project | Repository | Webhooks are not replaced; new webhooks are added alongside existing ones | If you are moving from project scope to repository scope, you may experience: * Duplicate webhook events * Duplicate PR comments * Repeated automation To avoid this, manually remove the old project-level webhooks: Go to Azure DevOps. Open **Project Settings**. Select **Service Hooks**. Remove the old Qodo webhooks. Remove any old Qodo users or service principals that are no longer needed. This keeps your Azure DevOps organization clean and avoids confusion with the new installation. Go to Azure DevOps. Open **Organization Settings**. Select **Users**. Remove any old Qodo users or service principals that are no longer in use. Do not delete the user named `Qodo-code-review` as this belongs to the new installation. Old app registrations from your previous Qodo installation may still remain in Microsoft Entra ID. Removing them keeps your environment tidy, but this step is optional and should only be done if you are confident the app is no longer in use. Go to Microsoft Entra ID. Open **App registrations** or **Enterprise applications**. Identify any old Qodo apps. Remove them only if you are sure they are not part of the new installation. Do not remove an app or user if you are unsure whether it belongs to the new installation. If you are unsure, contact your Qodo Account Manager for guidance. Your Azure DevOps integration is now fully migrated to the new wizard. Qodo is running through the new installation on your selected repositories. ## Next steps * [Repositories page](/governance/repositories): Confirm your new installation appears. * [Configure](/configuration): Configuration files, portal settings, and advanced options for your organization. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install Qodo on Bitbucket Source: https://docs.qodo.ai/install-qodo/bitbucket Multi-tenant and single-tenant Bitbucket Cloud install guides for Qodo automated code review. Existing Qodo installations on Bitbucket Data Center will continue to operate without interruption. Support for new Bitbucket Data Center installations will be introduced soon. Not sure which deployment model you need? See [Install Qodo in your Git provider](/install-qodo/install) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). Install Qodo on Bitbucket Cloud using the built-in installation wizard. Available for both single-tenant and multi-tenant environments. # Install Qodo on Bitbucket Cloud Source: https://docs.qodo.ai/install-qodo/bitbucket/bitbucket-cloud Multi-tenant and single-tenant Bitbucket Cloud install guide for Qodo automated code review. * Supported from Qodo 2.2.1. * Available for both single-tenant and multi-tenant Qodo environments. * Not sure which deployment model you need? See [Install Qodo in your Git provider](/code-review/get-started/installation) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). Qodo works natively with Bitbucket Cloud, using a Qodo Bitbucket account to post code review comments on pull requests. It relies on Bitbucket webhooks and native pull request workflows to deliver automated insights. You can configure Qodo for selected repositories or across your entire Bitbucket workspace. Configuration typically takes around 5 minutes. Once installed, Qodo automatically processes pull requests and delivers actionable insights, such as code reviews, descriptions, and improvement suggestions, directly within your Bitbucket workflow. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * A Qodo environment set up for Bitbucket Cloud. If you're unsure of your environment type, contact your Qodo Account Manager. * System administrator access to your Bitbucket workspace. * A dedicated email address to use for the Qodo Bitbucket account (for example, `qodo@yourcompany.com`). The account is created during the installation wizard. ## Access the Bitbucket integration Log in to your [Qodo portal](https://app.qodo.ai/signin). Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **Bitbucket**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **Bitbucket**. ## Install Qodo on Bitbucket Cloud You must have system administrative access in your Bitbucket workspace to complete the setup. 1. Create a dedicated Qodo email in your company domain (e.g., `qodo@yourcompany.com`) to be used to create a Qodo Bitbucket account. 2. Click **Next** to proceed. Bitbucket installation wizard showing Before you begin step with prerequisites and steps overview Using the email you just created, add Qodo as a user in your Bitbucket workspace. * Click **Download Qodo logo for avatar** and save it for use in sub-step 3. Bitbucket installation wizard showing Add Qodo to Bitbucket step with an embedded reference guide for inviting the user, creating the account, and logging in Complete the following steps in Bitbucket: Go to **Workspace settings → User groups**, open **Add workspace members**, and enter the Qodo email address. Accept the invitation email to create the Qodo Bitbucket account. Log in to Bitbucket using the Qodo account credentials. Back in the wizard, select the **Confirm Bitbucket Qodo account creation** checkbox, then click **Next**. Using the Qodo Bitbucket account you just created, install the Qodo app. Bitbucket installation wizard showing Install Qodo step with workspace admin requirements and a workspace selection list Requirements * The Qodo user must be a Bitbucket workspace admin or repo admin to complete the installation. * The Qodo user must be logged in to your Bitbucket workspace. If Qodo has access to more than one workspace, select the workspace to install Qodo on. * Click **Install Bitbucket App** to proceed. This step is optional. Skip it to keep using the previously authorized Bitbucket account. If a workspace access token is already saved and this field is left empty, it's replaced with the authorized account. If you're using Bitbucket Cloud Premium, you can add a workspace access token instead. It's recommended for workspaces with many repositories: it gives Qodo higher API limits and reduces the chance of Bitbucket rate limiting or blocking requests. Bitbucket installation wizard showing Workspace access token step with optional token and expiry date fields Create a workspace access token in Bitbucket. 1. Sign in as the Qodo user created during installation. 2. Go to **Workspace settings → Security → Access tokens**. 3. Create a token with **Repositories**, **Pull requests**, and **Webhooks** access. See [How to create a workspace access token](https://support.atlassian.com/bitbucket-cloud/docs/create-a-workspace-access-token/). Then, back in the wizard, fill in: * **Workspace access token** (optional): Paste the token you created. * **Expires on** (optional): Add the token's expiry date. Bitbucket doesn't expose this date. Enter it here to get a warning before reviews stop. Qodo can't renew the token automatically. * Click **Continue** to proceed. Select the repositories for Qodo to review. Bitbucket installation wizard showing Select repositories step with workspace and repository tree Use the search bar to find specific repositories, or browse by workspace and project. You can select individual repositories or an entire workspace. * Click **Setup** to continue. You can always add more repositories later by returning to this step. Qodo verifies the connection to each repository selected in the previous step. Bitbucket installation wizard showing Check connection step with per-repository installation success confirmations Each selected repository is listed with its installation status. * Click **Next** to continue. Qodo has been installed on your Bitbucket workspace. Repositories are fully connected and active within a few minutes. Bitbucket installation wizard showing Setup complete screen with enabled repositories confirmation The confirmation screen shows the number of repositories that will be active once the connection is finalized, and confirms that AI code review, auto rule generation, and codebase context are included. * Click **Done** to finish. Qodo is set up for the selected repositories and becomes active once the connection is finalized. To add repositories, return to this wizard at any time and run a new installation with the updated scope. Repositories that already have Qodo installed are not available for selection. To reduce scope, remove the installation and create a new one. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new pull request in one of the connected repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Next steps * [Repositories page](/governance/repositories): Enable or disable Qodo on individual repositories within your current scope. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Bitbucket: Migrate to the new installation wizard Source: https://docs.qodo.ai/install-qodo/bitbucket/migration Migrate your existing Bitbucket installation to the new Qodo installation wizard to access advanced code review features including rules, findings, and improved performance. Launching the wizard gives you access to the Review Standards, findings, and other advanced code review features, improves overall performance and reliability, and ensures your installation appears on the [Repositories page](/governance/repositories). The process involves installing Qodo using the new wizard, verifying it is working, and then removing the old installation to avoid conflicts. Without migrating, your existing installation will continue to work but you will not have access to advanced features such as rules and findings, and your installation will not appear on the [Repositories page](/governance/repositories). Your existing installation covers all repositories in your Bitbucket workspace. Follow the [installation wizard](/install-qodo/bitbucket) in the Qodo portal to complete your new Bitbucket setup, selecting all repositories to match your existing coverage or your desired new scope. Once the wizard is complete, return here to continue. Before removing the old installation, confirm the new one is active. Open a pull request or use an existing one in any connected repository. Add `/agentic_review` as a comment on the pull request. This runs a full review and can take a few minutes. The new installation publishes its response under the name `Qodo`. Once you see a review response from `Qodo`, proceed with removing the old installation. If there is no response, check that the repository is within the scope you selected during installation. If the issue persists, contact your Qodo Account Manager. Go to your Bitbucket workspace. Select the **Settings** cog on the top navigation bar, then select **Workspace settings**. Under **Apps and features**, click **Installed apps**. Find the old Qodo app and click **Remove**. Confirm when prompted. Your Bitbucket installation is now fully migrated to the new wizard. Qodo is now active on all repositories in your Bitbucket workspace via the new installation. ## Next steps * [Repositories page](/governance/repositories): Confirm your new installation appears. * [Configure](/configuration): Set up configuration files, portal settings, and advanced options for your organization. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Qodo deployment models by Git provider Source: https://docs.qodo.ai/install-qodo/deployment-model-support A reference table of supported deployment models for each Git provider, including multi-tenant, single-tenant, on-premises, and air-gapped options. | Platform | Multi-tenant | Single-tenant | On-prem | Air-gapped | | - | - | - | - | - | | GitHub Cloud | ✔ | ✔ | ✔ | N/A | | GitHub Enterprise | ✖ | ✔ | ✔ | ✔ | | GitHub Cloud Enterprise | ✔ | ✔ | ✔ | N/A | | GitLab Cloud | ✔ | ✔ | ✔ | N/A | | GitLab Self-Managed | ✔ | ✔ | ✔ | ✔ | | Bitbucket Cloud | ✔ | ✔ | ✔ | N/A | | Bitbucket Data Center | ✖ | ✖ | ✔ | ✔ | | Azure DevOps Cloud | ✔ | ✔ | ✖ | N/A | | Gerrit | ✔ | ✔ | ✔ | ✔ | # Install Qodo on Gerrit Source: https://docs.qodo.ai/install-qodo/gerrit Install guide for Qodo automated code review on Gerrit, using the guided installation wizard. This wizard can be used for Qodo multi-tenant, single-tenant, and on-premises deployments. Gerrit is a self-hosted, web-based code review tool for Git repositories where review is organized around changes (individual patch sets) rather than pull requests, and repositories are called projects. This guide helps you connect Qodo to your Gerrit instance so it can review changes and deliver findings directly where you already work. Assuming your Qodo environment is already set up, connecting Gerrit involves creating a dedicated Qodo user in Gerrit, connecting it to Qodo, and registering a webhook so Gerrit can notify Qodo of new changes. ## Prerequisites Before you begin, ensure you have: * A Qodo environment configured for Gerrit. If you're unsure of your environment type, contact your Qodo Account Manager. * A Gerrit instance where you have administrator access, to create a dedicated user, grant it permissions, and register a webhook. ## Access the Gerrit integration Log in to your Qodo portal. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **Gerrit**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **Gerrit**. ## Install Qodo on Gerrit Gerrit wizard step 1, Create a Qodo user, showing required ref and label permission tables In your Gerrit server, create a new user named `Qodo`. This user will be used to post review comments on Qodo’s behalf in the Gerrit UI. Grant the user the following permissions: | Ref pattern | Purpose | | - | - | | `refs/changes/*` | Access patchset commits for code review and analysis | | `refs/heads/*` | Read branch content, including the `.pr_agent.toml` configuration file | | `refs/tags/*` | Read tags for version context in PR descriptions | | Label | Range | Purpose | | - | - | - | | **Code-Review** | -2..+2 | Post review comments and findings | | **Verified** | -1..+1 | Mark verification status (optional) | | Access category | Ref pattern | Purpose | | - | - | - | | **Edit Hashtags** | `refs/heads/*` | Apply hashtags with `/generate_labels` | Generate an HTTP password for the user. You'll enter its username and password in the next step. Back in the wizard, click **Continue**. Gerrit wizard step 2, Connect to Gerrit, showing Gerrit URL, username, HTTP token, and API path fields Enter the following, then click **Connect to Gerrit**: * **Gerrit URL**: Your Gerrit instance URL (for example, `https://gerrit.example.com`). * **Username**: The dedicated Gerrit user created in the previous step. * **HTTP token**: The user's HTTP password. * **API path** (optional): Path to Gerrit's authenticated REST API. If your Gerrit instance is served under a sub-path, add that to the Gerrit URL above instead of this field. Qodo validates the credentials against your Gerrit server, then stores them securely, not in the Qodo portal itself. Gerrit wizard step 3, Import repositories, showing the repositories-added confirmation and webhook setup commands Qodo imports every Gerrit project the connected user can access. Then, register a webhook on your Gerrit server so Qodo receives change events: Copy the **Webhook URL** shown in the wizard. Run the following command against your Gerrit server, replacing the URL and credentials with your own: ```bash theme={null} curl --location --request PUT \ '/a/config/server/webhooks~projects/All-Projects/remotes/qodo' \ --header 'Content-Type: application/json; charset=UTF-8' \ --user ':' \ --data-raw '{"url":"","events":["patchset-created","comment-added","wip-state-changed","change-merged","change-abandoned"],"maxTries":"3","sslVerify":"true"}' ``` This targets **All-Projects**, Gerrit's global config project. Webhook configuration [is inheritable](https://gerrit.googlesource.com/plugins/webhooks/+doc/master/src/main/resources/Documentation/config.md): it applies to every repository, without requiring per-project configuration. To scope the webhook to specific repositories, replace `All-Projects` in the URL with a repository's name and repeat this for each repository to include. Verify it was created: ```bash theme={null} curl --user ':' '/a/config/server/webhooks~projects/All-Projects/remotes' ``` Replace `All-Projects` with a specific repository name if that's what you registered the webhook against. Back in the wizard, click **Done**. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new change in one of the connected projects and confirm that Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or change summary directly on the change. ## Troubleshooting If Qodo is not responding: * Confirm the webhook is registered on the project you expect (`All-Projects`, or a specific repository). See [Install Qodo on Gerrit](#install-qodo-on-gerrit) for the verify command. * Confirm the HTTP credential used hasn't expired. ## Manage repositories Every Gerrit project the connected user can access is imported when you connect (see [Install Qodo on Gerrit](#install-qodo-on-gerrit)), but only projects covered by the webhook actually receive change events. * To cover only specific projects, register the webhook against those projects by name instead of `All-Projects`. * To turn code review on or off for a project already covered by the webhook, without touching the webhook itself, use the **Code review** toggle on the [Repositories page](/governance/repositories) in the Qodo portal. ## Next steps * [Using Qodo in code reviews](/code-review/use-qodo-in-prs): Get the most out of Qodo. * [Install and configure Qodo](/configuration): Use the shared configuration guides to configure Qodo for your organization. # Git provider feature support Source: https://docs.qodo.ai/install-qodo/git-provider-feature-support A reference table of supported configuration options and commands by Git provider in Qodo 2.x. Qodo configuration options and commands vary by Git provider. Use the tables below to check what is supported for your provider. Qodo strives for feature parity across all providers, but a number of settings are limited by each provider's capabilities. GitHub, GitLab, and Azure DevOps support extended markdown; Bitbucket Cloud and Bitbucket Data Center support standard markdown only, which is why they do not support all features. ## Configuration options Configuration is managed in the repository's [`.pr_agent.toml`](/configuration/configuration-file) file or in the [Qodo portal](/configuration/portal-configuration). For a full description of each setting, see the [Configuration and command reference](/configuration/configuration-and-command-reference). ### Review output and visibility | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`comments_location_policy`](/code-review/feedback-location) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`inline_comments_severity_threshold`](/code-review/severity-thresholds) | ✔ | ✔ | ✖ | ✖ | ✔ | ### Findings display | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`finding_overflow_count`](/code-review/findings-visibility) | ✔ | ✔ | ✖ | ✔ | ✖ | ### Resolved findings | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`show_resolved_findings`](/code-review/track-resolved-findings) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`resolved_findings_placement`](/code-review/track-resolved-findings#placement) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`resolved_overflow_count`](/code-review/track-resolved-findings#resolved-findings-overflow) | ✔ | ✔ | ✔ | ✔ | ✔ | Bitbucket and Gerrit do not support collapsible sections. As a result, resolved findings beyond the overflow breakpoint are not displayed. You can view them in the Qodo portal instead. ### Expanded sections in findings | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`expand_description`](/code-review/findings-visibility) | ✔ | ✔ | ✖ | ✔ | ✖ | | [`expand_code`](/code-review/findings-visibility) | ✔ | ✔ | ✖ | ✔ | ✖ | | [`expand_recommendation`](/code-review/findings-visibility) | ✔ | ✔ | ✖ | ✔ | ✖ | | [`expand_evidence`](/code-review/findings-visibility) | ✔ | ✔ | ✖ | ✔ | ✖ | | [`expand_prompt`](/code-review/findings-visibility) | ✔ | ✔ | ✖ | ✔ | ✖ | ### Show content section titles | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`show_subsection_names`](/code-review/findings-visibility#show-content-section-titles) | ✖ | ✖ | ✔ | ✖ | ✔ | ### Inline comment sections | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`inline_render_description`](/code-review/findings-visibility#inline-comment-sections) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`inline_render_code`](/code-review/findings-visibility#inline-comment-sections) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`inline_render_recommendation`](/code-review/findings-visibility#inline-comment-sections) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`inline_render_evidence`](/code-review/findings-visibility#inline-comment-sections) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`inline_render_prompt`](/code-review/findings-visibility#inline-comment-sections) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`link_findings_to_inline_comments`](/code-review/findings-visibility#link-finding-summary-to-inline-findings) | ✖ | ✖ | ✔ | ✖ | ✔ | ### Review workflow | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`pr_commands`](/configuration/configuration-and-command-reference) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`feedback_on_draft_pr`](/configuration/configuration-and-command-reference) | ✔ | ✔ | ✖ | ✔ | ✖ | | [`handle_push_trigger`](/code-review/persistent-review-comments) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`push_commands`](/code-review/persistent-review-comments) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`demand_self_review`](/code-review/self-review) | ✔ | ✖ | ✖ | ✖ | ✖ | | [`approve_pr_on_self_review`](/code-review/self-review) | ✔ | ✖ | ✖ | ✖ | ✖ | | [`enable_chat_in_code_suggestions`](/code-review/auto-detected-questions) | ✔ | ✔ | ✖ | ✖ | ✖ | Gerrit [work-in-progress changes](https://gerrit-review.googlesource.com/Documentation/intro-user.html#work-in-progress-changes) are treated as drafts. Qodo skips new patch sets while a change is work in progress, so `feedback_on_draft_pr` cannot enable automatic feedback for them. ### CI feedback | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`enable_auto_checks_feedback`](/code-review/enable-ci-failure-feedback) | ✔ | ✖ | ✖ | ✖ | N/A | | [`excluded_checks_list`](/code-review/enable-ci-failure-feedback) | ✔ | ✖ | ✖ | ✖ | N/A | | [`persistent_comment`](/code-review/enable-ci-failure-feedback) | ✔ | ✖ | ✖ | ✖ | N/A | | [`enable_help_text`](/code-review/enable-ci-failure-feedback) | ✔ | ✖ | ✖ | ✖ | N/A | | [`final_update_message`](/code-review/enable-ci-failure-feedback) | ✔ | ✖ | ✖ | ✖ | N/A | ### Ignore rules | Setting | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`ignore_pr_title`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`ignore_pr_source_branches`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | N/A | | [`ignore_pr_target_branches`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`ignore_pr_labels`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`ignore_pr_authors`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`ignore_repositories`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`allow_only_specific_folders`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✖ | | [`ignore_language_framework`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✖ | | [`ignore_ticket_labels`](/code-review/ignore-content-from-analysis) | ✔ | ✔ | ✔ | ✔ | ✔ | Gerrit changes do not have a source branch separate from the change ref. Gerrit [hashtags](https://gerrit-review.googlesource.com/Documentation/intro-user.html#hashtags) are used as labels for `ignore_pr_labels`. ## Comment commands You can trigger these commands in Pull Request (PR) comments or Gerrit change comments. | Command | GitHub | GitLab | Bitbucket | Azure DevOps | Gerrit | | :- | :- | :- | :- | :- | :- | | [`/agentic_review`](/code-review/use-qodo-in-prs/code-review) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`/agentic_describe`](/code-review/pr-summary) | ✔ | ✔ | ✔ | ✔ | ✔ | | [`/ask`](/code-review/ask-questions-with-ask) | ✔ | ✔ | ✔ | ✔ | ✔ | | ⮑ Ask on code lines | ✔ | ✔ | ✖ | ✖ | ✖ | | [`/generate_labels`](/code-review/generate-pr-labels) | ✔ | ✔ | ✖ | ✖ | ✔ | | [`/checks`](/code-review/enable-ci-failure-feedback) | ✔ | ✖ | ✖ | ✖ | N/A | On Gerrit, `/generate_labels` applies [hashtags](https://gerrit-review.googlesource.com/Documentation/intro-user.html#hashtags) to the change. # Install Qodo on GitHub Source: https://docs.qodo.ai/install-qodo/github Multi-tenant, single-tenant, and on-premises GitHub install guides for Qodo automated code review. Qodo integrates directly with GitHub Cloud and GitHub Enterprise Server, supporting multi-tenant, single-tenant, and on-premises deployments. Not sure which deployment model you need? See [Install Qodo in your Git provider](/install-qodo/install) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). Select your setup to get started: The fastest way to get started on GitHub Cloud. Ideal for most teams. For organizations needing a dedicated Qodo environment. Supports GitHub Cloud and GitHub Enterprise Server. For self-hosted GitHub Enterprise Server deployments. # Install Qodo on GitHub Enterprise Server Source: https://docs.qodo.ai/install-qodo/github/github-enterprise Qodo on-premises installation guide for GitHub Enterprise Server. * Not sure which deployment model you need? See [Install Qodo in your Git provider](/code-review/get-started/installation) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). * GitHub Enterprise Server requires a **Qodo on-premises** deployment. To enable the Git integration, [contact the Qodo team.](https://www.qodo.ai/contact/#pricing) This guide walks you through setting up Qodo on GitHub Enterprise Server. ## Prerequisites Before you begin, ensure you have: * A Qodo on-premises deployment. * GitHub organization admin access. ## Set up Qodo on GitHub Enterprise Server Follow the [on-premises setup instructions](/on-prem/git-integration/setup-the-git-integration) to configure your Qodo environment. Add the `GITHUB.BASE_URL` environment variable with the API URL of your GitHub server to your workflow file. If your GitHub Enterprise Server is hosted at `https://github.mycompany.com`: ```yaml theme={null} env: # ... previous environment values GITHUB.BASE_URL: "https://github.mycompany.com/api/v3" ``` ## Next steps [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # GitHub: Migrate to the new installation wizard Source: https://docs.qodo.ai/install-qodo/github/migration Migrate your existing GitHub installation to the new Qodo installation wizard to access advanced code review features including rules, findings, and improved performance. To migrate your GitHub installation, remove your existing app before installing the new wizard. This ensures your repositories are correctly linked to the new installation in the database. Without migrating, your existing installation will continue to work but you will not have access to advanced features such as rules and findings, and will not be visible on the [Repositories page](/administration/repositories). **Multi-tenant deployments with the Review Standards already enabled:** No action needed. Your existing installation continues to work as usual. Check which repositories your current installation covers so you can replicate the same scope in the new setup. Go to your GitHub organization page. Navigate to **Settings**, then under **Third-party Access**, click **GitHub Apps**. Find your existing Qodo app and click **Configure**. Under **Repository access**, note whether the app is set to **All repositories** or **Only select repositories**. If **Only select repositories** is selected, note which repositories are listed before proceeding. Go to your GitHub organization page. Navigate to **Settings**, then under **Third-party Access**, click **GitHub Apps**. Find the old Qodo app and click **Configure**. Scroll to the bottom of the page to the **Danger zone** section. Click **Uninstall** and confirm when prompted. Follow the [installation wizard](/install-qodo/github) in the Qodo portal to complete your new GitHub setup, selecting the same repository scope you noted above. Once the wizard is complete, return here to continue. Confirm the new installation is active. Open a pull request or use an existing one in any connected repository. Add `/agentic_review` as a comment on the pull request. This runs a full review and can take a few minutes. Confirm Qodo responds with a review. If there is no response, check that the repository is within the scope you selected during installation. If the issue persists, contact your Qodo Account Manager. Your GitHub installation is now fully migrated to the new wizard. Qodo is now active on your selected repositories. ## Next steps * [Repositories page](/administration/repositories): Confirm your new installation appears. * [Configure](/configuration): Set up configuration files, portal settings, and advanced options for your organization. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install Qodo on GitHub Cloud - Multi-tenant Source: https://docs.qodo.ai/install-qodo/github/qodo-multi-tenant Multi-tenant GitHub Cloud install guide for Qodo automated code review. Using GitHub Enterprise Server? The installation flow is the same as Qodo single-tenant. See [Qodo single-tenant](/install-qodo/github/qodo-single-tenant). Not sure which deployment model you need? See [Install Qodo in your Git provider](/install-qodo/install) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). Install Qodo on GitHub Cloud using the built-in wizard. Installing from the Qodo portal rather than GitHub Marketplace ensures every feature is enabled and correctly configured. Assuming your environment is already set up, the process takes about 5 minutes. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo multi-tenant portal. * GitHub organization admin access. ## Access the GitHub integration Install using the GitHub account and Qodo workspace you intend to use for your organization going forward. A GitHub organization stays bound to whichever Qodo workspace installs it first, and reassigning it to a different workspace later requires contacting Qodo support. See [Troubleshooting](#troubleshooting). Log in to your [Qodo portal.](https://app.qodo.ai/signin) Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **GitHub**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **GitHub**. ## Install Qodo using the wizard The wizard guides you through two steps: The wizard shows the install guide, a preview of the repository access configuration you will complete on GitHub. GitHub MT wizard install guide step showing repository scope options Click **Connect your organization**. You are redirected to GitHub. Authorize the installation and confirm repository access, then click **Install**. You are redirected back to the Qodo wizard. The wizard confirms that Qodo has been successfully installed on your GitHub organization and that AI code review, auto rule generation, and codebase context are enabled. GitHub MT wizard installation complete screen Click **Finish installation**. You are redirected to the **Integrations** page. Qodo is now active on the selected repositories. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new pull request in one of the configured repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Manage repositories after installation * To add or remove repositories, go to your GitHub App settings and update which repositories the app can access. * To enable or disable Qodo on individual repositories within your current scope, use the [Repositories page](/administration/repositories) in the Qodo portal. ## Troubleshooting ### GitHub organization already connected to another workspace If you see this message: ``` This GitHub organization is already connected to another Qodo workspace. ``` Error code: `GITHUB_ID_ALREADY_CLAIMED` Common causes: * A personal account installed Qodo before a company account did. * The account that originally installed Qodo was deleted. * A different company account installed Qodo on the same organization. This can also happen silently: clicking **Add installation** on the Integrations page redirects to a GitHub page for managing an app that's already installed, instead of the Qodo setup wizard. Back in the Qodo portal, the organization still shows as not connected, with no error shown. Contact [Qodo support](mailto:support@qodo.ai) with the GitHub organization name to identify and resolve the existing installation. ## Next steps * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. * [Repositories page](/administration/repositories): Manage which repositories Qodo is active on. # Install Qodo on GitHub - Single-tenant and Enterprise Server Source: https://docs.qodo.ai/install-qodo/github/qodo-single-tenant Single-tenant and GitHub Enterprise Server install guide for Qodo automated code review. * This guide applies to the following deployment combinations, all of which use the same installation wizard: * Qodo single-tenant with GitHub Cloud * Qodo single-tenant with GitHub Enterprise Server * Qodo multi-tenant with GitHub Enterprise Server * Not sure which deployment model you need? See [Install Qodo in your Git provider](/install-qodo/install) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). This guide walks you through installing Qodo on GitHub using the built-in wizard. Assuming your Qodo environment is already set up, the process takes about 5 minutes. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * Sufficient permissions to create GitHub applications. ## Access the GitHub integration Log in to your Qodo portal. For single-tenant accounts, your portal URL follows the pattern `app.yourcompany.st.qodo.ai` and is provided by your Qodo Account Manager. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **GitHub**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **GitHub**. For GitHub Enterprise Server, select the self-hosted option that appears after you select **GitHub**. ## Install Qodo using the wizard The wizard guides you through three steps. In **GitHub Organization URL**, enter your GitHub organization URL (for example, `https://github.com/your-org`). If you are using GitHub Enterprise Server, enter your server's URL (for example, `https://github.mycompany.com`). Review **Permissions Qodo will ask for**. The summary describes what Qodo does with its access: reads code and pull requests, posts review comments, replies when mentioned, and commits fixes on request. Expand the section to view the full app manifest. If you have questions about permissions or need adjustments, contact your Qodo Account Manager before proceeding. Click **Next**. GitHub installation wizard Connect GitHub step with the organization URL field and permissions summary Click **Continue on GitHub** to open GitHub and complete the following steps. GitHub installation wizard Install Qodo step listing the three actions to complete in GitHub **In GitHub** Review the app details Qodo filled in for you, keep the prefilled app name (Qodo for your organization name), and click **Create GitHub App for \[your organization name]**. Then select the GitHub user account to authorize the app. If the displayed account is correct, click **Continue**. Otherwise, sign in with a different account. Select which repositories Qodo can access: **All repositories** (recommended) or **Only select repositories**. You can later manage repository-level settings from the Qodo portal. GitHub App installation page showing repository access permission options Click **Install**. You are redirected back to the Qodo portal. In the wizard, click **Download logo**. Then, in GitHub, open the Qodo app's settings, upload the logo, and click **Save**. Qodo's comments then show the logo in pull requests. Check for the *"GitHub is connected"* message. The message shows how many repositories are connected. Qodo starts indexing them and their pull requests in the background to build context for code reviews. Click **Next**. If the wizard shows *"GitHub isn't connected yet"*, click **Try again**. If it fails again, contact your Qodo Account Manager. GitHub installation wizard Verify connection step showing the GitHub is connected message Qodo is now active on the selected repositories. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new pull request in the configured repositories and confirm that Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Manage repositories after installation * To add or remove repositories, navigate to your GitHub App settings and update which repositories the app can access. * To enable or disable Qodo on individual repositories within your current scope, use the [Repositories page](/governance/repositories) in the Qodo portal. ## Next steps * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. * [Repositories page](/governance/repositories): Manage which repositories Qodo is active on. # Install Qodo on GitLab Source: https://docs.qodo.ai/install-qodo/gitlab Multi-tenant, single-tenant, and on-premises GitLab install guides for Qodo automated code review. Qodo integrates directly with GitLab Cloud and GitLab Server, supporting multi-tenant, single-tenant, and on-premises deployments. Choose the guide for your GitLab hosting type and Qodo deployment. Not sure which deployment model you need? See [Install Qodo in your Git provider](/install-qodo/install) for a full comparison, or [check your deployment type](/deployment-models#check-your-deployment-type). The guided installation wizard, for Qodo multi-tenant and single-tenant on `gitlab.com`. The guided installation wizard, for Qodo multi-tenant and single-tenant on a self-hosted GitLab instance. The guided installation wizard, for Qodo on-premises on `gitlab.com`. The guided installation wizard, for Qodo on-premises on a self-hosted GitLab instance. # Install Qodo on GitLab Server Source: https://docs.qodo.ai/install-qodo/gitlab/gitlab-server Install guide for Qodo automated code review on a self-hosted GitLab Server instance, using the guided installation wizard. This wizard can be used for Qodo multi-tenant, single-tenant, and on-premises deployments on GitLab Server. For `gitlab.com`, see . Qodo works directly with GitLab Server, using a dedicated GitLab service account with Developer-level permissions to post code review comments on merge requests. Qodo can create this account for you, or your GitLab administrator can create it. You can configure Qodo for selected repositories or across your entire GitLab group. Configuration typically takes around 5–10 minutes. Once installed, Qodo automatically processes merge requests and delivers actionable insights, such as code reviews, descriptions, and improvement suggestions, directly within your GitLab workflow. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * The GitLab access that matches how the Qodo service account is created: * Automatic setup: Instance Admin access, needed for Qodo to create its service account and set up webhooks. * Manual setup: The Owner role on each group you connect, or the Maintainer role on each repository. Your GitLab administrator creates an instance service account for Qodo. * Network access from Qodo to your GitLab URL. ## Access the GitLab integration Log in to your Qodo portal. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **GitLab**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **GitLab**. Then select the self-managed option that appears after you select **GitLab**. ## Install Qodo on GitLab Server Enter your **GitLab URL** (for example, `https://gitlab.example.com`), then choose how the Qodo service account is created. Qodo creates the service account for you, using an instance Admin's access token. GitLab wizard step 1 on GitLab Server, Connect GitLab, with Automatic setup selected Under **How should the Qodo service account be created?**, select **Automatic setup**. Qodo uses your token to: * Create a dedicated Qodo service account on your instance. * Give it access only to the groups or repositories you select. * Configure the required webhooks. Sign in as an instance Admin and click **Create a token in GitLab** to open your GitLab instance's access token settings directly. If your instance is on GitLab 16.6 or earlier, use **Create a token in GitLab 16.6 or earlier** instead. The `api` scope is required and preselected. Leave it selected when you create the token. This token is used once, to create the Qodo service account, and is never stored. You can set a short expiry, for example 1 day, and revoke it once installation completes. Paste the token under **Your personal access token** and click **Next**. Your GitLab administrator creates the service account, so you don't need instance Admin access. GitLab wizard step 1 on GitLab Server, Connect GitLab, with Manual setup selected and the administrator instructions shown Under **How should the Qodo service account be created?**, select **Manual setup**. Before continuing, ask your GitLab administrator to: * In Admin > Service accounts, create a dedicated instance [service account](https://docs.gitlab.com/user/profile/service_accounts/) for Qodo that isn't an administrator. On GitLab Community Edition, which has no service accounts, create a dedicated regular user instead. * Create a personal access token for that account with the `api` scope, expiring at least two days from today. * Share the token with you. Use an instance service account, not a group or project one. GitLab limits group and project service accounts to their own group or project. Qodo reuses the same account whenever you connect more groups or repositories, and connecting outside that group or project can fail. Qodo checks each of the following when you connect. Any failure blocks the connection. * The token is a personal access token on the service account itself, not a group or project access token. * The token has the `api` scope, is active, and expires at least two days from today. * The token doesn't belong to an instance administrator, or to the account you sign in with. * On GitLab Enterprise Edition, the token belongs to an actual service account, not a person's account. Qodo can't check whether the account is an instance service account. Make sure your administrator creates one, as described above. Enter your own personal access token and the service account's token. Your token needs the `api` scope, and you need the Owner role on each group you connect, or the Maintainer role on each repository. Qodo asks for your token again when you later add or remove groups and repositories, or uninstall Qodo. You need the same role then. Qodo adds the service account to the groups or repositories you select, so it needs no other access. Use this service account and its token for Qodo only. * Qodo renews the token before it expires, which invalidates your copy. When Qodo is uninstalled, it revokes the token and leaves the account in place. * If the instance already has an installation, Qodo keeps using its existing service account. A new token for that account replaces the stored one. A token for a different account is ignored. * If the service account stops working and you can't create a working token for it, uninstall and reinstall Qodo, unless you can sign in with an instance Admin account. Click **Next**. GitLab wizard step 2, Select repositories, showing the group list with one group selected, the search bar, and Select all Find and select what to connect: * Use the search bar to find a specific group or repository, or browse the list of top-level groups you have access to. * Select a group to connect every repository within it, or drill into a group to select individual repositories. * Select **Select all** to connect everything you have access to in one step. On GitLab Community Edition and free-tier instances, which don't support group hooks, this step appears as "Select repositories" and Qodo creates a hook for each repository you select. On tiers with group hooks, it appears as "Select groups and repositories", and selecting a group creates a group hook. Repositories in personal namespaces aren't supported. Click **Next**. GitLab wizard step 3, Verify connection, confirming that GitLab Self-Managed is connected and that pull request indexing started in the background Qodo confirms it's connected to your selected repositories and groups, and starts pull request indexing in the background. Click **Next**. Qodo is now active on the repositories in the groups you selected. To connect more repositories under an existing installation, use [Manage the repositories in an installation](/governance/repositories/installations#manage-the-repositories-in-an-installation) on the Repositories page. To connect a different group, return to this wizard. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new merge request in one of the connected repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or MR summary directly on the merge request. ## Troubleshooting If Qodo doesn't respond on the merge request, check that GitLab can reach Qodo's webhook URL: In GitLab, navigate to the webhook settings of the connected group or repository. Copy the URL of the webhook Qodo created. The URL is different for each Qodo installation. Confirm that your network allows GitLab to reach that URL. ## Next steps * [Repositories page](/governance/repositories): Manage which repositories Qodo is active on, or remove an installation. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. * [Migration guide](/install-qodo/gitlab/migration): Migrate an existing Qodo installation. # Install Qodo on GitLab Cloud Source: https://docs.qodo.ai/install-qodo/gitlab/install-qodo-on-gitlab Install guide for Qodo automated code review on GitLab Cloud, using the guided installation wizard. This wizard can be used for Qodo multi-tenant, single-tenant, and on-premises deployments on GitLab Cloud (`gitlab.com`). For a self-hosted instance, see . Qodo works directly with GitLab, using a dedicated GitLab service account with Developer-level permissions to post code review comments on merge requests. Qodo creates this account automatically using a personal access token you provide during setup, then discards the token. You can configure Qodo for selected repositories or across your entire GitLab group. Configuration typically takes around 5–10 minutes. Once installed, Qodo automatically processes merge requests and delivers actionable insights, such as code reviews, descriptions, and improvement suggestions, directly within your GitLab workflow. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * The Owner role on each top-level GitLab group you connect, needed for Qodo to create its service account in that group and set up webhooks. * Network access from Qodo to `gitlab.com`. ## Access the GitLab integration Log in to your Qodo portal. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **GitLab**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **GitLab**. ## Install Qodo on GitLab Cloud GitLab wizard step 1, Connect GitLab, showing the GitLab URL and personal access token fields Confirm the **GitLab URL** is `https://gitlab.com`. Sign in as a group Owner. Click **Create a token in GitLab** to open your GitLab access token settings directly. The `api` scope is required and preselected. Leave it selected when you create the token. This token is used once, to create the Qodo service account, and is never stored. You can set a short expiry, for example 1 day. Paste the token under **Your personal access token** and click **Next**. GitLab wizard step 2, Select repositories, showing the group list with one group selected, the search bar, and Select all Find and select what to connect: * Use the search bar to find a specific group or repository, or browse the list of top-level groups you have access to. * Select a group to connect every repository within it, or drill into a group to select individual repositories. * Select **Select all** to connect everything you have access to in one step. On GitLab free-tier groups, which don't support group hooks, this step appears as "Select repositories" and Qodo creates a hook for each repository you select. On tiers with group hooks, it appears as "Select groups and repositories", and selecting a group creates a group hook. Repositories in personal namespaces aren't supported. Click **Next**. GitLab wizard step 3, Verify connection, showing the confirmation banner and per-group connection status Qodo confirms it's connected to your selected repositories and groups. * Each one shows its status: **Already connected** from a previous installation, or **Connected** if newly connected. * Installing across multiple top-level groups sets up each group as a separate installation, appearing as its own item on the [Installations tab](/governance/repositories/installations). * Click **Done**. Qodo is now active on the repositories in the groups you selected. To connect more repositories under an existing installation, use [Manage the repositories in an installation](/governance/repositories/installations#manage-the-repositories-in-an-installation) on the Repositories page. To connect a different group, return to this wizard. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new merge request in one of the connected repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or MR summary directly on the merge request. ## Troubleshooting If Qodo doesn't respond on the merge request, check that GitLab can reach Qodo's webhook URL: In GitLab, navigate to the webhook settings of the connected group or repository. Copy the URL of the webhook Qodo created. The URL is different for each Qodo installation. Confirm that your network allows GitLab to reach that URL. ## Next steps * [Repositories page](/governance/repositories): Manage which repositories Qodo is active on, or remove an installation. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. * [Migration guide](/install-qodo/gitlab/migration): Migrate an existing Qodo installation. # GitLab: Migrate to the Qodo 2.7 installation wizard Source: https://docs.qodo.ai/install-qodo/gitlab/migration Migrate your existing GitLab integration to the Qodo 2.7 installation wizard for full feature access and better performance and reliability. How you migrate depends on how you originally installed Qodo on GitLab. This guide covers migrating to the Qodo 2.7 installation wizard. ## Installed using the Qodo 2.3.3 installation wizard No action is required. Your existing installation continues to operate as expected. The next time you open the installation wizard, for example to add more groups or projects, Qodo migrates your installation to the new system automatically and safely. ## Installed manually (pre-wizard) Launching the wizard gives you access to the Review Standards, findings, and other advanced code review features, improves overall performance and reliability, and ensures your installation appears on the [Repositories page](/administration/repositories). The process involves noting your existing webhooks, installing Qodo using the new wizard, verifying it is working, and then removing the old setup to avoid conflicts. Without migrating, your existing installation will continue to work but you will not have access to advanced features such as rules and findings, and your installation will not appear on the [Repositories page](/administration/repositories). Before installing, record the IDs of your existing Qodo webhooks. You will need these to identify which webhooks to remove during cleanup, so you do not accidentally delete webhooks created by the new installation. GitLab webhooks can be set at the group level or at the individual project level, depending on how your original installation was configured. Check both. **Group webhooks** Go to your GitLab group. Select **Settings**, then **Webhooks**. Note any Qodo webhooks listed. **Project webhooks** Go to each project in your group. Select **Settings**, then **Webhooks**. For each Qodo webhook, click **Edit** and note the webhook ID from the URL. For example, in `https://gitlab.com/group/project/-/hooks/80678936/edit`, the webhook ID is `80678936`. Your existing installation covers either all repositories in a group (if a group webhook was installed) or select repositories (if individual project webhooks were installed). Follow the [installation wizard](/install-qodo/gitlab) in the Qodo portal to complete your new GitLab setup, selecting all repositories to match your existing coverage or your desired new scope. Once the wizard is complete, return here to continue. Before removing the old installation, confirm the new one is active. Open a merge request or use an existing one in any connected repository. Add `/agentic_review` as a comment on the merge request. This runs a full review and can take a few minutes. If two installations are running, you will see two sets of 👀 reactions and duplicate comments on merge requests. Once you see the new installation responding as expected, proceed with the cleanup steps below. Delete only the webhooks whose IDs you noted in step 1. Do not delete webhooks created by the new installation. **Group webhooks** Go to your GitLab group. Select **Settings**, then **Webhooks**. Delete each webhook whose ID matches one you noted in step 1. **Project webhooks** Go to each project where you noted a webhook. Select **Settings**, then **Webhooks**. Delete each webhook whose ID matches one you noted in step 1. Delete the personal, project, or group access token that was created for the original installation. Go to your GitLab profile or group settings, depending on the token type. Select **Access Tokens**. Revoke the token that was created for the original Qodo installation. Your GitLab integration is now fully migrated to the new wizard. Qodo is running through the new installation on your selected repositories. ## Next steps * [Repositories page](/administration/repositories): Confirm your new installation appears. * [Configure](/configuration): Set up configuration files, portal settings, and advanced options for your organization. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install Qodo in your Git provider Source: https://docs.qodo.ai/install-qodo/install Connect Qodo to your Git provider to enable automated code reviews directly in your pull requests. Already using Qodo? See the [migration guide](/install-qodo/migration-guide) to upgrade your existing installation to the Qodo installation wizard. Qodo integrates directly with your Git provider to analyze and enhance pull requests where your team already works. This connection enables Qodo to: * Pull the content of your pull request * Analyze changes using context-aware review agents and your organization's standards * Publish insights, summaries, and review feedback back to the same pull request By working directly inside your Git provider, Qodo keeps all review feedback tightly coupled to your source code and existing workflow, without requiring you to switch tools or contexts. ## Where to start You can connect a Git provider from three places in the Qodo portal: * **Onboarding wizard**: Opens on an organization admin's first sign-in. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **Integrations page**: Browse all Git providers and connect from there. * **Homepage**: Click the **+** button next to Git providers, in the top right-hand side. See [Qodo portal quick tour](/qodo-portal-quick-tour). ## Select your setup Qodo is available in three deployment models: * **Multi-tenant (MT)**: The standard offering for teams wanting immediate value with zero infrastructure management. Available on all plans. * **Single-tenant (ST)**: A dedicated, isolated environment for Enterprise customers requiring data sovereignty. * **On-premises (On-Prem)**: Full control over the environment, suitable for air-gapped or highly regulated industries. Not sure which deployment model is right for you? See [Deployment models](/deployment-models) for a full comparison. ## Installation matrix Select your Git provider and deployment model. | | Qodo multi-tenant | Qodo single-tenant | Qodo on-premises | | - | - | - | - | | **Availability** | All plans | Enterprise only | Enterprise only | | **GitHub Cloud** | [Install on GitHub Cloud](/install-qodo/github/qodo-multi-tenant) | [Install on GitHub Cloud](/install-qodo/github/qodo-single-tenant) | — | | **GitHub Enterprise Server** | [Install on GitHub Enterprise Server](/install-qodo/github/qodo-single-tenant) | [Install on GitHub Enterprise Server](/install-qodo/github/qodo-single-tenant) | [Install on GitHub Enterprise Server](/install-qodo/github/github-enterprise) | | **GitLab Cloud** | [Install on GitLab Cloud](/install-qodo/gitlab/install-qodo-on-gitlab) | [Install on GitLab Cloud](/install-qodo/gitlab/install-qodo-on-gitlab) | [Install on GitLab Cloud](/on-prem/git-integration/install/gitlab-cloud) | | **GitLab Server** | [Install on GitLab Server](/install-qodo/gitlab/gitlab-server) | [Install on GitLab Server](/install-qodo/gitlab/gitlab-server) | [Install on GitLab Server](/on-prem/git-integration/install/gitlab) | | **Bitbucket Cloud** | [Install on Bitbucket Cloud](/install-qodo/bitbucket/bitbucket-cloud) | [Install on Bitbucket Cloud](/install-qodo/bitbucket/bitbucket-cloud) | [Install on Bitbucket Cloud](/on-prem/git-integration/install/bitbucket-cloud) | | **Bitbucket Data Center** | — | — | [Install on Bitbucket Data Center](/on-prem/git-integration/install/bitbucket-data-center) | | **Azure DevOps** | [Install on Azure DevOps](/install-qodo/azure-devops) | [Install on Azure DevOps](/install-qodo/azure-devops) | [Install on Azure DevOps](/on-prem/git-integration/install/azure-devops) | | **Gerrit** | [Install on Gerrit](/install-qodo/gerrit) | [Install on Gerrit](/install-qodo/gerrit) | [Install on Gerrit](/on-prem/git-integration/install/gerrit) | Select your Git provider and deployment model from the table above to begin. Once installed, see [Configure](/configuration) to set up Qodo for your organization. # Launch the installation wizard for advanced code review Source: https://docs.qodo.ai/install-qodo/migration-guide Migrate your existing Qodo installation to the Qodo installation wizard to unlock advanced code review features including rules, findings, and improved performance. Launching the wizard gives you access to the Review Standards, findings, and other advanced code review features, and improves overall performance and reliability. Without migrating, your existing installation will continue to work but you will not have access to advanced features such as rules and findings. Select your Git provider to get started: Migrate your GitHub installation to the Qodo installation wizard. Migrate your Azure DevOps integration to the Qodo installation wizard. Migrate your Bitbucket installation to the Qodo installation wizard. Migrate your GitLab installation to the Qodo installation wizard. # Extend Qodo's capabilities with integrations Source: https://docs.qodo.ai/integrations Connect Qodo to your workflow tools to enrich code reviews with ticket context, specifications, design assets, and more. Qodo connects to the tools your team already uses. The more context Qodo has about a change, the more useful the review feedback. Connections are managed from the Integrations page in the Qodo portal. For Git provider setup, see [Installation](/install-qodo/install). ## Task management When a pull request references a ticket, Qodo fetches the ticket data and uses it to generate a more accurate summary and surface requirement gaps during review. Supported tools include Jira, GitHub Issues, and Linear. See [Ticketing integrations](/integrations/ticketing-integrations) for setup, supported fields, and configuration options. ## Documentation & design Connect your documentation and design tools so Qodo can check code changes against product specifications and UI designs. Supported tools include Confluence, Notion, and Figma, currently in Research preview. See [Documentation and design integrations](/integrations/documentation-and-design-integrations) for setup and details. ## IT & asset management Connect IT and asset management systems, such as ServiceNow and Jira Service Management (JSM) Assets, to surface configuration item and asset context during review. To set up IT and asset management integrations, [contact your Qodo Account Manager](/qodo-support). ## IDE extensions **Heads up: IDE plugin deprecation notice** The Qodo IDE plugin is being retired on October 30, 2026. Local code review now runs inside the coding agents you already use. Set up the Qodo Agentic Toolbox to keep reviewing code before you open a pull request. [Get the Agentic Toolbox](https://docs.qodo.ai/agentic-toolbox). Each developer can install the Qodo extension to get review feedback and AI assistance directly in their editor, available for Visual Studio Code, Visual Studio, and JetBrains IDEs. This is a per-developer install, not a portal connection. See [Qodo IDE setup and installation](/qodo-ide/getting-started/setup-and-installation) for details. # Documentation & design integrations Source: https://docs.qodo.ai/integrations/documentation-and-design-integrations Learn how to integrate Qodo with your documentation and design tools so specifications and designs can be used in pull request reviews and workflows. Qodo integrates with documentation and design tools to bring external context into pull request workflows. This allows Qodo to access specifications and design files stored in supported tools and use them during analysis. ## URL processing guidelines When including documentation or design URLs in a pull request, the following apply: * A pull request can include up to one specification document and one design document. * When multiple URLs of the same type are present, only the first detected URL is used. * If multiple specification sources are provided (for example, Notion and Confluence), only the first one is used. * The following guidelines apply to these specific usecases: | URLs included in the pull request | Result | | - | - | | Multiple Notion URLs | Only the first Notion URL is processed | | Multiple Confluence URLs | Only the first Confluence URL is processed | | Multiple Figma URLs | Only the first Figma URL is processed | | One Notion URL and one Figma URL | Both URLs are processed | | One Confluence URL and one Figma URL | Both URLs are processed | | One Notion URL and one Confluence URL | Only the first specification URL is processed | ## Get started To enable documentation and design integrations, configure a supported tool in the Qodo portal. See the setup guide for each supported tool: Pull Confluence pages into review context so Qodo can check changes against specifications. Pull Notion docs into review context so Qodo can check changes against specifications. Surface design frames and component context when reviewing UI changes. # Integrate Qodo with Confluence Source: https://docs.qodo.ai/integrations/documentation-and-design-integrations/integrate-qodo-with-confluence Connect Confluence to Qodo to enable the Spec Agent to analyze pull requests against requirements documented in Confluence. Connect Confluence to Qodo so the Spec Agent can use documentation stored in Confluence when reviewing GitHub pull requests. ## Prerequisites Before connecting Confluence, ensure you have: * Confluence administrator permissions. * A Git provider connected to Qodo and the Qodo app installed. For more information, see [Install Qodo](https://docs.qodo.ai/install-qodo/install). ## Integrate Confluence with Qodo 1. Log in to the Qodo portal. 2. Navigate to **Integrations** > **Documentation & Design**. 3. Under **Confluence**, click **Connect**. 4. Sign in to your Atlassian account. 5. Select the Confluence workspace you want to connect. 6. Review the requested permissions and click **Allow**. 7. After authorization completes, the integration status changes to **Connected**. Confluence integration with Connected status When you connect Confluence, Qodo automatically enables the Spec agent. You do not need to enable it manually. ## Verify the integration After connecting Confluence: 1. Create or update a Confluence page that contains product requirements, technical specifications, or implementation details. 2. Create or update a pull request in a GitHub repository connected to Qodo, and add a link to the relevant Confluence page in the PR description. 3. Wait for the Qodo review to complete. 4. Open the **Qodo Review Results** in the pull request. When a pull request includes a specification link in its description, the Spec agent analyzes the implementation against the requirements in the linked page and generates **📎 Requirement gap** findings as part of the review. GitHub pull request with Qodo Review Results and a Requirement gap finding For more information about requirement gap findings, see [View requirement gaps in your findings](/code-review/view-requirement-gaps-in-findings). ## Troubleshooting ### No documentation findings appear If you do not see documentation-based findings in the pull request review: * Verify that the PR description contains a link to the relevant Confluence page.” * Verify that the Confluence integration is connected in the Qodo portal. * Verify that the repository is connected to Qodo through the GitHub App. * Verify that the Spec Agent is enabled. * Ensure the pull request has completed a Qodo review. * Confirm that the relevant documentation exists in Confluence. Not every pull request produces documentation findings. The Spec agent generates requirement gaps only when it identifies documentation that is relevant to the changes in the pull request and detects missing or incomplete implementation. ## Related resources * [Documentation & design integrations](/integrations/documentation-and-design-integrations): An overview of documentation and design management integrations. * [View requirement gaps in your findings](/code-review/view-requirement-gaps-in-findings): How requirement gaps appear in reviews. # Integrate Qodo with Notion Source: https://docs.qodo.ai/integrations/documentation-and-design-integrations/integrate-qodo-with-notion Connect Notion to Qodo so the Spec Agent can analyze pull requests against requirements documented in Notion. Connect Notion to Qodo so the Spec Agent can use Notion documentation when validating pull requests against documented requirements. ## Prerequisites * Notion administrator permissions. ## Connect Notion to Qodo 1. Log in to the Qodo Portal. 2. Navigate to **Integrations > Documentation & Design**. 3. Under **Notion**, click **+ Connect**. You are redirected to the Notion authorization page. 4. Sign in to Notion and authorize the integration. After authentication is complete, the Spec agent is enabled in the **Research Preview** section. ## Related resources * [Documentation and design management integrations](/integrations/documentation-and-design-integrations): An overview of documentation and design management integrations. * [View requirement gaps in your PR findings](/code-review/view-requirement-gaps-in-findings): How requirement gaps appear in reviews. # Integrate Qodo with Figma Source: https://docs.qodo.ai/integrations/documentation-and-design-integrations/integrate-with-figma Connect Figma to Qodo so the Design review Agent can analyze pull requests against designs documented in Figma. Connect Figma to Qodo so the Design review Agent can use Figma designs when validating pull requests against documented requirements. ## Prerequisites * Figma administrator permissions. ## Connect Figma to Qodo 1. Log in to the Qodo Portal. 2. Navigate to **Integrations > Documentation & Design**. 3. Under **Figma**, click **+ Connect**. You are redirected to the Figma authorization page. 4. Sign in to Figma and authorize the integration. After authentication is complete, the Design review agent is enabled under **Design gaps** in the **Finding types** tab. ## Related resources * [Documentation and design management integrations](/integrations/documentation-and-design-integrations): An overview of documentation and design management integrations. * [View UX deviations in your PR findings](/code-review/view-ux-deviations-in-findings): How UX deviations appear in reviews. # Use ticket context in code reviews Source: https://docs.qodo.ai/integrations/ticketing-integrations Learn how to integrate Qodo with your ticketing system to surface ticket context in code reviews and align pull request feedback with stated requirements.
GitHub Jira Linear Azure DevOps
Qodo enhances the code review process by integrating with your ticket management system. It automatically surfaces relevant ticket data alongside code changes, helping reviewers understand the intent behind a pull request. Qodo supports both native ticketing integrations (where the repository and ticketing system are hosted on the same platform) and external ticketing integrations, which can be used alongside supported repository platforms. #### Ticket data fetched The table below shows which ticket fields are fetched and used by Qodo for ticket context and compliance, per provider. | Provider | Title | Description | Custom Fields | Subtasks / Children | Acceptance Criteria | Attachments | Labels / Tags | | - | - | - | - | - | - | - | - | | **Jira** | ✔ | ✔ | ✔ (`customfield_*`) | ✔ | ✔\* | ✔ (≤3 images) | ✔ | | **Linear** | ✔ | ✔ | ✖ | ✔ | ✖ | ✔ (≤3 images + embedded) | ✔ | | **Azure DevOps** | ✔ (`System.Title`) | ✔ (`System.Description`) | ✖ | ✖ | ✔ (dedicated field) | ✖ | ✔ (`System.Tags`) | | **Monday.com** | ✔ | ✔ | ✔ (long\_text cols) | ✔ | ✖ | ✖ | ✔ | | **GitHub Issues** | ✔ | ✔ | ✖ | ✔ | ✖ | ✖ | ✔ | | **GitLab Issues** | ✔ | ✔ | ✖ | ✔ | ✖ | ✖ | ✔ | \* Acceptance criteria in Jira is supported only when stored in a custom field. #### Ticket recognition criteria A ticket is linked to a PR if: * The PR description contains a direct link to the ticket, **or** * The branch name matches an accepted ticket reference pattern (see accepted syntax for details) **Accepted syntax** | Provider | Supported examples | Not supported | | - | - | - | | **Jira** | `PROJ-123`
`proj-123`
`feature/PROJ-123`
`feature/PROJ-123/add-new-feature`
`feature/PROJ-123-add-new-feature`
`fix-PROJ-123-bug`
`TSAASO-3250-cluster-labels`
`ABC-5678_v2`
`[PROJ-123]-hotfix`
`release-v1.2-PROJ-123-impl` | `bugfix-abc-456-fix`
`PROJ123`
`P-123`
`PROJ1-123`
`VERYLONGPROJECT-123`
`PROJ-12345678` | | **Linear** | `PLT-2837`
`plt-2837`
`plt-2837-be-rename-env-file`
`A1B2-456`
`feature/PLT-2837`
`feature/PLT-2837-add-feature`
`release/v1.2/PLT-2837`
`hotfix/ABC-123/urgent` | `fix-PLT-2837`
`bugfix_PLT-2837`
`feature-PLT-2837-bug`
`[PLT-2837]`
`PREFIX/feature-PLT-2837` | **Notes:** * Branch-based detection is always enabled * Supported patterns are fixed in production and cannot be configured * Matching is case-insensitive * The ticket ID must appear at the start of the branch name or immediately after a `/` ### Code review behavior #### Context-aware analysis When a pull request references a ticket or requirement, Qodo uses the available context (such as title and description) to better understand the intent behind the changes. This context informs both the generated pull request description and the review feedback. #### Requirement alignment feedback During review, Qodo evaluates how well the changes align with the stated intent and surfaces feedback as findings rather than explicit compliance statuses. This may include: * Missing or incomplete requirements * Changes that do not clearly support the intended goal * Notes indicating that the implementation looks correct but may require additional manual validation (for example, UI testing) #### Configuration options By default, requirement-aware feedback is included in reviews. To disable it: ```bash theme={null} [pr_reviewer] require_ticket_analysis_review = false ``` You can also enable detection of unrelated changes: ```bash theme={null} [pr_reviewer] check_pr_additional_content = true ``` When enabled, Qodo flags changes that appear unrelated to the stated intent and notes them in the review. This setting is disabled by default. ## Get started See the setup guide for each supported tool: Surface issue requirements, acceptance criteria, and subtasks during review. Supports Jira Cloud and Jira Data Center. Link Linear issues to pull requests for context-aware review. Link GitHub Issues to pull requests for context-aware review. Surface Azure Boards work item context and acceptance criteria during review. # Integrate Qodo with Azure DevOps work items Source: https://docs.qodo.ai/integrations/ticketing-integrations/azure-devops Configure how Qodo uses Azure DevOps Work Items and external tickets to provide PR context and perform ticket compliance checks. Azure DevOps supports ticketing at the project level through **Azure Boards Work Items**, and can reference external tickets when they are included in pull requests. This integration applies to repositories hosted in Azure DevOps Repos, where Azure Boards Work Items function as the native ticketing system. Qodo uses ticket information associated with Pull Requests to provide additional context and perform ticket compliance checks. ### Supported ticket types Depending on your integrations, Qodo can use: * Azure DevOps **Work Items** (all Work Item types) * Integrated external ticket systems (for example, Jira, Linear, Monday) Azure DevOps Work Items and external tickets can be used together in the same Pull Request. ### How tickets are associated with pull requests Qodo uses ticket information associated with a Pull Request in the following ways: #### **Linked work items** When creating or editing a Pull Request: Navigate to **Repos → Pull Requests** Create a new Pull Request or open an existing one Use **Work items to link** Select one or more Work Items from the project Linked Work Items are used by Qodo for ticket context and compliance validation. **Notes:** * Multiple Work Items per Pull Request are supported and all linked tickets are used for context and compliance * Up to **10 tickets** are processed per PR by default * This limit can be configured (for example: `max_tickets = 15`) * Each ticket is capped at **10,000 characters** of content (fixed limit) #### **Pull request description** Tickets can be referenced in the Pull Request description using natural language or direct links, including links to external ticket systems when configured. If a Pull Request includes both linked Azure DevOps Work Items and external ticket references, **all tickets are used together** for context and compliance. #### **Branch name association** Tickets from external systems (such as Jira and Linear) can be associated with a Pull Request based on the source branch name. See more details about the [accepted syntax.](/code-review/qodo-merge/integrations/ticketing-integrations#accepted-syntax) ### Permissions and access requirements Qodo requires `read` access to Azure DevOps Work Items. If the service account cannot access a linked Work Item, ticket compliance behaves the same as if no ticket were linked. ### Cross-project work items A Pull Request may reference a Work Item from a different project within the same Azure DevOps organization. The Work Item can be fetched only if Qodo is configured for the referenced project and the service account has access to it. # Integrate Qodo with GitHub Issues Source: https://docs.qodo.ai/integrations/ticketing-integrations/github GitHub Issues are supported when your repository is hosted on GitHub, and function as a native ticketing integration for GitHub repositories. Qodo automatically recognizes GitHub issues referenced in the PR description and fetches the issue content. Valid GitHub issue references include: * `https://github.com///issues/` * `#` * `/#` Because Qodo is already integrated with GitHub, no additional configuration is required to fetch GitHub issues. # Integrate Qodo with Jira Source: https://docs.qodo.ai/integrations/ticketing-integrations/jira Configure Jira Cloud or Data Center as a ticketing integration so Qodo can fetch ticket context for pull request reviews. ## Jira Cloud Jira is supported as an external ticketing integration and can be used with supported repository platforms by referencing tickets in the PR description or branch name. ### Jira app authentication The recommended way to authenticate with Jira Cloud is to install the Qodo app in your Jira Cloud instance. This will allow Qodo to access Jira data on your behalf. Go to the Qodo Integrations page. Click **Connect Jira Cloud** to connect the Jira Cloud app. Click **Accept**. After installing the app, you’ll be redirected to the Qodo registration page with a confirmation message. Qodo can now fetch Jira ticket context for your pull requests. ## Jira Data Center/Server ### Personal Access Token (PAT) authentication Authenticate with Jira Data Center or Server using a Personal Access Token (PAT). Add the following values to your configuration file, environment variables, or secrets file: ```bash theme={null} [jira] jira_base_url = "https://jira.company.com" jira_api_token = "server_pat_token" ``` ### Validate PAT authentication via Python script If you’re experiencing issues retrieving tickets in Qodo when using PAT authentication, you can validate the setup with a Python script. The steps below help verify that PAT authentication is working correctly and that Jira ticket details are accessible. Run: ```bash theme={null} pip install jira==3.8.0 ``` Run the following Python script. Make sure to replace the placeholders with your actual values: ```python expandable theme={null} from jira import JIRA if __name__ == "__main__": try: # Jira server URL server = "https://..." # Jira PAT token token_auth = "..." # Jira ticket code (e.g. "PROJ-123") ticket_id = "..." print("Initializing JiraServerTicketProvider with JIRA server") # Initialize JIRA client jira = JIRA( server=server, token_auth=token_auth, timeout=30 ) if jira: print(f"JIRA client initialized successfully") else: print("Error initializing JIRA client") # Fetch ticket details ticket = jira.issue(ticket_id) print(f"Ticket title: {ticket.fields.summary}") except Exception as e: print(f"Error fetching JIRA ticket details: {e}") ``` ## How to link a PR to a Jira ticket Qodo automatically detects Jira tickets using one of the following methods: ### Method 1: PR description reference Include a ticket reference in your pull request description using either: * The full Jira ticket URL: `https://.atlassian.net/browse/` * The shortened ticket ID (for example, `ISSUE-123`) For shortened ticket IDs, the Jira base URL must be configured (see below). ### Method 2: Branch name detection Prefix your branch name with the ticket ID, for example: * `ISSUE-123-feature-description` * `feature/ISSUE-123/feature-description` ## Jira base URL For shortened ticket IDs or branch name detection (Jira Cloud), configure the Jira base URL in your configuration file under the `[jira]` section: ```bash theme={null} [jira] jira_base_url = "https://.atlassian.net" ``` Where `` is your Jira organization identifier (for example, `mycompany` for `https://mycompany.atlassian.net`). ## Multi-JIRA server configuration Qodo supports connecting to multiple JIRA servers using different authentication methods. ### PAT auth Configure multiple servers using Personal Access Token authentication in your [configuration file](/configuration/configuration-file). **Example Configuration:** ```js theme={null} [jira] # List of JIRA server URLs jira_servers = ["https://server1.jira.com", "https://server2.jira.com"] # List of PAT tokens jira_api_token = ["pat_token_1", "pat_token_2"] # Default server for ticket IDs # Each repository can configure its own jira_base_url in a local config file # to choose which server to use by default. jira_base_url = "https://server1.jira.com" ``` ### Jira Cloud app For Jira Cloud instances using app authentication: 1. Install the Qodo app on each Jira Cloud instance you want to connect. 2. In your configuration file, set the default server for ticket ID resolution: ```bash theme={null} [jira] jira_base_url = "https://primary-team.atlassian.net" ``` Full URLs (for example, `https://other-team.atlassian.net/browse/TASK-456`) automatically resolve to the correct connected Jira instance. # Integrate Qodo with Linear Source: https://docs.qodo.ai/integrations/ticketing-integrations/linear Linear is supported as an external ticketing integration and can be used with supported repository platforms by referencing tickets in the PR description or branch name. ## Linear app authentication The recommended way to authenticate with Linear is by connecting the Linear app through the Qodo portal. ### Installation steps Once connected, Qodo can fetch Linear ticket context for your pull requests. ### How to link a PR to a Linear ticket Qodo will automatically detect Linear tickets using either of these methods: **Method 1: Description reference:** Include a ticket reference in your PR description using either: * The full Linear ticket URL: `https://linear.app//issue/` * The shortened ticket ID (for example, `ABC-123`) This method requires the `linear_base_url` configuration (see below). **Method 2: Branch name detection:** Prefix your branch name with the ticket ID, for example: * `ABC-123-feature-description` * `feature/ABC-123/feature-description` ### Linear base URL To use shortened ticket IDs or branch name detection, configure your Linear base URL in your [configuration file](/configuration/configuration-file) under the `[linear]` section. ```bash theme={null} [linear] linear_base_url = "https://linear.app/[ORG_ID]" # your Linear organization identifier ``` # Migrating to Qodo v2 Source: https://docs.qodo.ai/migrating-to-qodo-v2 This guide explains how to transition from Qodo v1 to Qodo v2's new code review experience safely and incrementally. Starting February 4, 2026, new Qodo accounts will not have access to the Qodo v1 code review experience. To use the new code review experience, update your repository configuration and enable the new review commands. During migration, you can run the new review alongside existing commands for testing, then remove duplicates once validation is complete. ### Step 1: Update your repository configuration Configuration for code review lives in your repository’s [configuration](/configuration). In the `.pr_agent.toml` you can see which review commands are enabled and how feedback is generated. #### Add the new review commands In the `git_provider` section (varies depending on your provider), add the new review commands (prefixed with `/agentic`): ```bash expandable theme={null} ⚠️ Select ONLY ONE section below, the one that matches your git provider. # Do not include multiple provider sections in the same configuration file. # GitHub App [github_app] pr_commands = [ "/agentic_describe", "/agentic_review" ] # GitLab [gitlab] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Bitbucket Cloud / App [bitbucket_app] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Bitbucket Server / Data Center [bitbucket_server] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Azure DevOps Server [azure_devops_server] pr_commands = [ "/agentic_describe", "/agentic_review" ] ``` The new commands combine and replace multiple legacy commands, including `/improve`, `/review`, `/describe`, and `/compliance` During testing, both old and new review commands may run in parallel for comparison, but once migration is complete, older commands should be removed to avoid duplicate feedback and noise. **Optional: Test the new review manually** Manual testing is an optional way to preview the new code review experience before or during configuration. In any pull request comment, enter: ```bash theme={null} /agentic_describe /agentic_review ``` This enables you to: * Validate the new review output on real pull requests * Compare results with existing review behavior * Test without changing repository configuration Manual invocation is intended for testing and validation. ### Step 2: Enable on a pilot repository Before rolling out the new code review experience across your organization, we recommend enabling it on a pilot repository. This helps you: * Evaluate signal quality and noise levels * Confirm the new review behavior meets expectations * Adjust configuration if needed * Remove duplicate commands after validation **Configuration details** To learn how to configure options such as severity thresholds, display modes, verbosity levels, and ignore rules, see [Configuration](/configuration) fundamentals. ### Step 3: Enable on entire organization After you’ve validated the new code review experience in a pilot repository, you can roll it out across your organization by applying the configuration at the organization level. To enable the new review commands across all repositories, define them in the **global organization configuration**: Create a repository in your organization named: `pr-agent-settings` Add a `pr_agent.toml` file to the root of that repository’s default branch. In the `git_provider` section, set the new review commands: ```bash expandable theme={null} ⚠️ Select ONLY ONE section below, the one that matches your git provider. # Do not include multiple provider sections in the same configuration file. # GitHub App [github_app] pr_commands = [ "/agentic_describe", "/agentic_review" ] # GitLab [gitlab] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Bitbucket Cloud / App [bitbucket_app] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Bitbucket Server / Data Center [bitbucket_server] pr_commands = [ "/agentic_describe", "/agentic_review" ] # Azure DevOps Server [azure_devops_server] pr_commands = [ "/agentic_describe", "/agentic_review" ] ``` Merge the change. After this change is merged, the configuration applies as the default for all repositories in the organization (unless overridden by a repo-level or wiki configuration). ### Step 4: Remove Qodo v1 configuration Once you enable the new commands broadly, remove older review commands from any configuration location where they are still defined (wiki, repo-level, or global). See [Configuration](/configuration) fundamentals for more details. ## What you’ll notice in your PRs After rollout, review output will be consolidated and more structured: * Compliance and Code Suggestions will no longer appear as separate outputs (they are incorporated into the new review experience) * Issues are grouped by priority (for example, Action Required vs Remediation Recommended) * Findings include clearer explanations and direct references to relevant code * Reviews include agent-assisted fix prompts to help resolve issues faster These changes are expected and reflect a more coordinated and prioritized review flow. # Migrating to Qodo v2 FAQ Source: https://docs.qodo.ai/migrating-to-qodo-v2/migrating-to-qodo-v2-faq Frequently asked questions about migrating from Qodo v1 to Qodo v2, including feature changes, deprecations, and the new Review Standards. Qodo v2 introduces a unified platform architecture that expands and restructures capabilities previously available in Qodo v1. As the platform evolves across v2.x releases, features may be enhanced, consolidated, or redesigned to support a more scalable and integrated experience. This guide focuses on feature mappings, deprecations, and required migration guidance for existing functionality. For new capabilities introduced in Qodo 2.x that did not exist in Qodo v1, refer to the [What's New ](/qodo-documentation/whats-new). ### General Supported SCM: GitHub. Supported Plans: All plans. Supported deployment types: Single-tenant, Multi-tenant and On Premises. Qodo v2 introduces a unified platform architecture. The table below maps current platform capabilities to their equivalents in Qodo v1. Items are ordered by the most recent update. | Qodo v2 Feature | Qodo v1 Equivalent | Version | Status | Change Summary | Supported SCM | Required Action | | - | - | - | - | - | - | - | | Qodo Review Standards | Best Practices / Custom Compliance | v2.1 | Beta | The separate review flows have been unified under PR code review, with best practices and compliance handled by the Review Standards. | GitHub | Onboard | | Agentic Review Experience | PR-Merge | v2.0 | GA | Replaced with: `/agentic_review`, `/agent_describe`, `/invoke_reviews` | GitHub | N/A | Yes. Migrating to Qodo v2 requires updating your repository configuration to enable the new review commands. Onboarding is designed to be incremental and safe. You can test the new review experience alongside your existing configuration before rolling it out across your organization. The onboarding process includes: * Updating repository configuration to enable the new review commands * Optionally testing the new experience manually in pull requests * Enabling the new configuration on a pilot repository * Rolling out configuration at the organization level * Removing previous review commands to prevent duplicate feedback For detailed, step-by-step instructions, see [Migrating to Qodo v2](/code-review/migrating-to-qodo-v2). Migrating gives you full access to available Qodo features and better performance and reliability. Without migrating, your existing installation will continue to work but you may not have access to all available features, and your installation will not appear on the [Repositories page](/governance/repositories). For step-by-step instructions, see the [migration guide](/install-qodo/migration-guide). | Qodo v1 Feature | Deprecated in Version | Change Summary | | - | - | - | | `/improve` command | v2.1 | Unified under PR review through the Review Standards. | | `/compliance` command | v2.1 | Unified under PR review through the Review Standards. | ### Code review experience Q\&A No. Qodo remains fully embedded in your pull request workflow. The review experience is enhanced, but your development process does not need to change. Review feedback is now unified and structured: * Issues are grouped by priority (e.g., Action Required, Remediation Recommended, Other). * Findings include clear explanations and direct references to code. * Reviews include agent-assisted fix prompts. * Compliance and code suggestions are no longer separate outputs. In Qodo v2, review is coordinated by a multi-agent system that: * Uses specialized review agents to evaluate pull requests from multiple perspectives. * Evaluates changes using repository context, pull request history, and organizational standards. * Consolidates findings into a single prioritized review. * Applies organizational standards through the Review Standards. | Qodo v1 | Qodo v2 | | - | - | | Compliance presented as checklist-style outputs. | Compliance integrated into prioritized findings. | | Code suggestions appeared as separate advisory comments. | Suggestions integrated into contextual findings. | | Findings not prioritized. | Issues ranked by impact and severity. | | Limited explanation of issues | Clear reasoning and resolution guidance provided | Yes. In Qodo v2 you will notice: * No separate Compliance or Code Suggestions sections. * A more coordinated and prioritized review flow. * Clearer explanations tied directly to code. * Emoji acknowledgment (👀) when invoking agent commands. Qodo provides a set of configuration options that allow teams to control how reviews behave and how feedback appears in pull requests. In addition, pull request commands can be used directly in PR comments to run reviews, generate summaries, ask questions about code changes, and perform other actions. For the complete list of supported configuration settings, see the [Configuration and Command Reference](/configuration/configuration-and-command-reference). For pull request commands and other ways to interact with Qodo in a PR, see the [Pull request command and interaction reference](/code-review/pr-command-and-interaction-reference). ### Review Standards Q\&A Review Standards are a core part of the Qodo v2 review experience. They: * Capture your organization’s standards. * Apply them consistently during pull request reviews. * Surface findings as structured rule violations. When rules are not supported in a given environment, Qodo uses Qodo v1 review logic. Qodo analyzes your organization's pull request history automatically using Rule Miner. When enabled, Rule Miner scans PR discussions across your repositories on a recurring schedule, identifies recurring review patterns, and generates suggested rules without any manual trigger. See [Generate rules from pull request history with Rule Miner](/governance/rule-enforcement/rule-miner) for details on how to enable and configure it. The `/scan_repo_discussions` command, which previously allowed manual rule discovery, has been deprecated. After onboarding, Qodo monitors the supported rule files across your repositories. When a supported file is updated or a new supported file is added and merged to your repository, new rules are automatically added to your Review Standards as active rules. **Single-tenant customers:** If you installed Qodo before the new setup wizard, additional setup may be required. For full details, see [Automatic rule updates from files](/governance/rule-enforcement/generate-and-manage-rules).  In Qodo v2, Best Practices and Custom Compliance files are replaced by Review Standards, which provide a more powerful and flexible way to define, manage, and enforce review policies across your organization.\ For existing customers, Qodo automatically ingests existing Best Practices and Custom Compliance files into the [Review Standards](/governance/rule-enforcement) framework, where these rules can then be reviewed and managed. If you previously used a central configuration repository (for example, `pr-agent-settings`) to store Best Practices or Custom Compliance rules across your organization, those rules are imported the same way. However, they remain scoped to that repository only. Use [bulk scope edit](/governance/rule-enforcement/generate-and-manage-rules#manage-rules-in-bulk) to apply them to the other repositories you want covered. # Qodo on-premises Source: https://docs.qodo.ai/on-prem Deploy Qodo in your own infrastructure with dedicated guides covering architecture, prerequisites, installation, integrations, and optional components. This guide covers deploying Qodo in a self-managed infrastructure environment. For cloud-hosted Git instances, see [Install Qodo](/install-qodo/install). Qodo on-premises allows you to deploy and manage Qodo within your organization's infrastructure while maintaining control over your deployment environment. #### Deploy Qodo Deploy the Qodo platform on Kubernetes and configure the components required for your environment. #### Connect your Git provider Connect Qodo to your source control platform by installing the Qodo app and configuring repository access. # Install the Azure DevOps integration for Qodo on-premises Source: https://docs.qodo.ai/on-prem/git-integration/install/azure-devops Install and configure the Azure DevOps integration for Qodo on-premises deployments. Qodo works natively with Azure DevOps, using Microsoft Entra ID to authenticate and authorize access to Azure DevOps APIs, pull request workflows, and Azure Boards work items. You can configure Qodo for a single repository or project, or expand it across multiple projects within your Azure DevOps organization. Setup typically takes around 20 minutes and includes creating a Microsoft Entra ID application, configuring authentication, and setting up webhooks. Once configured, Qodo monitors pull requests and publishes outputs such as reviews, descriptions, and improvement suggestions directly to your Azure DevOps pull requests. ## Prerequisites Before you begin, ensure you have: * A Qodo on-premises environment configured for Azure DevOps, including the Qodo webhook endpoint. Azure connection details (tenant ID, client ID, and client secret) are generated as part of the Microsoft Entra ID application registration during setup. * Permissions to create an app registration in Microsoft Entra ID. * Permissions to create users in Microsoft Entra ID and add users to the Azure DevOps organization (Microsoft Entra ID User Administrator and Azure DevOps Organization Owner), and access to the Azure DevOps projects that will be integrated with Qodo. ## Installation ### Step 1: Create an application registration Sign in to the [Microsoft Azure portal](https://portal.azure.com/). Use the search bar to navigate to **App registrations**. Click **New registration** and enter the following: * **Application Name:** Qodo * **Supported account types:** Select **Accounts in any organizational directory (Any Microsoft Entra ID tenant – Multitenant)** * **Application Logo:** [https://www.qodo.ai/wp-content/uploads/2025/03/qodo-logo.svg](https://www.qodo.ai/wp-content/uploads/2025/03/qodo-logo.svg) Navigate to **Manage → Authentication → Add Redirect URL**. In the popup: 1. Select **Web Applications → Web**. 2. Enter the callback URL. The webhook URL is unique per customer. For example: `https://admin..qodo.ai/api/ado/oauth/callback` 3. Click **Configure**. Navigate to **Manage → Certificates & secrets → New client secret**. In the popup: 1. Add a description and select an expiration. 2. Click **Add** to generate a client secret and save the Value. This will not be visible later. Microsoft Azure Certificates and secrets page showing new client secret creation Navigate to **Manage → API permissions → Add a permission**. In the popup: 1. Select the **Azure DevOps** card. 2. Add the Azure DevOps permission (`user_impersonation`). 3. Click **Add permissions**. 4. Click **Grant admin consent** for the directory. The **Overview** page displays all the relevant information for the following steps. Copy and save the **Application (client) ID** and **Directory (tenant) ID**. Microsoft Azure App registration Overview page showing Application and Directory IDs ### Step 2: Create a new user In the Microsoft Azure portal, create a new user named `Qodo` that will be used as a bot (service) account for Qodo. 1. Navigate to **Manage → Users → New user**. 2. In the popup, enter the user details and assign the **Cloud Application Administrator** role. ### Step 3: Create a service account The Microsoft Entra ID user that authenticates and creates the OAuth token must be the same user (same email / UPN) that is added to the Azure DevOps organization. If these do not match, the integration will not work. When using non-Azure domains (for example, Gmail), Azure may automatically create an `@onmicrosoft.com` user. Ensure that the same identity (email / UPN) is used consistently in both Microsoft Entra ID and Azure DevOps. Sign in to the Azure DevOps portal (for example, `https://dev.azure.com/`). Navigate to **Organization settings → Users** and add the `Qodo` user created in the previous step to the Azure DevOps organization. Assign the user **Access Level: Basic** and add it to the **Project Administrators** group for the project the bot should access. ### Step 4: Register the application with Qodo This step connects your Microsoft Entra ID application to your Qodo on-premises environment using the Qodo admin portal. Open an incognito or private browser window and verify that no Microsoft account is currently signed in. This ensures you authenticate using the correct service account. Sign in to Microsoft Entra ID using the dedicated service account created in Step 2. In the same browser window, navigate to your Qodo admin portal and open the Azure DevOps configuration section. Click **Edit** and provide the following details from the app registration in the Microsoft Azure portal: * **OAuth Application ID** (Application (client) ID from the **Overview** tab) * **OAuth Application Secret** (use the secret **value**, not the secret ID) * **Entra Tenant ID** (Directory (tenant) ID from the **Overview** tab) Qodo admin portal Azure DevOps configuration form with OAuth fields Click **Connect Azure DevOps** and then **Save**. Qodo admin portal Azure DevOps Connect button After successful registration, a new window will open displaying a **Webhook Secret Token**. Save this value. You will use it when configuring Azure DevOps webhooks in Step 5. ### Step 5: Set up webhooks Webhooks enable two-way communication between Azure DevOps and Qodo. Navigate to the Azure DevOps project where you want to install Qodo. Open **Project settings → Service hooks**. Create a new **Web Hook** subscription. Configure the webhook to trigger on the following pull request events: * PR Created * PR Updated * PR Commented * PR Merged Set the URL to your Qodo on-premises endpoint. For example: `https://qodo-merge..qodo.ai` Add the following HTTP header: ``` X-Webhook-Secret: ``` Click **Test** to verify that the webhook endpoint is reachable and correctly configured. Click **Finish** to create the webhook. ## Verify the installation Open a new pull request in the configured Azure DevOps project and confirm that Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Next steps [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install the Bitbucket Cloud integration for Qodo on-premises Source: https://docs.qodo.ai/on-prem/git-integration/install/bitbucket-cloud Install and configure the Bitbucket Cloud integration for Qodo on-premises deployments. This guide helps you install and configure Qodo on-premises with your Bitbucket Cloud workspace. Assuming your Qodo environment is already set up, configuring Bitbucket typically takes about 10 minutes. Once complete, Qodo processes pull requests and delivers actionable output such as code reviews and insights, directly in your pull requests. ## Prerequisites Before you begin, ensure you have: * **A Qodo on-premises deployment.** You will receive your Qodo on-premises URL from your Qodo Account Manager. It typically looks like: `qodo-merge.yourcompanyname.qodo.ai` * **System administrator access to your Bitbucket workspace.** ## Installation Navigate to **Settings** (cog wheel) → **Workspace settings**. Bitbucket workspace settings navigation On the left-hand side menu, navigate to **Installed apps**. Bitbucket workspace installed apps menu Enable **Development mode** to allow app installation, then click **Install app from URL**. Bitbucket Manage apps page with Development mode enabled and Install app from URL button Enter your Qodo on-premises URL and click **Install**. Bitbucket Install app from URL dialog with Qodo URL entered In the popup displayed, click **Grant access** to the app. Bitbucket Grant access popup for Qodo app Add your Bitbucket workspace ID to your Qodo on-premises configuration to complete the setup. Qodo is now enabled for all repositories within your Bitbucket workspace. ## Verify the installation ### Run a test pull request Open a new pull request in one of the integrated repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Next steps [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install the Bitbucket Data Center integration for Qodo on-premises Source: https://docs.qodo.ai/on-prem/git-integration/install/bitbucket-data-center Install guide for Qodo automated code review on Bitbucket Data Center, using the guided installation wizard. Qodo works directly with Bitbucket Data Center, using a dedicated Bitbucket account to post code review comments on pull requests. Depending on your setup, Qodo either creates this account for you using administrator credentials, or your administrator creates it and shares the credentials with Qodo. It relies on webhooks to deliver automated insights. You can configure Qodo for selected projects or across your entire Bitbucket Data Center server. Configuration typically takes around 5 minutes. Once installed, Qodo automatically processes pull requests and delivers actionable insights, such as code reviews, descriptions, and improvement suggestions, directly within your Bitbucket workflow. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * A Qodo environment configured for Bitbucket Data Center. * Bitbucket System Administrator access, or access to an administrator who can create a dedicated Qodo account and webhooks for you. ## Access the Bitbucket Data Center integration Log in to your Qodo portal. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **Bitbucket**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **Bitbucket**. For Bitbucket Data Center, select the self-hosted option that appears after you select **Bitbucket**. ## Install Qodo on Bitbucket Data Center Choose how the Qodo account is created. The rest of the wizard follows from this choice. Qodo creates and configures the account for you. Bitbucket Data Center installation wizard showing the Connect Bitbucket step, with automatic setup selected Enter your **server URL**, for example `https://bitbucket.example.com`. Enter your **administrator username** and **administrator password**. Qodo uses them once to: * Create a dedicated Qodo account in your Bitbucket server. * Give it access only to the projects or repositories you select in the next step. * Configure the required webhooks for your selected projects or repositories. Optionally, click **Test connection** to verify the server and sign-in before continuing. Qodo doesn't store your administrator credentials after setup. They're used only to create the account and configure webhooks, and you can change the password afterward. Click **Continue**. Bitbucket Data Center installation wizard showing the Choose repositories step, with the search bar and a list of projects to choose from Select which projects or repositories Qodo should review. * Use the search bar to find a specific project or repository, or browse the list of projects on your server. * Selecting a project includes every repository in it, including ones added later. * Selecting an individual repository includes only that repository. Click **Connect repositories**. Bitbucket Data Center installation wizard showing the Setup complete step, confirming the number of repositories connected Qodo creates the `qodo-bot` account and registers the required webhooks in Bitbucket. Once setup completes, Qodo confirms the number of repositories connected. Reviews are posted by the `qodo-bot` account. Qodo warns you before its token expires. * Click **Done**. Your Bitbucket administrator creates the account instead of sharing administrator credentials with Qodo. Bitbucket Data Center installation wizard showing the Connect Bitbucket step, with manual setup selected Enter your **server URL**, for example `https://bitbucket.example.com`. Ask your administrator to: * Create a new Bitbucket user account for Qodo. The username must contain `qodo` (for example, `qodo-bot`, `svc-qodo`, or `qodo_reviewer`). Qodo rejects a username without it. * Give this user **write access** to the projects or repositories you want Qodo to access. * Share the account's username and password with you. Enter the account's **username** and **password**, then click **Test connection** to verify. If the connection isn't verified, the cause is usually one of the following: * **Wrong credentials**: Bitbucket rejects the sign-in. Double-check the username and password and try again. * **Username doesn't contain `qodo`**: Qodo rejects the account. Use a username that contains `qodo` and try again. Click **Continue**. Bitbucket Data Center installation wizard showing the Choose repositories step, with the search bar and a list of projects to choose from Select which projects or repositories Qodo should review. You create the webhook for them yourself on the next step. * Use the search bar to find a specific project or repository, or browse the list of projects on your server. * Selecting a project includes every repository in it, including ones added later. * Selecting an individual repository includes only that repository. Click **Connect repositories**. Bitbucket Data Center installation wizard showing the Finish setup step, with the webhook URL, secret, and the pull request and repository events to enable Bitbucket requires additional permission to create webhooks beyond what the connected account has. Create the webhook yourself in Bitbucket, using the values Qodo provides here. * To connect a whole project: go to **Project settings** > **Webhooks** > **Create webhook**. * To connect a single repository: go to **Repository settings** > **Webhooks** > **Create webhook**. Configure the webhook with the following values: * **URL**: Paste the URL Qodo displays into the webhook URL field. * **Secret**: Paste the secret Qodo displays into the webhook secret field, copied exactly as shown. Qodo uses it to verify that webhook events came from your Bitbucket server. * **Events**: Under **Pull request**, enable Opened, Modified, Source branch updated, Merged, Declined, and Comment added. Under **Repository**, enable Push. Once the webhook is created, Qodo starts receiving pull request and repository events from Bitbucket. A project-level webhook automatically covers all repositories in that project, including ones added later. Project-level webhooks require Bitbucket 8.8 or later. On older versions, create a webhook for each repository instead. * Click **Done**. Qodo uses the Bitbucket account you created to access repositories and post reviews. If you change that account's password in Bitbucket, reconnect this server in Qodo with the new password. Qodo is now active on the repositories in the projects you selected. To add more projects, return to this wizard at any time and run a new installation with the updated scope. Projects that already have Qodo installed are not available for selection. To reduce scope, remove the installation and create a new one. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new pull request in one of the connected repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Next steps * [Repositories page](/governance/repositories): Manage which repositories Qodo is active on, or remove an installation. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install the Gerrit integration for Qodo on-premises Source: https://docs.qodo.ai/on-prem/git-integration/install/gerrit Install and configure the Gerrit integration for Qodo on-premises deployments. This wizard can be used for Qodo multi-tenant, single-tenant, and on-premises deployments. Gerrit is a self-hosted, web-based code review tool for Git repositories where review is organized around changes (individual patch sets) rather than pull requests, and repositories are called projects. This guide helps you connect Qodo to your Gerrit instance so it can review changes and deliver findings directly where you already work. Assuming your Qodo environment is already set up, connecting Gerrit involves creating a dedicated Qodo user in Gerrit, connecting it to Qodo, and registering a webhook so Gerrit can notify Qodo of new changes. ## Prerequisites Before you begin, ensure you have: * A Qodo environment configured for Gerrit. If you're unsure of your environment type, contact your Qodo Account Manager. * A Gerrit instance where you have administrator access, to create a dedicated user, grant it permissions, and register a webhook. ## Access the Gerrit integration Log in to your Qodo portal. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **Gerrit**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **Gerrit**. ## Install Qodo on Gerrit Gerrit wizard step 1, Create a Qodo user, showing required ref and label permission tables In your Gerrit server, create a new user named `Qodo`. This user will be used to post review comments on Qodo’s behalf in the Gerrit UI. Grant the user the following permissions: | Ref pattern | Purpose | | - | - | | `refs/changes/*` | Access patchset commits for code review and analysis | | `refs/heads/*` | Read branch content, including the `.pr_agent.toml` configuration file | | `refs/tags/*` | Read tags for version context in PR descriptions | | Label | Range | Purpose | | - | - | - | | **Code-Review** | -2..+2 | Post review comments and findings | | **Verified** | -1..+1 | Mark verification status (optional) | | Access category | Ref pattern | Purpose | | - | - | - | | **Edit Hashtags** | `refs/heads/*` | Apply hashtags with `/generate_labels` | Generate an HTTP password for the user. You'll enter its username and password in the next step. Back in the wizard, click **Continue**. Gerrit wizard step 2, Connect to Gerrit, showing Gerrit URL, username, HTTP token, and API path fields Enter the following, then click **Connect to Gerrit**: * **Gerrit URL**: Your Gerrit instance URL (for example, `https://gerrit.example.com`). * **Username**: The dedicated Gerrit user created in the previous step. * **HTTP token**: The user's HTTP password. * **API path** (optional): Path to Gerrit's authenticated REST API. If your Gerrit instance is served under a sub-path, add that to the Gerrit URL above instead of this field. Qodo validates the credentials against your Gerrit server, then stores them securely, not in the Qodo portal itself. Gerrit wizard step 3, Import repositories, showing the repositories-added confirmation and webhook setup commands Qodo imports every Gerrit project the connected user can access. Then, register a webhook on your Gerrit server so Qodo receives change events: Copy the **Webhook URL** shown in the wizard. Run the following command against your Gerrit server, replacing the URL and credentials with your own: ```bash theme={null} curl --location --request PUT \ '/a/config/server/webhooks~projects/All-Projects/remotes/qodo' \ --header 'Content-Type: application/json; charset=UTF-8' \ --user ':' \ --data-raw '{"url":"","events":["patchset-created","comment-added","wip-state-changed","change-merged","change-abandoned"],"maxTries":"3","sslVerify":"true"}' ``` This targets **All-Projects**, Gerrit's global config project. Webhook configuration [is inheritable](https://gerrit.googlesource.com/plugins/webhooks/+doc/master/src/main/resources/Documentation/config.md): it applies to every repository, without requiring per-project configuration. To scope the webhook to specific repositories, replace `All-Projects` in the URL with a repository's name and repeat this for each repository to include. Verify it was created: ```bash theme={null} curl --user ':' '/a/config/server/webhooks~projects/All-Projects/remotes' ``` Replace `All-Projects` with a specific repository name if that's what you registered the webhook against. Back in the wizard, click **Done**. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new change in one of the connected projects and confirm that Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or change summary directly on the change. ## Troubleshooting If Qodo is not responding: * Confirm the webhook is registered on the project you expect (`All-Projects`, or a specific repository). See [Install Qodo on Gerrit](#install-qodo-on-gerrit) for the verify command. * Confirm the HTTP credential used hasn't expired. ## Manage repositories Every Gerrit project the connected user can access is imported when you connect (see [Install Qodo on Gerrit](#install-qodo-on-gerrit)), but only projects covered by the webhook actually receive change events. * To cover only specific projects, register the webhook against those projects by name instead of `All-Projects`. * To turn code review on or off for a project already covered by the webhook, without touching the webhook itself, use the **Code review** toggle on the [Repositories page](/governance/repositories) in the Qodo portal. ## Next steps * [Using Qodo in code reviews](/code-review/use-qodo-in-prs): Get the most out of Qodo. * [Install and configure Qodo](/configuration): Use the shared configuration guides to configure Qodo for your organization. # Install the GitHub integration for Qodo on-premises Source: https://docs.qodo.ai/on-prem/git-integration/install/github Install and configure the GitHub integration for Qodo on-premises deployments. This guide helps you install and configure Qodo on-premises with GitHub. You can install it for a single repository or expand it across multiple organizations as needed. Assuming your Qodo environment is already set up, configuring GitHub typically takes about 20 minutes. This includes creating a GitHub App, configuring webhooks, setting permissions, and installing the app. Once complete, Qodo processes pull requests and delivers actionable output such as code reviews and insights, directly in your PRs. ## Prerequisites Before you begin, ensure you have: * **A Qodo on-premises deployment.** You will receive your Qodo on-premises URL from your Qodo Account Manager. It typically looks like: `qodo-merge.yourcompanyname.qodo.ai` * **System administrator access to your GitHub organization.** ## Installation ### Step 1: Navigate to the GitHub Apps section Log in to GitHub using an administrative account. Click your profile picture → **Your organizations**. GitHub profile picture menu with Your organizations option Select your organization. GitHub organizations list Click **Settings**. GitHub organization settings button Go to **Developer settings → GitHub Apps**. GitHub Developer settings with GitHub Apps menu item Click **New GitHub App**. ### Step 2: Create the GitHub App Register a new GitHub App with the following settings: * **App name:** Qodo * **Homepage URL:** `https://qodo.ai` GitHub App registration form with App name and Homepage URL fields Configure the webhook: * Check the **Active** checkbox. * **Webhook URL:** `https://qodo-merge.[yourcompanyname].qodo.ai/api/v1/github_webhooks` * **Secret:** generate a strong random secret and save it. You will need it to configure the Qodo service. * Select **Enable SSL verification**. GitHub App webhook configuration with URL, secret, and SSL verification fields Set the following repository permissions: | Permission | Access | | - | - | | Actions | Read-only | | Checks | Read-only | | Contents | Read and write | | Discussions | Read and write | | Issues | Read and write | | Pull requests | Read and write | Subscribe to the following events: GitHub App event subscriptions page Under **Where can this GitHub App be installed?**, choose **Any account**. This avoids creating a separate application per organization. GitHub App installation scope selection showing Any account option Click **Create GitHub App**. GitHub Create GitHub App button ### Step 3: Post-creation actions Note the **App ID**. You will need it for Qodo configuration. GitHub App details page showing App ID Generate a **private key**. You will need it for Qodo configuration. GitHub App private key generation section Upload the Qodo logo to use on GitHub posts. GitHub App logo upload field ### Step 4: Install the app Go to **Your Organization → Settings → Developer Settings → GitHub Apps**. GitHub Developer Settings GitHub Apps page Click the Qodo app name. GitHub Apps list showing Qodo app Click **Install** on each relevant organization. GitHub App install page showing Install button ### Step 5: Configure repository access Go to **Settings → Developer Settings → GitHub Apps** in your organization. Click **Configure** on the Qodo app. GitHub Apps list with Configure button for Qodo app Under **Repository Access**, choose **Only select repositories** and select the repositories to include. GitHub App repository access section with Only select repositories option ### Step 6: Configure your Qodo instance Add the following details to your Qodo on-premises configuration: ``` # GitHub App ID app_id = # Shared secret for webhook verification webhook_secret = "your-webhook-secret-here" # Private key (.pem file) # Organization name(s) where the app is installed ``` The organization name is available in your organization's settings in GitHub. You can provide multiple organizations if the app is installed in more than one. For production environments, follow your organization's secret management procedures to securely store these credentials. ## Verify the installation Open a new pull request in one of the configured repositories and confirm that Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or PR summary directly on the pull request. ## Troubleshooting If Qodo is not responding: * Verify that the pull request is in a repository selected in the app settings. * Contact your Qodo Account Manager for assistance. ## Next steps [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install the GitLab Server integration for Qodo on-premises Source: https://docs.qodo.ai/on-prem/git-integration/install/gitlab Install guide for Qodo automated code review on a self-hosted GitLab Server instance, using the guided installation wizard. This wizard can be used for Qodo multi-tenant, single-tenant, and on-premises deployments on GitLab Server. For `gitlab.com`, see . Qodo works directly with GitLab Server, using a dedicated GitLab service account with Developer-level permissions to post code review comments on merge requests. Qodo can create this account for you, or your GitLab administrator can create it. You can configure Qodo for selected repositories or across your entire GitLab group. Configuration typically takes around 5–10 minutes. Once installed, Qodo automatically processes merge requests and delivers actionable insights, such as code reviews, descriptions, and improvement suggestions, directly within your GitLab workflow. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * The GitLab access that matches how the Qodo service account is created: * Automatic setup: Instance Admin access, needed for Qodo to create its service account and set up webhooks. * Manual setup: The Owner role on each group you connect, or the Maintainer role on each repository. Your GitLab administrator creates an instance service account for Qodo. * Network access from Qodo to your GitLab URL. ## Access the GitLab integration Log in to your Qodo portal. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **GitLab**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **GitLab**. Then select the self-managed option that appears after you select **GitLab**. ## Install Qodo on GitLab Server Enter your **GitLab URL** (for example, `https://gitlab.example.com`), then choose how the Qodo service account is created. Qodo creates the service account for you, using an instance Admin's access token. GitLab wizard step 1 on GitLab Server, Connect GitLab, with Automatic setup selected Under **How should the Qodo service account be created?**, select **Automatic setup**. Qodo uses your token to: * Create a dedicated Qodo service account on your instance. * Give it access only to the groups or repositories you select. * Configure the required webhooks. Sign in as an instance Admin and click **Create a token in GitLab** to open your GitLab instance's access token settings directly. If your instance is on GitLab 16.6 or earlier, use **Create a token in GitLab 16.6 or earlier** instead. The `api` scope is required and preselected. Leave it selected when you create the token. This token is used once, to create the Qodo service account, and is never stored. You can set a short expiry, for example 1 day, and revoke it once installation completes. Paste the token under **Your personal access token** and click **Next**. Your GitLab administrator creates the service account, so you don't need instance Admin access. GitLab wizard step 1 on GitLab Server, Connect GitLab, with Manual setup selected and the administrator instructions shown Under **How should the Qodo service account be created?**, select **Manual setup**. Before continuing, ask your GitLab administrator to: * In Admin > Service accounts, create a dedicated instance [service account](https://docs.gitlab.com/user/profile/service_accounts/) for Qodo that isn't an administrator. On GitLab Community Edition, which has no service accounts, create a dedicated regular user instead. * Create a personal access token for that account with the `api` scope, expiring at least two days from today. * Share the token with you. Use an instance service account, not a group or project one. GitLab limits group and project service accounts to their own group or project. Qodo reuses the same account whenever you connect more groups or repositories, and connecting outside that group or project can fail. Qodo checks each of the following when you connect. Any failure blocks the connection. * The token is a personal access token on the service account itself, not a group or project access token. * The token has the `api` scope, is active, and expires at least two days from today. * The token doesn't belong to an instance administrator, or to the account you sign in with. * On GitLab Enterprise Edition, the token belongs to an actual service account, not a person's account. Qodo can't check whether the account is an instance service account. Make sure your administrator creates one, as described above. Enter your own personal access token and the service account's token. Your token needs the `api` scope, and you need the Owner role on each group you connect, or the Maintainer role on each repository. Qodo asks for your token again when you later add or remove groups and repositories, or uninstall Qodo. You need the same role then. Qodo adds the service account to the groups or repositories you select, so it needs no other access. Use this service account and its token for Qodo only. * Qodo renews the token before it expires, which invalidates your copy. When Qodo is uninstalled, it revokes the token and leaves the account in place. * If the instance already has an installation, Qodo keeps using its existing service account. A new token for that account replaces the stored one. A token for a different account is ignored. * If the service account stops working and you can't create a working token for it, uninstall and reinstall Qodo, unless you can sign in with an instance Admin account. Click **Next**. GitLab wizard step 2, Select repositories, showing the group list with one group selected, the search bar, and Select all Find and select what to connect: * Use the search bar to find a specific group or repository, or browse the list of top-level groups you have access to. * Select a group to connect every repository within it, or drill into a group to select individual repositories. * Select **Select all** to connect everything you have access to in one step. On GitLab Community Edition and free-tier instances, which don't support group hooks, this step appears as "Select repositories" and Qodo creates a hook for each repository you select. On tiers with group hooks, it appears as "Select groups and repositories", and selecting a group creates a group hook. Repositories in personal namespaces aren't supported. Click **Next**. GitLab wizard step 3, Verify connection, confirming that GitLab Self-Managed is connected and that pull request indexing started in the background Qodo confirms it's connected to your selected repositories and groups, and starts pull request indexing in the background. Click **Next**. Qodo is now active on the repositories in the groups you selected. To connect more repositories under an existing installation, use [Manage the repositories in an installation](/governance/repositories/installations#manage-the-repositories-in-an-installation) on the Repositories page. To connect a different group, return to this wizard. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new merge request in one of the connected repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or MR summary directly on the merge request. ## Troubleshooting If Qodo doesn't respond on the merge request, check that GitLab can reach Qodo's webhook URL: In GitLab, navigate to the webhook settings of the connected group or repository. Copy the URL of the webhook Qodo created. The URL is different for each Qodo installation. Confirm that your network allows GitLab to reach that URL. ## Next steps * [Repositories page](/governance/repositories): Manage which repositories Qodo is active on, or remove an installation. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Install the GitLab Cloud integration for Qodo on-premises Source: https://docs.qodo.ai/on-prem/git-integration/install/gitlab-cloud Install guide for Qodo automated code review on GitLab Cloud, for Qodo on-premises deployments. This wizard can be used for Qodo multi-tenant, single-tenant, and on-premises deployments on GitLab Cloud (`gitlab.com`). For a self-hosted instance, see . Qodo works directly with GitLab, using a dedicated GitLab service account with Developer-level permissions to post code review comments on merge requests. Qodo creates this account automatically using a personal access token you provide during setup, then discards the token. You can configure Qodo for selected repositories or across your entire GitLab group. Configuration typically takes around 5–10 minutes. Once installed, Qodo automatically processes merge requests and delivers actionable insights, such as code reviews, descriptions, and improvement suggestions, directly within your GitLab workflow. ## Prerequisites Before you begin, ensure you have: * Access to your Qodo portal. * The Owner role on each top-level GitLab group you connect, needed for Qodo to create its service account in that group and set up webhooks. * Network access from Qodo to `gitlab.com`. ## Access the GitLab integration Log in to your Qodo portal. Start the installation wizard in one of the following ways: * **From the onboarding wizard**: If you're an organization admin signing in for the first time, the onboarding wizard opens automatically. In the Connect Git step, select **GitLab**. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **From the homepage**: On the homepage, in the top right-hand side, click the **+** button next to Git providers. On the selection page, choose **GitLab**. ## Install Qodo on GitLab Cloud GitLab wizard step 1, Connect GitLab, showing the GitLab URL and personal access token fields Confirm the **GitLab URL** is `https://gitlab.com`. Sign in as a group Owner. Click **Create a token in GitLab** to open your GitLab access token settings directly. The `api` scope is required and preselected. Leave it selected when you create the token. This token is used once, to create the Qodo service account, and is never stored. You can set a short expiry, for example 1 day. Paste the token under **Your personal access token** and click **Next**. GitLab wizard step 2, Select repositories, showing the group list with one group selected, the search bar, and Select all Find and select what to connect: * Use the search bar to find a specific group or repository, or browse the list of top-level groups you have access to. * Select a group to connect every repository within it, or drill into a group to select individual repositories. * Select **Select all** to connect everything you have access to in one step. On GitLab free-tier groups, which don't support group hooks, this step appears as "Select repositories" and Qodo creates a hook for each repository you select. On tiers with group hooks, it appears as "Select groups and repositories", and selecting a group creates a group hook. Repositories in personal namespaces aren't supported. Click **Next**. GitLab wizard step 3, Verify connection, showing the confirmation banner and per-group connection status Qodo confirms it's connected to your selected repositories and groups. * Each one shows its status: **Already connected** from a previous installation, or **Connected** if newly connected. * Installing across multiple top-level groups sets up each group as a separate installation, appearing as its own item on the [Installations tab](/governance/repositories/installations). * Click **Done**. Qodo is now active on the repositories in the groups you selected. To connect more repositories under an existing installation, use [Manage the repositories in an installation](/governance/repositories/installations#manage-the-repositories-in-an-installation) on the Repositories page. To connect a different group, return to this wizard. If you're connecting your Git provider as part of the onboarding wizard, the wizard continues to the next onboarding step once the connection completes. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## What happens after you connect Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Verify the installation Open a new merge request in one of the connected repositories and confirm Qodo is triggered automatically. Add a comment using one of the supported commands: * `/agentic_describe` * `/agentic_review` Qodo should respond with a review or MR summary directly on the merge request. ## Troubleshooting If Qodo doesn't respond on the merge request, check that GitLab can reach Qodo's webhook URL: In GitLab, navigate to the webhook settings of the connected group or repository. Copy the URL of the webhook Qodo created. The URL is different for each Qodo installation. Confirm that your network allows GitLab to reach that URL. ## Next steps * [Repositories page](/governance/repositories): Manage which repositories Qodo is active on, or remove an installation. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Configure PostgreSQL for code review (optional) Source: https://docs.qodo.ai/on-prem/git-integration/set-up-postgres-database Configure PostgreSQL to enable persistent findings, incremental reviews, and other database-backed code review capabilities. PostgreSQL is optional. Qodo Code Review works without a database, but some capabilities are unavailable or rely on a less reliable fallback that parses findings from pull request comments. With PostgreSQL configured, Qodo Code Review can: * Persist review findings * Track incremental reviews * Measure suggestion adoption * Deduplicate findings across reviews * Manage concurrent reviews ## Before you begin **What data is stored in the database?** The database contains two tables: * **`findings`**: Stores the review findings generated by the agentic review. Each finding includes a title, description, category (such as correctness, security, or performance), and severity level. For code context, each finding stores a diff reference with the file path, line range, and a code snippet in unified diff format. Findings also store supporting evidence with citations, fix suggestions and prompts for downstream agents, and workflow metadata such as deduplication decisions, conversion approvals, attribution status, and Git provider comment IDs. * **`review_runs`**: Stores review execution metadata, including the PR URL, commit SHA, start time, status, and request ID. This data is used for concurrency management and incremental review tracking. Only the specific lines referenced by a finding are persisted. No full file contents or complete diffs are stored. **Which versions of Qodo Code Review are supported?** | Feature | Minimum version | | - | - | | Findings DB | 1.6.0 | | Concurrency management | 1.28.0 | | Incremental review | 1.63.0 | ## Set up the database ### Option A: Already have a Qodo Aware database If you already deployed a PostgreSQL instance for Qodo Aware, you can reuse the same PostgreSQL server. **Step 1: Create a dedicated database and user** On your existing PostgreSQL instance, run the following as a `superuser`: ```sql theme={null} -- Run as superuser CREATE ROLE qodo_merge_user LOGIN PASSWORD 'your-password'; GRANT qodo_merge_user TO postgres; -- replace 'postgres' with your superuser CREATE DATABASE qodo_merge OWNER qodo_merge_user; ``` Then reconnect as the newly created user and lock down the schema: ```sql theme={null} -- Run as qodo_merge_user \c qodo_merge REVOKE CREATE ON SCHEMA public FROM PUBLIC; GRANT USAGE, CREATE ON SCHEMA public TO qodo_merge_user; ``` **Step 2: Configure Qodo Review** Proceed to the [Configure Qodo Review](#configure-qodo-review) section below. ### Option B: Fresh PostgreSQL setup If you don't have an existing PostgreSQL instance, you need to provision one. **Step 1: Recommended instance configuration** This can be a managed service (AWS RDS, GCP Cloud SQL, Azure Database for PostgreSQL) or a self-hosted instance. | Resource | Minimum | | - | - | | PostgreSQL version | 17 or later | | CPU | 4 vCPU | | RAM | 8 GB | | Disk | 100 GB | **Step 2: Allow network access** * Enable TCP connections on port 5432. * Whitelist access from the Kubernetes cluster where Qodo Review is deployed. **Step 3: Create the database and user** Run the following as a `superuser`: ```sql theme={null} -- Run as superuser CREATE ROLE qodo_merge_user LOGIN PASSWORD 'your-password'; GRANT qodo_merge_user TO postgres; -- replace 'postgres' with your superuser CREATE DATABASE qodo_merge OWNER qodo_merge_user; ``` Then reconnect as the newly created user and lock down the schema: ```sql theme={null} -- Run as qodo_merge_user \c qodo_merge REVOKE CREATE ON SCHEMA public FROM PUBLIC; GRANT USAGE, CREATE ON SCHEMA public TO qodo_merge_user; ``` The Alembic migration will auto-create tables, but creating the database and setting permissions explicitly is recommended for clarity and security. ## Configure Qodo review These steps apply to both option A and option B. **Step 1: Add database credentials to `.secrets.toml`** Add the following section to your `.secrets.toml` file: ```toml theme={null} [database] password = "your-password" ``` **Step 2: Enable database persistence** Add the following environment variable to the `configMaps` section of your `values.yaml`: ```yaml theme={null} configMaps: main: REVIEW_AGENT__ENABLE_DATABASE_PERSISTENCE: "true" DATABASE__HOST = "your-postgres-host" DATABASE__PORT = "5432" DATABASE__DATABASE = "qodo_code_review" DATABASE__USERNAME = "qodo_code__review_user" ``` **Step 3: Restart the server** Restart the Qodo Review pods to pick up the new secret and configuration. **Step 4: Add a database migration job** Database schema migrations must run before the Qodo Review application starts, on every deployment. Add the following job to your `values.yaml`: ```yaml theme={null} jobs: db-migration: annotations: "helm.sh/hook": pre-install,pre-upgrade "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded command: - "python" - "-m" - "alembic" - "-c" - "pr_agent/database/migrations/alembic.ini" - "upgrade" - "head" ``` This runs as a Helm `pre-install/pre-upgrade` hook, ensuring the database schema is up to date before the application starts. Database credentials must be available to the job. The migration job runs as a Helm `pre-install/pre-upgrade` hook (weight "-5"), which means it executes before the main deployment resources are created. The Kubernetes secret and configmap referenced by the job must already exist in the namespace before running `helm install` for the first time. Create them manually (steps 1–2 above) before your initial deployment. On subsequent upgrades, they will already be present. **Step 5: Deploy** Deploy or upgrade using the standard Helm commands: ```bash theme={null} helm upgrade --install qodo-merge ./module-.tgz \ -f ./values.yaml \ -n qodo-merge ``` ## Verify **Check the migration job** After deployment, confirm the migration job completed successfully: ```bash theme={null} kubectl get jobs -n qodo-merge ``` The `db-migration` job should show `1/1` completions. ## Test the app Run the `/agentic_review` command and verify Qodo Review runs properly. # Git integrations for on-premises Source: https://docs.qodo.ai/on-prem/git-integration/setup-the-git-integration An introduction to Git provider integrations for Qodo on-premises. Connect Qodo on-premises to your Git provider to enable code reviews in your organization's repositories. ## Before you start Make sure you have: * A deployed Qodo on-premises environment. * Access to your organization's Git provider. * The permissions required to configure the integration. * The credentials and configuration values required by your Git provider. ## Supported Git providers Choose your Git provider to follow the installation and configuration steps: * [Install the GitHub integration](./install/github) * [Install the GitLab Cloud integration](./install/gitlab-cloud) * [Install the GitLab Server integration](./install/gitlab) * [Install the Bitbucket Cloud integration](./install/bitbucket-cloud) * [Install the Bitbucket Data Center integration](./install/bitbucket-data-center) * [Install the Azure DevOps integration](./install/azure-devops) * [Install the Gerrit integration](./install/gerrit) Each guide covers the provider-specific requirements and configuration needed to connect Qodo to your Git provider. ## Related resources Before configuring a Git integration, make sure you have completed the [Qodo on-premises installation overview](../qodo-on-premise/installation-process-overview). # Helm chart configuration reference Source: https://docs.qodo.ai/on-prem/on-prem-helm-chart-reference Reference documentation for the Qodo on-premises Helm chart. This reference provides a complete list of customer-serviceable Helm values, default settings, and configuration options for the Qodo Helm chart. If you're deploying Qodo for the first time, see [Deploy Qodo using Helm](qodo-on-prem-helm-chart-overview) for step-by-step installation instructions. | Key | Type | Default | Description | | - | - | - | - | | `global.baseDomain` **(required)** | string | | Controls the base domain used to derive all public hostnames. A wildcard DNS record and TLS certificate for \*.\ covers the entire stack. | | `global.tlsSecretName` | string | `"qodo-tls"` | Controls the pre-created TLS Secret used by every Ingress host. With cert-manager, this is the Secret it mints the certificate into. | | `global.caBundle` | string | | Controls the complete PEM trust bundle for outbound TLS from Qodo services, replacing the containers' default trust store. Must include public roots before appending private CA certificates. | | `global.pullSecret` | string | `"qodo-pull"` | Controls the Docker registry Secret used to pull every image. The name is fixed in this packaging and cannot be changed. | | `global.imageProxyPrefix` | string | `"artif-reg-self-hosted.codium.ai/proxy/codium-stack/"` | Controls the registry prefix prepended to every image reference. Change only when mirroring all images to your own registry. | | `global.composeImageProxyPrefix` | boolean | `true` | Controls whether `imageProxyPrefix` is prepended to every image at render time. Must remain `true` unless using fully-qualified image repositories. | | `global.podSecurityContext` | object | `{}` | Controls the pod-level securityContext applied to every Pod, including migration and provisioning Jobs. Set when the cluster requires Pods to declare security IDs, such as under an OpenShift restricted SCC. | | `global.containerSecurityContext` | object | `{}` | Controls the container-level securityContext applied to every container and initContainer. Separate from `podSecurityContext` per the Kubernetes API split between pod-only and container-only fields. | | `global.affinity` | object | `{}` | Controls affinity rules applied to every workload. Uses standard Kubernetes affinity syntax; a per-component affinity takes precedence. | | `global.tolerations` | array | `[]` | Controls tolerations applied to every workload. Replaces rather than extends per-component tolerations; pair with `nodeSelector` for dedicated node pools. | | `global.deploymentMode` | string | `"helm"` | Controls the deployment mode. Set `argocd` for `helm template` rendering with Argo CD, which requires manual Secret management and an external database. | | `global.features.restrictRepoPagesToAdmins` | boolean | `false` | Controls whether repository pages in the portal are restricted to organization owners. | | `global.repositoryAccess.enabled` | boolean | `false` | Controls the repository-access worker for account-linked repository visibility. Requires configured GitHub installations with repository access permissions. | | `global.repositoryAccess.filteringEnabled` | boolean | `false` | Controls enforcement of per-user repository access filtering. Enable only after verifying account linking and access calculation; requires `repositoryAccess.enabled`. | | `global.repositoryAccess.queue.topic` | string | `"qodo-platform-user-to-allowed-repos"` | Controls the shared queue topic for repository-access events. Use a deployment-specific name when sharing a message broker. | | `global.repositoryAccess.queue.subscription` | string | `"qodo-platform-user-to-allowed-repos"` | Controls the queue subscription suffix. The queue name is `.`; changing either name does not migrate an existing queue. | | `global.images.engine-indexer.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-engine-indexer"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.engine-indexer.tag` | string | `"2.68.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.engine-pr-kn-consumer.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-engine-indexer"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.engine-pr-kn-consumer.tag` | string | `"2.68.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.engine-retriever.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-engine-context-retriever"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.engine-retriever.tag` | string | `"2.68.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.git-event-consumer.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-platform"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.git-event-consumer.tag` | string | `"2.356.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.gitway.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/git-gateway-gitway"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.gitway.tag` | string | `"1.35.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.litegit.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/litegit-gateway"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.litegit.tag` | string | `"0.298.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.platform.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-platform"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.platform.tag` | string | `"2.356.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.user-to-allowed-repos-consumer.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-platform"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.user-to-allowed-repos-consumer.tag` | string | `"2.356.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.portal.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-platform-fe"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.portal.tag` | string | `"1.205.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.qar.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-agent-runtime"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.qar.tag` | string | `"1.25.6"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.pr-agent-agentic.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/pr-agent"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.pr-agent-agentic.tag` | string | `"3.14.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.qodo-git.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/pr-agent"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.qodo-git.tag` | string | `"3.14.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.qodo-git-sidecar.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/pr-agent-sidecar"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.qodo-git-sidecar.tag` | string | `"3.14.0"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.images.qodo-telemetry.repository` | string | `"us-central1-docker.pkg.dev/codium-production/codium-repo-self-hosted/qodo-telemetry"` | Controls the container image repository for this workload. Override only under Qodo guidance. | | `global.images.qodo-telemetry.tag` | string | `"0.6.1"` | Controls the container image tag for this workload. Override only under Qodo guidance. | | `global.ingress.enabled` | boolean | `true` | Controls whether Kubernetes Ingress resources are created. Set `false` on OpenShift and enable `global.route.enabled` instead; the chart refuses to render both. | | `global.ingress.className` | string | | Controls the Kubernetes IngressClass. Leave empty to use the cluster default. | | `global.ingress.annotations` | object | `{}` | Controls annotations added to every generated Ingress resource. | | `global.ingress.appHostname` | string | | Controls the public Qodo Portal hostname. Leave empty to derive as app.\. | | `global.ingress.apiHostname` | string | | Controls the public API hostname. Leave empty to derive as api.\. | | `global.ingress.portalApiHostname` | string | | Controls the public portal backend hostname. Portal and platform URLs are derived from this value automatically. | | `global.ingress.authHostname` | string | | Controls the public sign-on hostname and OIDC issuer. Changing it after provisioning is not supported. | | `global.ingress.gitHostname` | string | | Controls the webhook hostname for inbound git provider events. The entire host is routed to the webhook receiver and cannot be shared with other hosts. | | `global.ingress.sdkHostname` | string | | Controls the public Qodo Agent Runtime hostname for SDK and CLI clients. Leave empty to derive as sdk.\. | | `global.route.enabled` | boolean | `false` | Controls OpenShift Route creation as an alternative to Ingress. Requires `global.ingress.enabled: false`; the chart refuses to render both. | | `global.route.annotations` | object | `{}` | Controls annotations added to every generated OpenShift Route resource. | | `global.route.tls.termination` | string | `"edge"` | Controls TLS termination mode on OpenShift Routes. Only `edge` is supported; `reencrypt` and `passthrough` are refused. | | `global.route.tls.insecureEdgeTerminationPolicy` | string | `"Redirect"` | Controls the OpenShift router behavior for plain HTTP requests. Accepts `Redirect`, `None`, or `Allow`. | | `global.nodeSelector.kubernetes.io/arch` | string | `"amd64"` | Controls the architecture node selector applied to every workload. Only amd64 images are available; this constraint cannot be removed via values. | | `global.jobScheduling.nodeSelector` | object | `{}` | Controls extra node selection for migration, provisioning, and maintenance Jobs. Merged on top of the installation-wide `nodeSelector`. | | `global.jobScheduling.tolerations` | array | `[]` | Controls extra tolerations for migration, provisioning, and maintenance Jobs. Appended to the installation-wide tolerations list. | | `global.repositorySync.schedule` | string | `"0 * * * *"` | Controls the cron schedule for Git installation reconciliation and repository onboarding. Overlapping runs are blocked by `concurrencyPolicy: Forbid`. | | `global.repositorySync.rulesImportEnabled` | boolean or string (`preserve`) | `"preserve"` | Controls automatic repository standards ingestion. `true` enables onboarding, `false` pauses it, `preserve` keeps the existing database value. | | `global.rabbitmqMigration.mode` | string | `"automatic"` | Controls how Helm handles legacy workflow queue migration during upgrades. `validate` makes the hook read-only and blocks the upgrade until queues are migrated separately. | | `global.rabbitmqMigration.drainTimeoutSeconds` | integer | `600` | Controls the maximum wait in seconds for in-flight workflow messages during automatic queue migration. Expiry fails the Helm upgrade. | | `global.externalDatabase.host` **(required)** | string | | Controls the external PostgreSQL server hostname. | | `global.externalDatabase.port` | integer | `5432` | Controls the external PostgreSQL port. Some components still require a proxy or Service listening on port 5432. | | `global.externalDatabase.adminUser` **(required)** | string | `"postgres"` | Controls the database user for application database creation. Requires the `CREATEDB` privilege; set explicitly for managed database services. | | `global.externalDatabase.sslMode` | string | `"require"` | Controls the PostgreSQL TLS mode. `require` encrypts without verifying the server certificate or hostname. | | `global.externalDatabase.existingSecret` | string | `"qodo-db-admin"` | Controls the Secret containing `POSTGRES_PASSWORD`. The default name is required by components that reference it directly. | | `global.externalDatabase.qarDatabase` | string | `"qar"` | Controls the database used exclusively by Qodo Agent Runtime. Created during db-init on the shared server. | | `global.externalDatabase.qarUser` | string | | Controls an optional dedicated Qodo Agent Runtime database login. The role must not have `SUPERUSER` or `BYPASSRLS`. | | `global.externalRedis.host` | string | | Controls the external Redis hostname. Also set `redis.enabled: false` when using an external instance; port 6379 is fixed. | | `global.entra.type` | string | `"entra"` | Controls the identity provider connector type. Use `entra` for commercial Microsoft cloud or `generic-oidc` for another OIDC issuer. | | `global.entra.name` **(required)** | string | | Controls the identity provider display name. Changing it after installation registers a second provider instead of renaming. | | `global.entra.clientId` **(required)** | string | | Controls the application client ID for the identity provider. | | `global.entra.tenantId` | string | | Controls the Entra directory tenant ID. Required when `global.entra.type` is `entra`. | | `global.entra.issuerUrl` | string | | Controls the OIDC issuer URL for `generic-oidc` providers. Leave empty for the native Entra connector. | | `global.entra.userClaimsSource` | string | `"id_token"` | Controls the user claims source for `generic-oidc` providers. Set `userinfo` for Okta when its ID token lacks profile-name claims. | | `global.entra.adminRoleName` | string | `"Qodo-Platform-Admin"` | Controls the case-sensitive app-role claim value that grants organization owner access. | | `global.entra.existingSecret` | string | `"qodo-entra-idp"` | Controls the Secret containing the identity provider's `IDP_CLIENT_SECRET`. | | `global.entra.externalIdpsExistingSecret` | string | | Controls the Secret for multi-provider or SAML identity configuration via Dynaconf. Cannot be combined with single-provider fields. | | `global.llm.bundled` | boolean | `true` | Controls the in-cluster LLM gateway. Must remain enabled; it is the only supported topology for this packaging. | | `global.llm.openaiBaseUrl` | string | | Controls the OpenAI-compatible endpoint forwarded to by the gateway. Leave empty to use api.openai.com, which requires outbound internet access. | | `global.llm.modelMap` | object | `{}` | Controls the model mapping published by the gateway. Replaces the built-in set; must include a `text-embedding-3` model for indexing and retrieval. | | `global.llm.extraModelList` | array | `[]` | Controls additional models with their own endpoint or provider. Each entry must set `api_base` explicitly; follows LiteLLM `model_list` format. | | `global.llm.extraHeaders` | object | `{}` | Controls extra HTTP headers added to every LLM gateway request. Do not place credentials here. | | `global.merge.settings.OPENAI__RESPONSE_API` | string | `"true"` | Controls Code Review behavior overrides passed as environment-variable style keys. Must be the string `"true"`, not a YAML boolean. | | `global.analytics_sidecar.enabled` | boolean | `true` | Controls the review worker's log-forwarding sidecar for analytics events. Disabling it omits the sidecar container entirely. | | `global.tracing.enabled` | boolean | `false` | Controls the built-in OpenTelemetry Collector and Phoenix trace UI. Disabled by default; inspect via port-forward to the Phoenix service. | | `global.tracing.projectName` | string | `"qodo-onprem"` | Controls the Phoenix project name receiving traces from this installation. | | `global.tracing.samplingPercentage` | integer | `10` | Controls the percentage of ordinary traces retained. Error and slow traces are always kept. | | `global.generatedSecrets.render` | boolean | `true` | Controls in-cluster generation of internal credentials. Disable only for offline rendering with `helm template`, providing all Secrets manually. | | `telemetry.enabled` | boolean | `false` | Controls optional installation-health telemetry sent to Qodo. Requires customer approval and a valid identity Secret. | | `telemetry.mode` | string | `"automatic"` | Controls whether telemetry is sent automatically, on demand, or exported locally as JSON in file mode. Network sends require the `qodo-telemetry-auth` Secret. | | `telemetry.pushInterval` | string | `"1h"` | Controls the automatic telemetry report interval. Accepted values are 1m–1440m or 1h–24h. | | `postgres.enabled` | boolean | `false` | Controls the bundled PostgreSQL server. When enabled, point `global.externalDatabase.host` to `qodo-postgres` and set `sslMode` to `disable`. | | `redis.enabled` | boolean | `true` | Controls the bundled Redis server. Disable when `global.externalRedis.host` points to an external instance. | # Deploy Qodo using Helm Source: https://docs.qodo.ai/on-prem/qodo-on-prem-helm-chart-overview Install and configure Qodo on Kubernetes using Helm. This guide walks you through deploying the Qodo platform on Kubernetes using the Helm chart. For a complete list of Helm values and configuration options, see the [Helm chart configuration reference](on-prem-helm-chart-reference). This chart installs the Qodo platform into a single Kubernetes namespace: the web portal, the API, the code-review agents, the code-intelligence engine, the git gateway, and their supporting datastores. Configuration is **two values files**: | Layer | File | Who owns it | | - | - | - | | 1 | `onprem-base.yaml` | **Qodo.** Do not edit — it carries the component set and the settings common to every installation, and is replaced on upgrade. | | 2 | your own file | **You.** Everything specific to your environment. | The complete list of values you can set is [Helm chart configuration reference](on-prem-helm-chart-reference), with a ready-to-edit skeleton in `values-customer-template.yaml`. Both are generated from the chart, so they cannot drift from what it actually accepts. ### Where the chart comes from Two options. They install the same chart; pick one and follow it through, since they differ in one prerequisite. | | **A — this bundle** | **B — the Qodo registry** | | - | - | - | | Source | the `qodo-onprem/` directory beside this file | `oci://artifacts-self-hosted.qodo.ai/codium-stack/qodo-onprem/qodo-onprem` | | Auth | none — the chart is already here | your Qodo licence, via `helm registry login` | | Image pull Secret | **you create `qodo-pull`** (step 4) | **created for you** from your licence | | Upgrades | Qodo sends you a new bundle | `helm pull` a newer `--version` yourself | | Air-gapped | yes | no — needs egress to `artifacts-self-hosted.qodo.ai` | **Option B**, once per machine: ```bash theme={null} helm registry login artifacts-self-hosted.qodo.ai \ --username '' \ --password '' ``` Same credentials as the image registry — one licence covers the chart and the images. Then use the `oci://` URL wherever this page says `./qodo-onprem`, and **skip Secret 1 in step 4**: a chart pulled this way carries your licence, and the chart turns it into the image-pull Secrets every workload needs. Creating `qodo-pull` as well does no harm, it is simply unused. To see available versions: `helm show chart oci://artifacts-self-hosted.qodo.ai/codium-stack/qodo-onprem/qodo-onprem`. ## 1. Prerequisites Before working through this section, run `./qodo-check.sh -n -f ` and read `READINESS.md`: they verify these prerequisites for you and cover the backup, rollback and test-account items this guide does not. Run the same command again after installing, before opening traffic — it detects that Qodo is now installed and adds the post-installation checks. * Kubernetes 1.25+ and Helm 3, with a namespace you can install into. * An **ingress controller** (any: ingress-nginx, GCE, Traefik, …) and a DNS record you control — see step 2. * **PostgreSQL.** Nothing to prepare by default: the chart runs Postgres 16 with `pgvector` in-cluster, creates its own databases and generates its own admin password. To use your own database server instead — PostgreSQL 15 or 16 with the `pgvector` extension available — set `externalDatabase.enabled: true` and see step 5. * **A StorageClass that provisions PersistentVolumes** (`ReadWriteOnce` is enough). Postgres, Redis, RabbitMQ and the Qodo Git repo cache each claim one. If your cluster has no dynamic provisioning at all, see [Clusters without persistent volumes](#clusters-without-persistent-volumes). * Credentials Qodo issued you for the image registry. * One identity provider for single sign-on (step 3): **commercial Entra**, **GCC High** (or another sovereign Microsoft cloud), **Ping Identity**, **Okta**, or **Google Workspace**. Each is a different `global.entra` entity — do not mix their fields. * An **LLM endpoint**: an OpenAI-compatible URL and API key. It may be your own gateway; no outbound access to `api.openai.com` is required if you provide one. ## 2. DNS and TLS Pick a base domain, e.g. `qodo.example.com`. The chart derives these public hosts by default: | Default host | Full-host override | Serves | | - | - | - | | `app.` | `global.ingress.appHostname` | the web portal | | `api.` | `global.ingress.apiHostname` | the API | | `portal-api.` | `global.ingress.portalApiHostname` | the portal's backend endpoint | | `auth.` | `global.ingress.authHostname` | the sign-on service (OIDC issuer) | | `sdk.` | `global.ingress.sdkHostname` | Qodo Agent Runtime for SDK/CLI agentic reviews | | `git.` | `global.ingress.gitHostname` | inbound webhooks from your git provider | One wildcard DNS record `*.` pointing at your ingress controller covers all defaults, and one wildcard certificate covers them in TLS. Set a complete hostname override when an existing certificate or Kubernetes Gateway listener only covers another DNS level. Every generated Ingress route, OIDC issuer, portal URL, platform URL and CORS origin follows the same override. The six resolved hostnames must remain distinct because they route `/` to different services. Two things are easy to get wrong here: * **The resolved auth hostname must resolve from inside the cluster too.** Pods validate sign-on tokens against that public OIDC issuer, so a record that only exists on your corporate DNS, or a split-horizon setup that resolves it differently inside, will fail after login rather than at install time. * **The webhook host must be reachable by whatever calls it.** If your git provider is cloud-hosted, `git.` needs to be reachable from the internet. You can serve webhooks on the base domain itself instead of a subdomain — set `global.ingress.gitHostname` — but the host you choose is also the URL handed to the provider when hooks are registered, so it must resolve and be covered by the certificate from the caller's point of view. * **The SDK host defaults to `sdk.`.** If your DNS or certificate policy requires a different hostname, set `global.ingress.sdkHostname`; both the QAR Ingress route and the platform's `DYNACONF_SDK__BASE_URL` are derived from that one value. ## 3. Identity provider (Entra, GCC High, Ping, Okta, or Google Workspace) `global.entra` is one provider. Choose **one** entity and use only that entity's fields: | Entity | `type` | Authority | `userClaimsSource` | | - | - | - | - | | **Commercial Entra** | `entra` | `tenantId` — the Job builds `https://login.microsoftonline.com//v2.0` | leave default `id_token` (native Azure connector; this flag is unused) | | **GCC High** (or another sovereign Microsoft cloud) | `generic-oidc` | `issuerUrl`, e.g. `https://login.microsoftonline.us//v2.0` | **`id_token`** (ID token has `given_name` / `family_name`) | | **Ping Identity** | `generic-oidc` | `issuerUrl`, e.g. `https://auth.pingone.//as` | **`id_token`** | | **Okta** | `generic-oidc` | `issuerUrl`, e.g. `https://.okta.com` (org AS) | **`userinfo`** (Okta ID tokens usually lack `given_name` / `family_name`) | | **Google Workspace** | `generic-oidc` | `issuerUrl: https://accounts.google.com` | **`id_token`** | Do not mix them: commercial Entra needs `tenantId` and must not set a sovereign or generic OIDC `issuerUrl`. GCC High, Ping Identity, Okta, and Google Workspace use `generic-oidc`, while their issuers and mapping choices remain provider-specific. Confirm `/.well-known/openid-configuration` for every generic OIDC provider. Register **both** callback URIs on every application (Secret contract is the same): ``` https:///ui/login/login/externalidp/callback https:///idps/callback ``` Do not reuse the same provider `name` when changing connector types: Zitadel refuses to replace an existing native Entra provider with a generic OIDC provider of the same name. ### Commercial Entra (`type: entra`) In **Microsoft Entra admin center → App registrations → New registration**: 1. Note the **Application (client) ID** and **Directory (tenant) ID**. 2. Create a **client secret** and copy its value. 3. Add **both** Redirect URIs above (type *Web*). > **Register both.** The sign-on service uses the first one; the second is > required by its API. Registering only `/idps/callback` looks correct and > fails at login with `AADSTS50011: The redirect URI ... does not match the > redirect URIs configured for the application`. If you manage app registrations with the Azure CLI, note that `az ad app update --web-redirect-uris` **replaces** the entire list — read the existing URIs first and write them all back, or you will silently drop them. Define an Entra app role with the case-sensitive value `Qodo-Platform-Admin`; users assigned that role become Qodo organization owners, while users with any other or missing role remain regular users. If your app registration already uses another administrator role value, set `global.entra.adminRoleName` to match it exactly. ```yaml theme={null} global: entra: name: Corporate SSO type: entra clientId: "" tenantId: "" existingSecret: qodo-entra-idp ``` ### GCC High (`type: generic-oidc`) A sovereign Microsoft tenant cannot use the native `entra` connector: that path always derives `login.microsoftonline.com`. Use generic OIDC and the exact GCC High issuer. Keep `userClaimsSource: id_token` — GCC High tokens are Entra-shaped (`given_name` / `family_name`). Leave `tenantId` empty. ```yaml theme={null} global: entra: name: Entra GCC High type: generic-oidc clientId: "" tenantId: "" issuerUrl: "https://login.microsoftonline.us//v2.0" userClaimsSource: id_token existingSecret: qodo-entra-idp ``` Confirm discovery at that issuer uses GCC High authorization, token, and JWKS hosts (`login.microsoftonline.us`), not commercial `login.microsoftonline.com`. ### Ping Identity (`type: generic-oidc`) The Qodo on-prem portal supports PingOne through Zitadel's existing generic OIDC connector; no Ping-specific runtime component is required. Other Ping products must expose equivalent standard OIDC endpoints and claims. In PingOne, create and enable an OIDC web application. Use response type **Code**, grant type **Authorization Code**, and token endpoint authentication **Client Secret Basic**. Grant the intended users or groups access, allow the `openid profile email` scopes, include `email`, `given_name`, and `family_name` in the ID token, and register both callback URIs listed above. Use the environment's exact issuer URL and leave `tenantId` empty: ```yaml theme={null} global: entra: name: Ping Identity type: generic-oidc clientId: "" tenantId: "" issuerUrl: "https://auth.pingone.//as" userClaimsSource: id_token existingSecret: qodo-ping-idp ``` ### Google Workspace (`type: generic-oidc`) > **Fresh installations only.** This procedure configures Google Workspace for > a new Qodo and Zitadel installation. Switching an existing installation from > another identity provider is an identity migration and account-linking > project; that migration is not covered here. Create the OAuth application in a Google Cloud project owned by the Google Workspace organization that should access Qodo: 1. Open **Google Cloud Console → Google Auth Platform → Audience** and confirm the user type is **Internal**. This is the access boundary: do not rely on the optional `hd` request parameter or claim. 2. Open **Google Auth Platform → Clients**, create an **OAuth 2.0 Client ID**, and choose **Web application**. 3. Add both resolved callback URIs: ```text theme={null} https:///ui/login/login/externalidp/callback https:///idps/callback ``` 4. Copy the public client ID. Deliver the client secret through the customer-approved Kubernetes secret manager; never place it in this values file. 5. In **Admin Console → Security → Access and data control → API controls → Third-party app access**, a Workspace administrator locates the OAuth app by its client ID and sets an access status permitted by the customer's policy. This is not domain-wide delegation, and the Admin Console does not create the OAuth client. Google's issuer is global and exact: `https://accounts.google.com`. Leave `tenantId` empty and map claims from the ID token: ```yaml theme={null} global: entra: name: Google Workspace type: generic-oidc clientId: "" tenantId: "" issuerUrl: "https://accounts.google.com" userClaimsSource: id_token existingSecret: qodo-google-idp ``` Before opening Qodo to users, test one managed Workspace account twice and one account outside the Workspace: 1. The managed account must reach Qodo. 2. A fresh second login must reuse the same Qodo/Zitadel identity. 3. The outside account must be rejected by Google before Qodo creates a user. Troubleshooting: * missing provisioning Secret: create the Secret in the Helm release namespace, ensure its name exactly matches `global.entra.existingSecret`, and ensure its key is exactly `IDP_CLIENT_SECRET`. * `invalid_client`: verify that the client ID and Kubernetes Secret belong to the same Google OAuth client without printing the secret. * redirect mismatch: compare both registered callback URIs exactly. * an outside account reaches Qodo: stop rollout and change the Google OAuth audience to Internal. * a duplicate user appears on the second login: stop rollout and investigate issuer/subject identity continuity. * administrator controls are missing after promotion: sign out and obtain a fresh session, then verify the promoted email and workspace ID `onprem-workspace`. ### Okta (`type: generic-oidc`) Same generic OIDC connector as GCC High, different entity: Okta org authorization-server ID tokens typically have `name` and `email`, not `given_name` / `family_name`. With mapping on, Zitadel Login V1 only reads those given/family claims and shows a first/last-name form. Set `userClaimsSource` to **`userinfo`** so Zitadel uses the userinfo endpoint. Pin a qodo-platform image that honors `IDP_USER_CLAIMS_SOURCE`. Do not set `tenantId`. ```yaml theme={null} global: entra: name: Okta type: generic-oidc clientId: "" issuerUrl: "https://.okta.com" userClaimsSource: userinfo existingSecret: qodo-entra-idp ``` `https://.okta.com` is the **org** authorization server. A **custom** authorization server uses a different issuer, for example `https://.okta.com/oauth2/default` — pick one and use it consistently. ### Bootstrap a generic OIDC administrator The Ping and Google configurations above do not provide the Entra application-role claim. Their users therefore start as regular members. After the intended owner signs in once, promote only that user: ```bash theme={null} : "${NAMESPACE:?Set NAMESPACE to the Qodo Helm release namespace}" kubectl -n "$NAMESPACE" exec -it deploy/qodo-platform -- \ python -m modules.auth.scripts.promote_admin_cli \ --email owner@example.com \ --workspace-id onprem-workspace ``` Sign out and sign in again to obtain a fresh session with administrator access. ### Multiple identity providers Repeat the registration steps for every entity (commercial Entra, GCC High, Ping Identity, Okta). Give every provider a unique, stable display name, register both callback URIs in every application, and use the same administrator app-role value across tenants: Qodo has one `global.entra.adminRoleName` setting for the shared installation. Multi-IdP credentials use a different, secret-only contract. Create one Kubernetes Secret whose `DYNACONF_ZITADEL_PROVISION__EXTERNAL_IDPS` key contains the complete Dynaconf TOML list. Every `{ ... }` entry must stay on one logical line: ```bash theme={null} NAMESPACE=qodo kubectl create secret generic qodo-entra-idps -n "$NAMESPACE" \ --from-literal='DYNACONF_ZITADEL_PROVISION__EXTERNAL_IDPS=[{type="entra",name="Corporate",issuer_url="https://login.microsoftonline.com//v2.0",client_id="",client_secret=""},{type="generic-oidc",name="GCC High",issuer_url="https://login.microsoftonline.us//v2.0",client_id="",client_secret=""}]' ``` List entries are per entity, same rules as the table above: commercial Entra uses `type="entra"` (no `user_claims_source`); GCC High uses `type="generic-oidc"` with the `login.microsoftonline.us` issuer (source defaults to `id_token`); Ping Identity uses `type="generic-oidc"` with its environment issuer and `user_claims_source="id_token"`; Okta uses `type="generic-oidc"` with the Okta issuer and `user_claims_source="userinfo"`. `global.entra.userClaimsSource` is only wired for the single-provider Job when `type` is `generic-oidc` (`IDP_USER_CLAIMS_SOURCE`). Native `entra` does not get that env. Prefer creating that value through your Vault, External Secrets, CSI, or other approved secret manager so the completed list never enters shell history. The list must include every provider the provisioner should manage. Omitted providers remain in Zitadel until an operator removes them manually. Provider names are Zitadel's idempotency keys: renaming one creates another provider. Select list mode in values and leave the legacy fields empty: ```yaml theme={null} global: entra: name: "" clientId: "" tenantId: "" externalIdpsExistingSecret: qodo-entra-idps ``` Updating only this Secret does not start a new provisioning Job. After adding or removing a provider, or after rotating a client secret through Vault, External Secrets, CSI, or another secret manager, wait for the Kubernetes Secret to contain the new list and then re-run the same `helm upgrade --install` command used for the installation. The new Helm release revision starts the provisioner, applies the provider changes in Zitadel, and rolls the platform to read the refreshed configuration. The rotation is not active until that upgrade completes. The chart refuses list mode together with any legacy `name`, `clientId`, `tenantId`, or `issuerUrl`. On a one-to-many upgrade, remove those four fields from your customer values file, keep the existing provider's name and credentials in the new list, and do not delete `qodo-zitadel-generated`. The provisioner preserves that Secret, clears the old direct-provider pin, and the chart rolls the platform after provisioning so the provider picker takes effect. ## 4. Create the Secrets Create the Secrets required by the infrastructure choices below. Credentials never belong in a values file. > **On option B (the Qodo registry), skip Secret 1.** A chart pulled with your > licence already carries the registry credential and creates the pull Secrets > itself. ```bash theme={null} # Pick your namespace once and reuse it in every command on this page. NAMESPACE=qodo kubectl create namespace "$NAMESPACE" # 1. Image pull credentials (issued by Qodo). The name is fixed. # OPTION A ONLY — not needed when installing from the Qodo registry. kubectl create secret docker-registry qodo-pull -n "$NAMESPACE" \ --docker-server=artif-reg-self-hosted.codium.ai \ --docker-username='' \ --docker-password='' # 2. LLM endpoint API key. kubectl create secret generic qodo-openai -n "$NAMESPACE" \ --from-literal=OPENAI_API_KEY='' # 3. Single-provider IdP client secret from section 3. # Enter the exact name from global.entra.existingSecret: # qodo-google-idp for the Google example; # qodo-ping-idp for the Ping Identity example; # qodo-entra-idp for the Entra, GCC High, and Okta examples. # Disable shell tracing before handling credentials. set +x read -rp "Identity provider Secret name: " IDP_SECRET_NAME : "${IDP_SECRET_NAME:?Secret name is required}" read -rsp "Identity provider client secret: " IDP_CLIENT_SECRET echo : "${IDP_CLIENT_SECRET:?Client secret is required}" printf '%s' "$IDP_CLIENT_SECRET" | kubectl create secret generic "$IDP_SECRET_NAME" -n "$NAMESPACE" \ --from-file=IDP_CLIENT_SECRET=/dev/stdin unset IDP_CLIENT_SECRET IDP_SECRET_NAME # 4. YOUR OWN DATABASE SERVER ONLY. Use that server's EXISTING admin # password (see step 5). Do not run this for bundled PostgreSQL: Helm # generates and owns qodo-db-admin when generatedSecrets.render=true. kubectl create secret generic qodo-db-admin -n "$NAMESPACE" \ --from-literal=POSTGRES_PASSWORD='' ``` Use Vault, External Secrets, CSI, or another approved secret manager instead when available. Whichever method you use, the resulting Secret name must match `global.entra.existingSecret` and its key must be `IDP_CLIENT_SECRET`. The command above intentionally fails if the Secret already exists; update an existing Secret through your approved secret manager instead of storing its manifest in a client-side-apply annotation. Qodo Telemetry is optional and disabled by default. Qodo supplies the signed offline identity tool with its verification and enrollment guide. After Qodo approves your public identity, create the customer-owned signing Secret from the three files. This step is the same for direct and Replicated installs: ```bash theme={null} kubectl -n "$NAMESPACE" create secret generic qodo-telemetry-auth \ --from-file=private-key.pem=./qodo-telemetry-auth/private-key.pem \ --from-file=installation-id=./qodo-telemetry-auth/installation-id \ --from-file=approval.json=./qodo-telemetry-auth/approval.json ``` The chart mounts the files read-only. Keep the private key out of Helm values. Allow outbound HTTPS to `https://listener.qodo.ai` for network sends, then opt in: ```yaml theme={null} telemetry: enabled: true mode: automatic # on-demand or file are also supported pushInterval: 1h # whole minutes/hours from 1m through 24h ``` `automatic` sends at startup, on a bounded heartbeat, and after meaningful health changes. `on-demand` sends only through the local operator API. `file` makes no receiver requests and allows a local unsigned JSON report download; it needs only a valid public installation ID. Missing or invalid identity does not block the product install. Air-gapped installations should keep telemetry disabled unless an approved local file-only procedure is in place. To inspect the exact bounded payload, last attempt, and last successful send, port-forward the sender locally. These endpoints have no Service or Ingress and reject non-loopback clients: ```bash theme={null} kubectl -n "$NAMESPACE" port-forward deployment/qodo-telemetry 8091:8091 curl --fail http://127.0.0.1:8091/api/telemetry curl --request POST --fail-with-body http://127.0.0.1:8091/api/telemetry/send curl --fail --output qodo-telemetry-report.json \ http://127.0.0.1:8091/api/telemetry/export ``` > Do not pre-create `qodo-db-admin` on the bundled-PostgreSQL path. The chart > renders that Secret as part of the Helm release; an existing Secret without > Helm ownership metadata makes install fail with `invalid ownership metadata`. > The exception is the fully pre-provisioned mode > `global.generatedSecrets.render=false`, where you must create every Secret in > the generated-credentials inventory before install. Everything else the platform needs is generated on first install and kept across upgrades. On platform 2.182.0 and later, Zitadel provisioning also creates one `scim-` machine user per configured provider and checkpoints its one-time PAT as `SCIM_PAT_` in `qodo-zitadel-generated`. Keep that Secret backed up and access-restricted; runtime workloads consume only its OIDC keys, not those PATs. ## 5. Database **The default is an in-cluster database**: Postgres 16 with `pgvector`, on a persistent volume sized by `global.storage.sizes.postgres` (20Gi), creating the four databases it needs. You supply the three routing values below; with `global.generatedSecrets.render=true`, Helm creates `qodo-db-admin` itself: ```yaml theme={null} global: externalDatabase: host: qodo-postgres # the in-cluster Service — leave as-is adminUser: postgres # in-cluster superuser — correct here sslMode: disable # the bundled server does not enable TLS existingSecret: qodo-db-admin postgres: enabled: true # brings the server up ``` Both halves are needed: `postgres.enabled` runs the server, and `global.externalDatabase.*` is how every component finds it — including the migration Jobs, which is why `existingSecret` cannot be empty. The key is named `externalDatabase` because it is "where the database is"; `enabled: true` under it is what switches to a server of your own. ### Only if you bring your own database server Set `externalDatabase.enabled: true` with `host`, `existingSecret` (the `qodo-db-admin` Secret from step 4) and — importantly — `adminUser`: ```yaml theme={null} global: externalDatabase: enabled: true host: adminUser: # see the warning below sslMode: require # encrypted; the managed-server default existingSecret: qodo-db-admin ``` The install creates its own databases, so that user needs **CREATEDB**. `require` prevents plaintext connections, but does not authenticate the database certificate or hostname; verified TLS modes and custom database CA plumbing are not yet exposed by this chart. **Set `adminUser` explicitly.** It defaults to `postgres`, which most managed database services do not offer — on Google Cloud SQL the equivalent is the user you created with the `cloudsqlsuperuser` role, on Amazon RDS the master user. Leaving the default in place fails part-way through the install, in a setup job, rather than up front. Use an **empty** database or instance. The install creates databases named `zitadel`, `litegit`, `rag_db`, `qodo_merge` and `qodo_rules`; if objects with those names already exist and are owned by a different user, the setup jobs will fail on permissions. **`pgvector` must be creatable, not merely installed.** Two of those databases (`rag_db` and `qodo_rules`) hold embeddings and need the `vector` extension inside them — extensions are per-database, so one does not cover the other. Managed services usually make creating this particular extension **superuser-only**: on Amazon RDS it needs `rds_superuser`, which the install user should not have. The extension being *available* on the server is not enough. If your user cannot create it, have an admin run this once, before installing. The databases must be owned by the configured `adminUser`, not by the privileged operator running these commands (replace `qodo_admin` below with that exact role name): ```sql theme={null} CREATE DATABASE rag_db OWNER qodo_admin; -- skip if it already exists CREATE DATABASE qodo_rules OWNER qodo_admin; -- skip if it already exists ALTER DATABASE rag_db OWNER TO qodo_admin; ALTER DATABASE qodo_rules OWNER TO qodo_admin; \c rag_db CREATE EXTENSION IF NOT EXISTS vector; \c qodo_rules CREATE EXTENSION IF NOT EXISTS vector; ``` The install detects this and stops with the same instructions rather than failing later inside a migration. Note the bundled connection pooler (`advanced.components.pgbouncer.enabled`) is for the in-cluster database only and is rejected alongside `externalDatabase.enabled: true` — front a managed database with its own pooler (RDS Proxy, Cloud SQL connectors) instead. ### Clusters without persistent volumes If your cluster cannot provision PersistentVolumes, add `qodo-onprem/values-emptydir.yaml` as an extra `-f`, **after** your own values file. Note the path: it ships inside the chart directory, unlike `onprem-base.yaml` at the top level. ```bash theme={null} helm upgrade --install qodo ./qodo-onprem -n qodo \ -f onprem-base.yaml -f my-values.yaml -f qodo-onprem/values-emptydir.yaml ``` It moves all four datastores onto node-local `emptyDir` storage, so the install needs no StorageClass and creates no PVCs. > **This destroys data.** An `emptyDir` lives and dies with its pod. Any > restart, eviction, node drain, or `helm upgrade` that rolls a pod wipes that > component — the databases included. Verified, not theoretical: deleting the > Postgres pod took the database count from 10 back to 5 and dropped a test > table. Use it for a short-lived evaluation, never for an environment whose > data matters, and expect to re-run onboarding after any restart. Switching to real volumes later means a reinstall, not an upgrade: drop the extra `-f` and reinstall into a clean namespace. **Pass it on EVERY upgrade, not just the install.** Values files are not remembered between `helm upgrade` runs, so omitting this `-f` later asks the chart to move the datastores back onto PersistentVolumes. That upgrade fails part-way, and the failure is not self-healing: ``` Error: UPGRADE FAILED: cannot patch "qodo-rabbitmq" with kind StatefulSet: StatefulSet.apps "qodo-rabbitmq" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'ordinals', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden ``` Kubernetes refuses the two StatefulSets (their volume claims are immutable), but everything else in that run is already patched — including `qodo-gitway`, which is left mounting a `qodo-gitway-repo-store` PVC that can never bind on a cluster with no provisioner. The pod goes `Pending` with `pod has unbound immediate PersistentVolumeClaims`, and re-running the correct three-file command does **not** fix it: Helm compares its own last-good manifest with the new one, both `emptyDir`-shaped, so it sees nothing to change and never removes the stray volume. Recover by deleting the deployment and its orphaned claim, then upgrading again with all three files: ```bash theme={null} kubectl delete deploy qodo-gitway -n ``` ```bash theme={null} kubectl delete pvc qodo-gitway-repo-store -n ``` Nothing durable is lost — that volume is the repository cache, which is `emptyDir` on this path and re-clones on demand. ### Only if you bring your own Redis The chart runs Redis in-cluster by default, without a password, and nothing needs configuring. To point at a managed instance (ElastiCache, Memorystore): ```yaml theme={null} global: externalRedis: host: ``` **If that instance requires a password**, create a Secret and name it — no extra `-f` layer, no other change: ```bash theme={null} kubectl -n qodo create secret generic qodo-redis-auth \ --from-literal=REDIS_PASSWORD='' ``` ```yaml theme={null} global: externalRedis: host: existingSecret: qodo-redis-auth ``` Every component that talks to Redis picks it up from there. Any password works — `@`, `/`, `:`, `#` and spaces included; each component URL-encodes it. ## 6. Write your values file If this bundle contains a `values-example.yaml`, start from that — it is a worked file for your environment, with your hostnames and endpoints already filled in and the placeholders you must supply marked. Otherwise copy `values-customer-template.yaml` and uncomment what you need. A minimal file: ```yaml theme={null} global: baseDomain: qodo.example.com ingress: className: nginx annotations: cert-manager.io/cluster-issuer: letsencrypt entra: name: Corporate SSO type: entra clientId: tenantId: # GCC High instead of commercial Entra: # entra: # name: Entra GCC High # type: generic-oidc # clientId: # issuerUrl: https://login.microsoftonline.us//v2.0 # userClaimsSource: id_token # Okta instead of Entra — pin a qodo-platform image that honors # IDP_USER_CLAIMS_SOURCE: # entra: # name: Okta # type: generic-oidc # clientId: # issuerUrl: https://.okta.com # userClaimsSource: userinfo llm: openaiBaseUrl: https://llm-gateway.example.internal/v1 ``` That is a complete file — the database is in-cluster and needs nothing. To use your own database server instead, add the block from step 5: ```yaml theme={null} global: externalDatabase: enabled: true # without this the other keys are ignored host: postgres.example.internal adminUser: qodo_admin existingSecret: qodo-db-admin ``` ### Rules embedding dimensions The standard setup remains unchanged, with a default rule embedding dimension of 1024. Only override it for a model that requires different settings, using the same configuration on the API and event consumer. For example, native Nomic v1 produces 768 values and does not accept a request dimension parameter: ```yaml theme={null} platform: env: DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_MODEL_NAME: value: "nomic-embed-text-v1" DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_DIM: value: "768" DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_SEND_DIMENSIONS: value: "false" git-event-consumer: env: DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_MODEL_NAME: value: "nomic-embed-text-v1" DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_DIM: value: "768" DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_SEND_DIMENSIONS: value: "false" ``` The migration Job inherits these three settings from `platform.env`. ConfigMap or Secret references are supported on fresh installs when the referenced resources are available. On upgrades, use literal `value` entries for these settings: the pre-upgrade migration runs before Helm updates ConfigMaps and Secrets, so the chart rejects `valueFrom` entries to prevent stale settings. Register the selected model in your LLM gateway and use platform images that support configurable rule embedding dimensions. Set the dimension before the dimension migration first runs. Changing it later does not resize the database automatically; existing incompatible vectors need a migration and regeneration plan. Back up the database before changing models. ### PR history embedding dimensions PR history stores embeddings in `rag_db` with a default dimension of 2000. Only override it for an embedding model that returns a different size, for example Amazon Titan Text Embeddings V2, which returns at most 1024 values. Set the same literal on all three engine workloads, and keep the embedding request size equal to it: ```yaml theme={null} engine-indexer: env: PR_KNOWLEDGE__EMBEDDING_DIMENSION: value: "1024" ONPREM_MODELS__REMOTE_RAG__EMBED_DIM: value: "1024" engine-pr-kn-consumer: env: PR_KNOWLEDGE__EMBEDDING_DIMENSION: value: "1024" ONPREM_MODELS__REMOTE_RAG__EMBED_DIM: value: "1024" engine-retriever: env: PR_KNOWLEDGE__EMBEDDING_DIMENSION: value: "1024" ONPREM_MODELS__REMOTE_RAG__EMBED_DIM: value: "1024" ``` The engine migration Job creates the `rag_db` vector columns from the `engine-indexer` value, even when the indexer itself is disabled. The chart rejects values that differ across the three workloads (an unset value counts as the default 2000), values that are not a positive whole number, and `valueFrom` entries, because the migration runs before Helm updates ConfigMaps and Secrets. Set the dimension before PR history is first indexed. The migration only creates missing tables, so changing the value later does not resize them. To change it on an existing install, scale the three engine workloads to zero, then in `rag_db` empty the PR history tables and resize both vector columns before upgrading: ```sql theme={null} ALTER TABLE pr_description_embedding ALTER COLUMN embedding TYPE vector(1024); ALTER TABLE pr_fix_suggestion_embedding ALTER COLUMN embedding TYPE vector(1024); ``` PR history is then re-indexed from scratch. ### Optional per-user GitHub repository access Account linking, access calculation and enforcement are separate steps. Use a Qodo-provided Platform release supporting on-prem account linking and configure the customer OAuth App first. The installed GitHub App must also have the permissions needed to read repository and organization membership. Start calculation without changing visibility: ```yaml theme={null} global: repositoryAccess: enabled: true filteringEnabled: false ``` This starts the internal access worker and enables the API and Git event consumer publishers against the existing message broker and database; it creates no new database or migration. With a compatible Platform release, both account links and installation-created/repositories-added events trigger calculation. For a self-hosted GitHub server, ensure the API's configured GitHub host matches the linked accounts and installations. Existing links need a supported backfill or another link/sign-in trigger; starting a consumer alone does not compute them. Once the worker is ready and a linked user's access map is verified, set `global.repositoryAccess.filteringEnabled: true`. Unlinked users, including administrators, cannot see private repositories on the configured GitHub host. Disabling enforcement restores unfiltered reads. Queue naming and rollout settings are documented under `global.repositoryAccess` in `CUSTOMER-VALUES.md`. ## 7. Install Option A — from this bundle: ```bash theme={null} helm upgrade --install qodo ./qodo-onprem \ --namespace "$NAMESPACE" \ -f onprem-base.yaml \ -f my-values.yaml ``` Option B — from the Qodo registry (after `helm registry login`, section 1). Fetch and unpack first, because `onprem-base.yaml` lives *inside* the chart and `-f` only reads local files: ```bash theme={null} helm pull oci://artifacts-self-hosted.qodo.ai/codium-stack/qodo-onprem/qodo-onprem \ --version --untar helm upgrade --install qodo ./qodo-onprem \ --namespace "$NAMESPACE" \ -f qodo-onprem/onprem-base.yaml \ -f my-values.yaml ``` Install from the unpacked directory, **not** the `oci://` URL directly: the copy you pulled carries your licence, which is what produces the image-pull Secrets. Pulling again for an upgrade is the same two commands with a new `--version`. Order matters: the second `-f` wins where the two overlap. `$NAMESPACE` is the one you set in step 4 — the Secrets have to live in the same namespace as the release. Any namespace works; pick whatever fits your cluster conventions. The **release** name, though, must stay **`qodo`**. Resource names are fixed to a `qodo-` prefix in this packaging, so another release name yields `qodo-*` resources anyway and two releases in one namespace would collide. First install takes several minutes: setup jobs prepare the databases and configure sign-on before the applications become ready. ```bash theme={null} kubectl get pods -n "$NAMESPACE" -w ``` ### Pulling the images from your own registry Skip this unless you mirror images internally. By default every image comes from Qodo's registry using the pull Secret from step 4. It takes one value. Mirror the images listed under "Images in this chart version" in [Helm chart configuration reference](on-prem-helm-chart-reference) — keeping the repository path and tag identical, only the registry host changes — then set: ```yaml theme={null} global: imageProxyPrefix: registry.internal.example/qodo/ ``` Do not hand-write the image list: it is generated from a full render of this chart version, so it includes the ones referenced only from inside templates and cannot drift from the pins. ```bash theme={null} helm upgrade --install qodo ./qodo-onprem \ --namespace "$NAMESPACE" \ -f onprem-base.yaml -f my-values.yaml ``` Then confirm nothing was missed — this must print nothing: ```bash theme={null} helm template qodo ./qodo-onprem -f onprem-base.yaml -f my-values.yaml \ | grep -o 'image: .*' | grep -v 'registry.internal.example' ``` Run that check. A partial mirror still installs cleanly: Helm accepts it, and the images you missed fail minutes later as `ImagePullBackOff`, in a pod event that does not mention your values file. Your pull Secret (`global.pullSecret`, default `qodo-pull`) must carry credentials for your registry once you do this. ### Confining Qodo to particular nodes Skip this unless Qodo has to run on specific nodes. By default every pod is pinned to x86-64 nodes — the only architecture the images are built for — and placed anywhere else your scheduler chooses. Three values apply to every workload, the setup Jobs included: ```yaml theme={null} global: # ADDED to the architecture pin, which you do not repeat. nodeSelector: your-pool-label: qodo # Needed if those nodes are tainted. tolerations: - key: dedicated operator: Equal value: qodo effect: NoSchedule # For placement a selector cannot express. affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: topology.kubernetes.io/zone operator: In values: [us-central1-a] ``` A `nodeSelector` is an AND of its entries, so adding one label narrows placement rather than replacing the architecture pin. A toleration only permits scheduling onto a tainted node — it does not keep pods off the other nodes, so pair it with the selector. If the setup Jobs need to land somewhere the applications do not, add `global.jobScheduling.nodeSelector` / `.tolerations`; those are applied on top of the values above rather than instead of them. Check placement before opening traffic — every pod should be on a node you expect, and none should be stuck `Pending`: ```bash theme={null} kubectl get pods -n "$NAMESPACE" -o wide kubectl get pods -n "$NAMESPACE" --field-selector status.phase=Pending ``` A pod that stays `Pending` with `didn't match Pod's node affinity/selector` in `kubectl describe` means no node carries every label you set. ### Clusters that require pods to declare their IDs Skip this unless your cluster rejects pods that do not name a user or group — most commonly OpenShift, where a restricted SCC admits a pod only if the IDs it names fall inside the range assigned to your namespace. Two values apply to every workload, including the setup Jobs that run before the applications start: ```yaml theme={null} global: podSecurityContext: # Pod-level fields runAsNonRoot: true runAsUser: 1000680000 # from YOUR namespace's assigned range runAsGroup: 1000680000 fsGroup: 1000680000 containerSecurityContext: # container-level fields allowPrivilegeEscalation: false capabilities: drop: [ALL] ``` Read the admissible range from your own namespace rather than copying the numbers above: ```bash theme={null} kubectl get namespace "$NAMESPACE" \ -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}{"\n"}' ``` The two are separate values because Kubernetes splits the fields: `fsGroup` and `supplementalGroups` are Pod-only, while `allowPrivilegeEscalation`, `readOnlyRootFilesystem` and `capabilities` are container-only. Setting either in the wrong place is rejected by the API server. Both are empty by default, and a component that ships its own setting keeps it. On OpenShift you will also be publishing through Routes rather than an Ingress — see `global.route` in [Helm chart configuration reference](on-prem-helm-chart-reference). ## 8. Verify ```bash theme={null} # All workloads ready, setup jobs Completed kubectl get pods -n "$NAMESPACE" # The ingress has an address kubectl get ingress -n "$NAMESPACE" ``` Then browse to the resolved portal URL (`https://app.` by default, or `https://` when overridden), choose **SSO (Single Sign-On)**, and sign in with your Entra ID account. Your user is created automatically on first login. ## Troubleshooting **Pods stuck in `ImagePullBackOff`** — the `qodo-pull` Secret is missing, misnamed, or holds the wrong credentials. Confirm with `kubectl describe pod -n ` and check the name is exactly `qodo-pull`. **The ingress never gets an address** — with the GCE ingress controller, ask Qodo for the additional values layer it requires; container-native load balancing needs annotations this chart does not apply by default. On other controllers, check that `global.ingress.className` matches an IngressClass that exists (`kubectl get ingressclass`). **Setup jobs fail with a permissions or role error** — almost always `global.externalDatabase.adminUser`: see step 5. **Login fails with `AADSTS50011`** — a Redirect URI is missing from the app registration: see step 3, and note that both are required. **The portal loads but stays on a spinner** — check that the pods are ready and that the resolved portal API hostname (`portal-api.` or `global.ingress.portalApiHostname`) resolves and is covered by the certificate; the portal calls it from the browser. **A review pod restarts every few minutes and reviews never finish** — read the restart reason before treating it as a crash or a failed health check, because those look identical from `kubectl get pods`: ```bash theme={null} kubectl describe pod -n | grep -A4 'Last State' ``` `Reason: OOMKilled` with `Exit Code: 137` means the container hit its memory limit, not a bug. The queue worker reserves 10Gi per replica, while the HTTP agentic-review endpoint requests 4Gi with an 8Gi limit. Very large diffs or a long `global.merge.settings` metadata list can still exceed those limits. If both entry points serve reviews in your installation, raise both aliases so the outcome does not depend on which one handled the review: ```yaml theme={null} pr-agent-litegit: deployments: resources: limits: memory: 16Gi requests: memory: 16Gi pr-agent-agentic: deployments: resources: limits: memory: 16Gi requests: memory: 8Gi ``` Each container reserves its `requests.memory`, so multiply by `replicaCount` before raising it. Six queue-worker containers at 10Gi reserve 60Gi; with the default 1Gi analytics sidecar in every pod, the six replicas reserve 66Gi of schedulable memory. Pods stay `Pending` if the nodes cannot satisfy that. **A pod is `Pending` with `unbound immediate PersistentVolumeClaims`** — on a cluster without volume provisioning, this is usually an upgrade that omitted `values-emptydir.yaml`; see "Clusters without persistent volumes" in step 5 for the recovery, which Helm cannot perform on its own. **Something else** — collect `kubectl get pods -n `, `kubectl describe ingress -n `, and the logs of the failing pod, and contact Qodo support. ## Upgrades Replace `onprem-base.yaml` with the new version, keep your own values file, and re-run the same `helm upgrade --install` command. Your file is never overwritten by an upgrade. **Database migrations gate upgrades.** After the RabbitMQ topology check, `db-init` and the enabled application migration Jobs run as `pre-upgrade` hooks. A failed hook stops the upgrade before Helm updates application Deployments. Existing pods remain on the previous version; inspect the failed Job and correct the cause before retrying. These hooks use the existing database and credential Secrets; do not rotate or rename those Secrets in the same upgrade. On a first install, migration Jobs remain ordinary resources because generated Secrets and bundled PostgreSQL are not yet available. If an upgrade is intended to enable bundled PostgreSQL for the first time or repair an unavailable database, the pre-upgrade migrations cannot run against it. Do not bypass the hooks with `--no-hooks`: that can roll new application images onto an unmigrated database. Restore database availability first, or contact Qodo support for a staged migration and data-transfer plan. Switching to a newly enabled bundled PostgreSQL Service in one upgrade is rejected before any resources change. Offline `helm template --is-upgrade` cannot verify that Service; use `helm upgrade --dry-run=server` to preview an existing installation. The revisioned `qodo-merge-migrate-*` Job applies PR-Agent database changes. The review worker and agentic endpoint wait in `wait-for-schema` until their image's Alembic head matches the `qodo_merge` database; the init container reads `alembic_version` directly (it never invokes Alembic's database-creating startup path) and never runs migrations. Use `--wait --wait-for-jobs --timeout 30m` for upgrades so Helm reports a failed migration or a pod stuck waiting for it. Inspect the migration Job logs before retrying; changing the Deployment image alone does not start the Job. Application Deployments roll one pod at a time without adding surge capacity (`maxSurge: 0`, `maxUnavailable: 1`). A multi-replica service keeps at least `replicas - 1` ready while its new pods start; a single-replica service still has a brief interruption. QAR keeps its separate zero-unavailable, one-surge strategy and schema-aware startup gate. Old and new pods can overlap during a rolling upgrade, so image and database changes must remain backward-compatible through that interval. Helm reporting `deployed` does not by itself prove every rollout or migration finished; verify the Deployment and Job statuses. Before application workloads change, the chart checks the three persisted LiteGit workflow queues. RabbitMQ cannot change queue type or delivery arguments in place, while the independently released Platform, Engine and qodo-git images do not all adopt the bounded quorum contract in the same release. The chart therefore carries the topology supported by each pinned client: it migrates a queue to quorum only when that consumer supports bounded redelivery, and keeps an older consumer's queue classic until its image moves. The default `global.rabbitmqMigration.mode: automatic` runs a guarded pre-upgrade hook. When a queue does not match its pinned consumer, it temporarily scales the LiteGit webhook receiver to zero, lets accepted messages drain, stops only the affected consumers, and replaces only queues that RabbitMQ confirms are empty and unused. It then verifies the compatible topology and restores the original replicas. Expect a short webhook maintenance window; providers receive a retryable failure while LiteGit is paused. Already-migrated installations skip the maintenance window entirely. The hook never purges or copies messages. If the queues do not drain within `global.rabbitmqMigration.drainTimeoutSeconds` (default 600), the Helm upgrade fails before deleting a queue or changing an application image, and the hook restores the recorded replica counts. Inspect the retained failed Job before retrying: ```bash theme={null} kubectl -n logs job/qodo-rabbitmq-topology-migrate ``` Clusters that require an operator-controlled maintenance procedure may set `global.rabbitmqMigration.mode: validate`. That mode is read-only and blocks the upgrade while any legacy queue remains; use it only with a migration plan provided by Qodo. ## Argo CD / ApplicationSet (external PostgreSQL) Argo CD runs `helm template`, not `helm upgrade`: it cannot use Kubernetes `lookup` to reuse live credentials, and `.Release.Revision` does not advance. Use the packaged **`values-argocd.yaml` as the last values layer** after `onprem-base.yaml` and your environment values. It selects `global.deploymentMode: argocd` and `global.generatedSecrets.render: false`. Do not put credentials in any values file or in Git. This mode requires a reachable **external** PostgreSQL server; bundled `qodo-postgres` is deliberately rejected because its pod starts after the database setup Jobs on a first sync. The external Secret controller (for example, External Secrets or a sealed- Secret workflow) must reconcile these fixed names and keys in the target namespace **before** Argo CD syncs Qodo. They are absent from the Argo CD chart render; changing their names in values does not repoint the consumers. | Secret | Required keys | | - | - | | `qodo-db-admin` | `POSTGRES_PASSWORD` | | `qodo-zitadel-secrets` | `ZITADEL_MASTERKEY`, `ZITADEL_DB_PASSWORD` | | `qodo-platform-jwt` | `DYNACONF_AUTH__OIDC__JWT_ENCRIPTION_KEY` | | `qodo-qodo-platform-api-key` | `DYNACONF_AUTH__QODO_PLATFORM__API_KEY` (raw), `QODO_PLATFORM__API_KEY` (bearer), `DYNACONF_AUTH__SERVICE_API_KEYS` (JSON allowlist) | | `qodo-litegit-master-secrets` | `LITEGIT_MASTER_KEY`, `LITEGIT_MASTER_API_KEY` | | `qodo-rabbitmq-password` | `RABBITMQ_PASSWORD` | | `qodo-llm-gateway-key` | `LLM_GATEWAY_API_KEY` | | `qodo-pr-agent-secrets-toml` | `.secrets.toml` with `[qodo_platform].api_key` | The Platform bearer must equal `qodo-svc-onprem-` plus the preserved raw key; the allowlist must contain that bearer; LiteGit, Gitway, Engine, QAR, both review workers, and Platform read it from the **same** `qodo-qodo-platform-api-key` Secret. The TOML key must match it. The packaged preflight checks these invariants without displaying any credential: ```bash theme={null} python3 qodo-onprem/verify-external-secrets.py \ --context "$KUBE_CONTEXT" --namespace "$NAMESPACE" ``` Python 3.11+ is required. This checks the internal inventory above. The ordinary install prerequisites still apply separately: the image-pull Secret (`qodo-pull` on direct-registry installs), `qodo-openai` when using the bundled LLM gateway, the configured identity-provider Secret, and TLS as appropriate. `qodo-engine-secrets-toml` contains no credential and remains chart-rendered. `qodo-zitadel-generated` is written by the provisioner at runtime, not on a fresh first sync. An existing install **must preserve it** as well. The handoff preflight checks every required identity key used by Platform; an unrelated nonempty Secret does not pass. An empty IdP pin is valid for local login or a provider picker, but its key must remain present. For a Helm-to-Argo CD handoff: 1. Pin the release name to `qodo`, the same namespace and customer values, and a reviewed chart version. Keep the values order `onprem-base.yaml`, customer file, `values-argocd.yaml`. If the customer file lives in another Git repository, use Argo CD multi-source `$values/...` for that middle entry. Keep the Argo CD Application name `qodo` too, or configure a separate Argo CD tracking label key: Argo CD's default `app.kubernetes.io/instance` rewrite can otherwise break this chart's selectors. 2. Back up and import the **existing bytes** of every Secret above into the external Secret source, including Zitadel's master key, LiteGit's vault master key, and the database password. Preserve `qodo-zitadel-generated`. Never regenerate those keys against existing databases. Keep backup/export material only in approved encrypted Secret storage, never a values file, shell transcript, PR, or temporary render. 3. Have the external controller reconcile first. Run the preflight above with `--require-zitadel-generated`; verify its output is green, and verify the old and newly managed Secret data are byte-identical in your Secret system. Do **not** delete and recreate a live Secret to transfer its ownership. If only the pr-agent TOML check fails, reconstruct that file from the **existing Platform bearer** in the Secret source; do not rotate the bearer or its allowlist to match a stale TOML copy. 4. Freeze direct Helm upgrades. Start the ApplicationSet with automated pruning and self-heal **off**, inspect `argocd app diff`, and confirm Qodo's credential Secrets are not in its desired manifest. Do not run `helm uninstall`: that deletes other live resources and is not an Argo CD adoption step. The old Helm release record can remain while Argo CD owns future reconciliation. Only one controller should write the workloads. 5. Sync in a maintenance window if the chart or images move. Argo CD waits for the chart's ordered Jobs: wave -3 prepares static prerequisites/RBAC and waits for bundled RabbitMQ and Redis to be healthy; wave -2 checks RabbitMQ topology and initializes databases; wave -1 runs migrations; wave 0 updates workloads and provisions Zitadel; PostSync stamps the revision. The RabbitMQ Job checks the running broker on both install and upgrade. Absent queues on a fresh broker need no migration; a missing publisher alone does not prove retained queues are absent. Completed Jobs have stable names for identical renders and remain present; a chart, values, or queue-script change gives them new names and reruns them. Replicated pull-credential rotation alone does not change those names. Use a full Application sync, not selective resource sync: Argo CD skips hooks during selective sync, including this chart's PostSync revision roll. 6. Check every migration Job and Deployment is healthy before enabling automatic sync/pruning. If you enable pruning, use `PruneLast=true` and keep the external Secret resources in their own Application/Secret controller with a deliberate retention policy. Never let pruning remove a credential the Qodo chart no longer renders. Before enabling self-heal, tell the Application to ignore the three pod-template annotations that Qodo's provision/revision Jobs maintain, and set `RespectIgnoreDifferences=true`: ```yaml theme={null} spec: ignoreDifferences: - group: apps kind: Deployment jqPathExpressions: - '.spec.template.metadata.annotations."qodo.ai/revision"' - '.spec.template.metadata.annotations."qodo.ai/zitadel-idp-config"' - '.spec.template.metadata.annotations."qodo.ai/ca-bundle-checksum"' syncPolicy: syncOptions: - RespectIgnoreDifferences=true - PruneLast=true ``` Without that policy, Argo CD can undo the Jobs' pod restarts and repeatedly report drift. This Application policy belongs in the ApplicationSet, not in Helm values; validate it in the actual generated Application before turning on self-heal. The first Argo CD sync also runs the PostSync revision roller. Newly installed Deployments have no revision stamp, so this causes one additional rollout after initial readiness. Wait for those rollouts to settle before acceptance checks. Later identical syncs retain the stamp and do not repeat that rollout. Set Platform rule embedding model, dimension and send-dimensions settings with literal `platform.env.*.value` entries in Argo CD mode. Their migration runs before workload ConfigMap and Secret updates, so `valueFrom` cannot safely supply these non-secret settings. Embedding API credentials remain Secret refs. If Secret **bytes are unchanged**, ownership handoff alone needs no pod restart. If an external Secret legitimately changes, environment variables and `subPath` TOML mounts do not refresh in running pods: coordinate a rollout of every consumer after updating the Secret. A changed Platform bearer affects Platform, LiteGit, Gitway, QAR, Engine and review workers together. The PostSync revision roller handles chart-version/CA changes, **not** external Secret rotation. Zitadel master, LiteGit vault and database credentials must not be rotated as a side effect of migration. The `qodo-revision` ConfigMap reports `QODO_DEPLOYMENT_MODE=argocd`, the actual chart version, and `QODO_HELM_REVISION=0` (Argo CD has no Helm release revision). Use Argo CD's Application history for sync revisions. The external credential source, Argo CD ApplicationSet policy, Secret retention, and tracking-label choice cannot be supplied by chart values alone. A direct Helm install remains the default; do not add the Argo CD layer to one. For a first Argo CD install, provision Secrets and the external PostgreSQL server before the first sync, then run the preflight without `--require-zitadel-generated`. ### Check before and after every Argo CD sync `verify-external-secrets.py` checks the Secret inventory; it cannot see whether the servers still accept those values. `argocd-upgrade-check.py` checks the live state around a sync and never prints a credential: ```bash theme={null} python3 qodo-onprem/argocd-upgrade-check.py pre --context "$KUBE_CONTEXT" \ --namespace "$NAMESPACE" --argo-namespace "$ARGO_NAMESPACE" --app qodo # sync only when it reports GO, then: python3 qodo-onprem/argocd-upgrade-check.py post --context "$KUBE_CONTEXT" \ --namespace "$NAMESPACE" --argo-namespace "$ARGO_NAMESPACE" --app qodo \ --revision "$CHART_VERSION" ``` Run `pre` after changing the chart version and values and refreshing the Application. It reports NO-GO when: * an operation is running or queued, or automated sync is on; * the Application's comparison is stale or failed, or its desired state contains a credential Secret; * a credential Secret is missing, or one that the Application tracks lacks `Prune=false`; * a running pod's environment or mounted pr-agent TOML differs from its Secret; * RabbitMQ or the bundled LLM gateway rejects the Secret's value; * Zitadel logs master-key decrypt errors or database login failures; * any of these checks cannot run (missing access, unreadable container, no running pods). Before a first install nothing runs yet: use `verify-external-secrets.py` as the gate, and run `pre --first-install`, which skips the checks against running pods and servers. Run `post` after the sync. It repeats the Secret, running-pod and server checks. It also requires the sync to have succeeded at the expected chart version (or commit), every setup and migration Job of that revision to have succeeded, and every Deployment and StatefulSet to be fully rolled out. ### Moving an Argo CD install off `generatedSecrets.render: true` If Argo CD ever synced this chart with `generatedSecrets.render: true`, each render wrote new random internal credentials into the Secrets. Several things keep this hidden: * **The diff doesn't show it.** `ignoreDifferences` on Secret data hides the change from the diff but not from the sync. * **`RespectIgnoreDifferences` doesn't stop it** when it covers only `/data`, because the chart renders `stringData`. * **The servers keep the old values.** RabbitMQ keeps the password it stored on first boot. Zitadel's master key encrypts its stored keys, and LiteGit's vault key encrypts provider credentials, so the old values stay authoritative there. * **Running pods keep working until they restart.** An upgrade restarts all of them, and then RabbitMQ logins, Zitadel and Git integrations fail together. Before the first sync with `values-argocd.yaml`: 1. Turn off automated sync and make sure no operation is running. 2. Run the `pre` check. If `secrets.match_running_pods`, `rabbitmq.accepts_secret` or `zitadel.credentials` fails, the Secrets no longer hold the values the servers use. 3. Recover the original bytes from your own backup, or from the newest Helm release record in the namespace (`sh.helm.release.v1.qodo.v`, written by the last direct `helm install` or `helm upgrade`). Put them back into the six generated credential Secrets and `qodo-pr-agent-secrets-toml`. Restore Zitadel's master key and LiteGit's vault key exactly: regenerating them loses the data they protect. 4. The database setup Job resets the `zitadel` role's password whenever it runs. If the role rejects the restored `ZITADEL_DB_PASSWORD`, set it from a database admin session with `ALTER ROLE zitadel PASSWORD`. If RabbitMQ rejects every candidate, set the broker to the Secret's value with `rabbitmqctl change_password qodo` instead of generating a new one. 5. Annotate the Secrets `argocd.argoproj.io/sync-options: Prune=false` and restart the Qodo Deployments so every pod reads the restored values. Repeat the `pre` check until it reports GO. A rollback needs the same care: restore the database backup and the same Secret bytes, then sync the older version with `values-argocd.yaml`. Re-rendering an older chart with `render: true` writes yet another random set. Rolling back from 7.x to 6.x also needs a RabbitMQ step, because the 7.x topology migration converts the event queues on the broker's own volume and a database restore does not touch it. The 6.x consumers then fail with `PRECONDITION_FAILED - inequivalent arg`. Before syncing the older version: 1. Scale `qodo-litegit` (the publisher) to 0. 2. Wait until `vcs-events.pr-agent-pro-__pass_through__` and `vcs-events.qodo-platform-rules-consumer` show 0 messages (`rabbitmqctl list_queues name messages`). 3. Delete those two queues with `rabbitmqctl delete_queue`. The 6.x consumers recreate them as classic queues when they start. Before retrying the upgrade after a rollback, delete the setup and migration Jobs of the version you rolled back from. Their names depend only on the chart and values, so a retry with the same chart reuses the completed Jobs, and the database and queue migrations would not run against the restored state. The `pre` check fails with `jobs.will_run` in this case and prints the exact `kubectl delete job` command. ### Argo CD operations during an upgrade * Argo CD runs one operation per Application at a time. While a sync waits for an unhealthy resource, later sync requests queue behind it. Terminate the operation and wait for a terminal phase before syncing again. * Argo CD before 3.3.15, 3.4.9 and 3.5.3 can replay the previous result, without applying anything, when a sync is started by writing the Application's `operation` field directly (scripts, `kubectl patch`). Syncs started from the Argo CD UI or CLI are not affected. This is argoproj/argo-cd#26530, fixed by #28778. After any scripted sync, check that the operation's start time changed. * Do not use "apply only" (skip hooks) or a selective sync to get past a failing step. Both skip the RabbitMQ topology migration and the revision roll, so the workloads move to the new version without them. * If the RabbitMQ topology Job reports `rejected user 'qodo' (HTTP 401)`, the password in `qodo-rabbitmq-password` does not match the broker. Fix the credential as described above; syncing again cannot. * Any chart or values change gives every setup and migration Job a new name, so all of them run again. The previous revision's Jobs then show as "requires pruning". Remove them with a pruning sync (`PruneLast=true`) once every tracked credential Secret carries `Prune=false`, or delete them by hand. ### Azure SAML with Login V1 For a SAML enterprise application without Graph `User.Read`, see [SAML-LOGIN-V1.md](SAML-LOGIN-V1.md). It includes the platform release prerequisite, provider Secret, values overlay, claims mapping and Azure callback settings. # Qodo on-premise deployment architecture Source: https://docs.qodo.ai/on-prem/qodo-on-premise/architecture Understand how Qodo's on-premises deployment is structured across Git integration, AI processing, and Context Engine layers. Qodo's on-premises deployment runs entirely within your infrastructure. All components are deployed as containerized services on Kubernetes and communicate internally. No data leaves your environment. The deployment consists of three main layers: * **Git Integration**: Connects to your Git provider (GitHub, GitLab, or Bitbucket) via webhooks to trigger code review on pull requests. * **AI Processing**: Routes requests to your configured AI models (OpenAI, Anthropic, or cloud-hosted equivalents) to generate review findings. * **Context Engine** (optional): Indexes your repositories to provide deeper codebase-aware analysis during reviews. Qodo On-Premise Architecture Qodo On-Premise Architecture # Prerequisites Source: https://docs.qodo.ai/on-prem/qodo-on-premise/critical-prerequisites Obtain the Replicated container registry credentials required before installing any Qodo on-premises component. #### Container registry access (Replicated) **IMPORTANT:** All Qodo on-premises deployments require credentials to access container images through Replicated. **Image registries** * `artifacts-self-hosted.qodo.ai` * `artif-reg-self-hosted.codium.ai` **Authentication required** * You must have credentials provided by Qodo. **Login command** ```bash theme={null} helm registry login artifacts-self-hosted.qodo.ai \ --username $provided_user \ --password $provided_password ``` Before starting any installation, ensure you have received your Replicated credentials from Qodo. # Infrastructure requirements Source: https://docs.qodo.ai/on-prem/qodo-on-premise/infrastructure-requirements Kubernetes cluster, tooling, resource, and network requirements for deploying Qodo on-premises. ## Kubernetes cluster * Kubernetes version 1.24 or higher * Supported distributions: Any K8s-compatible platform (`GKE`, `EKS`, `AKS`, `OpenShift`, `Rancher`, vanilla `k8s`) * Network connectivity to `artifacts-self-hosted.qodo.ai` and `artif-reg-self-hosted.codium.ai` ## Tools required * `helm` * `kubectl` - configured with cluster admin access ## Resources | Component | CPU request | Memory request | | :- | :- | :- | | Qodo Git | 1 | 10Gi | | Qodo IDE | 4 | 12Gi | | Indexer | 500m | 2Gi | | Metadata Service | 500m | 2Gi | | Context Engine | 500m | 2Gi | ## Network requirements * Kubernetes cluster must be able to reach Qodo's container registries * Access to external AI model APIs (`OpenAI`, `Anthropic`, `Vertex AI`, `AWS Bedrock`) or self-hosted LLMs * Connectivity to your Git provider (`GitHub`, `GitLab`, `Bitbucket`) # Qodo on-premises installation overview Source: https://docs.qodo.ai/on-prem/qodo-on-premise/installation-process-overview Understand the four phases of installing Qodo on-premises, from preparation and deployment to configuration and validation. This guide provides an overview of how to install Qodo on-premises. The installation consists of four phases: preparation, deployment, configuration, and validation. Use this guide to understand the overall process, then follow the detailed documentation for each part of your installation. ## Phase 1: Preparation Before deploying Qodo, prepare your Kubernetes environment, credentials, and external dependencies. Make sure your environment meets the requirements for a Qodo on-premises deployment. * [Review the critical prerequisites](./critical-prerequisites) * [Review the infrastructure requirements](./infrastructure-requirements) * [Review the network and security requirements](./network-and-security-considerations) Contact Qodo to receive your Replicated registry credentials and verify access to the required registries. Prepare the external services required for your deployment, including: * AI model access * Git provider access and authentication * Network connectivity between Qodo and external services Have the information required for your deployment available, including: * Registry credentials * AI model credentials * Git provider credentials * Domain names and TLS certificates * Organization or team configuration ## Phase 2: Deployment Deploy Qodo using Helm. The deployment process includes: 1. Obtaining the required Helm chart. 2. Configuring deployment values and secrets. 3. Deploying Qodo to your Kubernetes cluster. 4. Verifying that the Qodo services are running successfully. ## Phase 3: Configuration After deploying Qodo, connect it to your Git provider and configure the required settings. **Connect your Git provider** Select your Git provider and follow the corresponding installation guide: * [GitHub](../git-integration/install/github) * [GitLab Cloud](../git-integration/install/gitlab-cloud) * [GitLab Server](../git-integration/install/gitlab) * [Bitbucket Cloud](../git-integration/install/bitbucket-cloud) * [Azure DevOps](../git-integration/install/azure-devops) * [Gerrit](../git-integration/install/gerrit) Each guide covers the provider-specific authentication, permissions, webhooks, and configuration required to connect Qodo. ## Phase 4: Validation After deployment and configuration, verify that Qodo is running correctly and can communicate with the required services. Confirm that the Qodo services are running successfully in your Kubernetes cluster. Confirm that Qodo can connect to your Git provider and other required external services. Trigger a test code review through your Git provider to verify that the integration is working correctly. If validation is successful, your Qodo on-premises deployment is ready for use. # Network and security considerations Source: https://docs.qodo.ai/on-prem/qodo-on-premise/network-and-security-considerations Network connectivity requirements and security best practices for Qodo on-premises deployments. ## Network requirements **Outbound connectivity required:** * `artifacts-self-hosted.qodo.ai` - Helm chart and image registry * `artif-reg-self-hosted.codium.ai` - Container images * AI model provider endpoints (api.openai.com, api.anthropic.com, etc.) * Git provider APIs (github.com, gitlab.com, or your self-hosted instances) **Inbound connectivity required:** * Git provider webhooks must reach your ingress endpoints * Developer IDEs must reach Qodo API endpoints * (For Context Engine) Context retriever MCP endpoint **Firewall considerations:** * Allow outbound HTTPS (443) to all external dependencies * Allow inbound HTTPS (443) for webhooks and API access * Ensure K8s cluster can reach external PostgreSQL if not in-cluster ## Security best practices **Secrets management:** * Use Kubernetes secrets for all sensitive data * Never commit `.secrets.toml` files to version control * Consider External Secrets Operator for centralized secret management * Rotate API keys and credentials regularly **Network policies:** * Restrict pod-to-pod communication * Limit egress to only required endpoints * Implement namespace isolation **Access control:** * Use RBAC for Kubernetes access * Implement principle of least privilege * Use service accounts with minimal permissions **TLS/SSL:** * Always use TLS for external endpoints * Use cert-manager for certificate management * Configure proper certificate validation **Image security:** * Images come from trusted Replicated registry * Regular updates through Helm for security patches * Scan images for vulnerabilities if required by policy # Set up Qodo with the onboarding wizard Source: https://docs.qodo.ai/onboarding-wizard Connect your Git provider, apply a Review preset, and set up the Agentic Toolbox with the Qodo onboarding wizard. Available for multi-tenant, single-tenant, and on-premises deployments. The onboarding wizard guides you through the essential setup for getting code reviews from Qodo, from connecting your code to choosing how Qodo reviews it and bringing Qodo into your developers' coding tools. Each step shapes how Qodo reviews your team's pull requests. Once the wizard is complete, Qodo reviews every new pull request automatically. You can change any of your choices later. Only organization admins see the onboarding wizard. It opens automatically the first time an admin signs in to the Qodo portal. If you aren't an admin, see [Quickstart: From sign-up to your first code review](/get-started) for the steps that apply to every user. ## The onboarding journey
1 Connect Git

Connect Qodo to the Git provider that hosts your code. Connect Git →

2 Apply review preset

Answer questions about your team and apply the Review preset Qodo builds from your answers. Apply review preset →

3 Get Agentic Toolbox

Share the Agentic Toolbox with your team and install it on your machine. Get Agentic Toolbox →

## Before you begin Make sure you have: * **Admin access to your Git provider**: The required permissions differ by Git provider. See [Install Qodo in your Git provider](/install-qodo/install) to find your provider's installation guide. * **Node.js 20 or later**: Required only if you install the Agentic Toolbox on your machine during setup. See [Install Qodo Agentic Toolbox with the CLI](/agentic-toolbox/cli#prerequisites). ## Step 1: Connect Git Select the Git provider that hosts your code, then click **Next**. If your Git provider is self-hosted, select the self-hosted option that appears after you select the provider.
Onboarding wizard first screen showing the left panel and the Git provider selection
Complete the installation wizard for your Git provider. See [Install Qodo in your Git provider](/install-qodo/install). On the **Verify connection** step, Qodo checks the connection to your Git provider. The step shows the connection as loading while Qodo checks it, then as connected or failed. Once connected, it shows how many repositories are connected. Click **Next** to continue with the wizard. Qodo starts building context for your code reviews, and the following processes run automatically in the background: * [Repository sync](/governance/repositories/installations): Syncs each connected repository with Qodo. * [Pull request indexing](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status): Indexes each repository's pull request history. * [Cross-repo discovery](/governance/repositories/relationships): Finds relationships between your repositories. Track their progress from **Background activity** in the top-right corner of the portal. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). It's recommended to import your team's existing rules and skills, which lets Qodo enforce your coding standards in its reviews. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). ## Step 2: Apply review preset Qodo builds a Review preset from your answers to a few questions about your team. A Review preset is a set of configuration settings tuned to what your team needs most from code review. Answer the questions about your team's priorities and how your team works. Select as many answers as apply, then click **Next**. Qodo shows the suggested preset, including what it runs, how it shows findings in pull requests, and what it automates. To use a different preset, select it from the dropdown.
Onboarding wizard Apply review preset step showing the recommended preset, what it runs, and the Change preset button
Click **Apply preset**. To continue without answering the questions, click **Skip**. You can choose a Review preset or change individual settings later in **Configurations**. See [Configure code review with Qodo presets](/configuration/review-presets). ## Step 3: Get Agentic Toolbox The [Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview) brings Qodo's code understanding, standards, and review capabilities into your coding agent. In **Set up your team**, under **Share the install**, click **Copy message** to copy install instructions to send to your team. Each developer installs the Agentic Toolbox on their own machine.
Onboarding wizard Get Agentic Toolbox step with the Set up your team section expanded, showing Copy message and the codebase tool access dropdown
Under **Who can use the codebase tool?**, select who in your organization has access. The codebase tool lets the Agentic Toolbox answer questions from your connected repositories. You can change this later. See [Manage access to the Agentic Toolbox](/agentic-toolbox/manage-access-in-qodo-portal). To install the Agentic Toolbox on your own machine, expand **Install on this machine**, then copy and run the command for your operating system, **macOS / Linux** or **Windows (PowerShell)**. To connect an MCP client instead, expand the MCP client option below the command. See [Install Qodo Agentic Toolbox with the CLI](/agentic-toolbox/cli) and [Connect Qodo Agentic Toolbox with MCP](/agentic-toolbox/mcp). Click **Complete setup**. ## Complete setup The final screen confirms that Qodo now reviews every new pull request in your organization. Click **Go to Home**. ## Leave and complete setup later You can close the wizard at any step. Steps you've already completed stay saved, and background processes keep running. If you close the wizard before your Git provider connection completes, you start Connect Git from the beginning when you resume. Click **X** in the top-right corner of the wizard. In the **Leave setup?** dialog, click **Leave**. To return to the wizard instead, click **Continue setup**. To resume, click **Complete setup** at the bottom of the left sidebar. It shows how many steps you've completed. ## Next steps * [Set up your Qodo organization as an admin](/set-up-your-qodo-organization): Link your Git account, connect task management, and invite your team. * [Qodo portal quick tour](/qodo-portal-quick-tour): Find your way around the Qodo portal. * [Trigger a code review](/code-review/use-qodo-in-prs): Run a review automatically or on demand. # Qodo for Open Source Projects Source: https://docs.qodo.ai/open-source-program Free AI-powered code review for eligible public open-source repositories on GitHub. Qodo Code Review for Open Source projects provides free AI-powered code review for public open-source repositories on GitHub. Qodo offers a free plan, in partnership with Google, for maintainers and contributors of public open-source projects. Eligible repositories receive AI-powered code reviews designed to improve pull request workflows, with fully managed hosting, and regular updates. ## Included features The Open Source plan includes core code review features directly in pull requests. Advanced features, including Rules and PR History, are available on paid plans. * [Generate code reviews](/code-review/use-qodo-in-prs/code-review) * [Generate PR summaries](/code-review/pr-summary) * [Ask questions with `/ask`](/code-review/ask-questions-with-ask) * [Automated review suggestions in pull requests](/code-review/use-qodo-in-prs) ## Eligibility Eligible repositories must: * Be public GitHub repositories * Have 200+ GitHub stars on the repository, or have at least one public repository in your organization with 200+ stars * Be actively maintained * Comply with Qodo usage policies ## Get started 1. Go to the [Qodo app on GitHub Marketplace](https://github.com/marketplace/qodo-merge-pro-for-open-source). 2. Install the Qodo app on the repositories where you want to use AI code review. 3. Open a pull request to receive an automated review, or use `/review` on an existing PR. **Have Qodo Portal access?** If you have been granted access to the Qodo Portal and use GitHub, proceed to [Install Qodo for GitHub](/install-qodo/github/qodo-multi-tenant). If you are interested in gaining access to the Qodo Portal, contact Qodo. # Qodo Research Preview Program Source: https://docs.qodo.ai/preview-research-program Learn about the Qodo Research Preview program, what to expect from early-access features, and which features are currently available. Research Preview Features set as Research Preview are under active development. Functionality and results may evolve as we continue to improve the feature. Research Preview features are not covered by any SLA and may be discontinued at any time. We recommend reviewing and validating outputs before use, and advise against using these features in production or business-critical workflows. The Research Preview program provides early access to features that are under active research. These features allow you to explore new capabilities, provide feedback, and help shape future improvements before broader release. ## What to expect * Features may evolve as development continues. * Functionality, behavior, and user experience may change over time. * Feedback helps guide future enhancements. * Results should be reviewed and validated before use in critical workflows. * Features are removed from the Research Preview program once they advance to Beta or General Availability. * Quality of results can be low. ## Research Preview features The following features are currently available as part of the Research Preview program. | Feature | Description | | - | - | | [PR Triage](/governance/pr-triage) | Brings your organization's open pull requests across repositories and Git providers into one shared queue. Use configurable triage policies to prioritize review work by SLA, priority, and blast radius, and understand which pull requests need attention and why. | | [Remediation Agent](https://docs.qodo.ai/code-review/remediate-findings-in-prs) | Identifying an issue is only the first step. Resolving review findings often requires developers to switch context, implement changes, validate the fix, and update the pull request. As findings accumulate, these additional steps can slow down reviews and delay merges. | | [Spec Agents](/code-review/view-requirement-gaps-in-findings) | Reviews pull requests against linked specification documents to verify that implementation matches documented requirements. It identifies missing requirements, incomplete implementations, and deviations from the intended design before code is merged. | | [Design review Agent](/code-review/view-ux-deviations-in-findings) | Reviews pull requests against linked Figma designs and design system components to verify that UI implementations match approved designs. It helps identify UX deviations, missing design requirements, and design system inconsistencies before code is merged. | | [Apply REVIEW.MD to code review](/governance/use-review-md) | Applies repository-specific review guidelines defined in a `REVIEW.md` file during automated code review, helping review agents prioritize findings, reduce noise, and enforce your team's engineering standards. | # Qodo pricing & usage Source: https://docs.qodo.ai/pricing-and-usage Understand how Qodo pricing, billing, credits, and workspace usage are structured. Qodo uses a workspace-based, usage-driven billing model. All users have access to the same product capabilities, and usage is tracked through shared workspace credits. For detailed pricing and credit information, see the [Pricing page](https://www.qodo.ai/pricing/). ## Workspace as the billing entity In Qodo, billing and usage are managed at the workspace level: * One shared credit pool per workspace. * All users and activity within a workspace draw from the same credits. * No per-user or per-engineer provisioning. * Multiple workspaces per account are not supported. Workspaces define billing boundaries, usage accounting, and collaboration scope. ## Free trial starting point for everyone Every workspace begins with a 14-day free trial starting at signup. This is the universal entry point into Qodo. The trial provides full access to the product with unlimited usage and operates within the same workspace and credit system used after the trial. When the trial ends, usage stops unless a paid billing setup is active. The trial is the initial state of every workspace, not a separate plan or tier. ## Billing model Qodo uses a credit-based usage system with the following billing and consumption rules: * Credits are shared at the workspace level. * Credits are consumed based on feature usage. * Base credits renew on a monthly cycle. * Usage continues beyond included credits through overage billing. * Overage is charged at the same per-credit rate as the base plan. * Overage accrues against a configurable monthly spending cap. * Billing is usage-based (not seat-based). * No annual self-serve billing option. ## Post-trial usage After the 14-day free trial, the workspace continues under a paid billing model. Included credits renew monthly, and usage beyond the included credits is billed as overage up to the workspace's configured spending limit. Full product access remains available while billing is active. ## Billing options After the trial, workspaces continue under one of two billing arrangements. ### Pro Teams Pro Teams is the standard self-serve offering for teams using Qodo in production. * Full product access. * Credit-based usage. * Shared workspace credits. * Unlimited users per workspace. ### Enterprise Enterprise is designed for larger organizations with additional commercial requirements. * Full product access. * Credit-based usage. * Shared workspace credits. * Enterprise support, pricing structure, and deployment options. Both options use the same underlying product and usage model. ## Check your workspace billing status Beta To view your workspace's current billing and usage status, open the [Billing and analytics page](https://app.qodo.ai/account/billing/analytics). The **Billing** page located in the Qodo portal under the **Account Management** section provides an overview of your workspace's plan, credit balance, usage, and renewal status. Billing page ### Billing summary At the top of the page, you can see: * **Current plan**: The billing plan currently assigned to your workspace. * **Credits remaining**: The number of credits remaining in the workspace's current credit pool, along with the total included credit allocation. * **Reviews this period**: The number of reviews run during the current billing period, with the total number of reviews for the year shown below. * **PRs reviewed this period**: The number of pull requests reviewed during the current billing period, with the yearly total shown below. * **Renews in**: The number of days until the workspace's billing period renews, along with the renewal date. You can also explore your workspace's usage in two views, **Analytics** provides a visual overview of usage over time, while **Transaction history** shows individual billing and credit transactions. ### Usage analytics Select **Analytics** to see how your workspace uses its credits over time. Use the date range selector to view a specific period, and switch between **Credits**, **Reviews**, and **PRs** to see different usage metrics. The chart shows daily usage for the selected period, helping you understand how quickly the workspace is consuming credits and how review activity contributes to usage. ### Transaction history Select **Transaction history** to view the workspace's billing transactions and credit activity. For more information about how credits are allocated and consumed, see [Billing model](#billing-model). ## Related resources * [Official pricing page](https://www.qodo.ai/pricing/): Check out the complete pricing, credit allocation details, and purchasing options. # Qodo portal quick tour Source: https://docs.qodo.ai/qodo-portal-quick-tour A quick tour of the Qodo portal for configuring your code review experience and managing Qodo access across your organization. A quick tour of the Qodo portal for managing your organization and governing code reviews at scale. The Qodo portal is the central administration interface for configuring and managing how Qodo operates across your organization. It connects directly to your Git workflows and uses AI-powered review agents to analyze pull requests, detect issues, enforce engineering standards, and surface insights across your codebase. Access the portal by signing in at [https://app.qodo.ai](https://app.qodo.ai). **Home** is the page that you land on when signing in to the Qodo portal. It shows recent code review activity, suggested actions for configuring Qodo, and the connection status of your Git providers and task management tools in the Connections panel. Qodo portal Home page showing recent code review activity, suggested actions, and Git provider and task management connection status in the Connections panel In the top right-hand corner, under **Connections** > **Git providers**, the icons show connection status, and the **+** button opens the selection page for the Git provider installation wizards. * **Organization admin, first sign-in**: The onboarding wizard opens automatically. To finish it later, click **Complete setup** at the bottom of the left sidebar. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). * **Organization admin, Git provider already connected**: Clicking a provider's icon opens the filtered Installations page. Use the **+** button to connect another provider. * **Non-admin**: The Git provider icons and the **+** button are disabled, with a tooltip explaining that you need organization admin permissions to connect a Git provider. ## How the Qodo portal is organized The Qodo portal is organized into two primary areas: * **Manage your Qodo account:** Control users, teams, access, authentication, and organization settings. For more information, see [Account management](/account-management/manage-your-qodo-account). * **Manage code review governance:** Configure how Qodo reviews code, enforce engineering standards, monitor findings, and measure adoption across your organization. For more information, see [Customize the code review experience](/configuration) ## Manage your Qodo account Manage the people, access, and settings that enable your organization to use Qodo. This area helps administrators control authentication, user access, team structure, and account-level preferences. ### Roles and permissions Control access to Qodo features by assigning roles and permissions across your organization. ### Users Add, remove, and manage users who have access to your Qodo organization. ### Teams Create and manage teams to organize users and simplify administration. ### Account settings Configure organization-level settings and preferences. ### API key management Create and manage API keys for integrations and automated workflows. ### Single sign-on (SSO) Configure SSO to centralize authentication and simplify user access management. ### Restrict organization sign-up to invited users Restrict organization membership so users can join only through administrator invitations. ### Connect Qodo Git integration Link your Git account to access repositories and enable code review workflows. See [Manage your Qodo account](/account-management/manage-your-qodo-account). ## Manage code review governance Configure how Qodo reviews code across your organization. This area helps engineering leaders define review standards, manage repositories, monitor findings, measure impact, and integrate Qodo into the development workflow. ### Repositories Connect and manage repositories that Qodo analyzes during pull request reviews. ### Review standards Define and manage engineering standards that Qodo enforces during code reviews. ### Skills Manage review skills that provide specialized analysis across domains such as security, architecture, performance, documentation, and best practices. ### Findings View and track findings identified across repositories and pull requests. ### Analytics Measure code review activity, adoption, engagement, and impact through organization-wide dashboards and reporting. ### Configurations Configure organization-wide review behavior, review settings, and remediation workflows. ### Integrations Connect Qodo with Git providers, ticketing systems, IDEs, and other tools used throughout your development workflow. ## Monitor Qodo's background activity Once you connect your Git provider, Qodo starts the following processes in the background. Track their progress from **Background activity**, in the top navigation on every page. * **Repository sync**: Syncs each repository with Qodo. * **Pull request indexing**: Indexes each repository's pull request history. * **Cross-repo discovery**: Finds relationships between repositories. * **Rules and skills import**: Imports the rules and skills you select. If a process needs attention, see [Troubleshoot background processes](/governance/troubleshoot-background-processes). ## Get started * [Manage your Qodo account](/account-management/manage-your-qodo-account) * [Manage code review governance](/code-governance) # Get support Source: https://docs.qodo.ai/qodo-support Get help, check system status, and access resources for Qodo. Contact Qodo support for help or questions: * **Email:** [support@qodo.ai](mailto:support@qodo.ai) ## System status Check the current system health and incident updates: * [Qodo Status](https://status.qodo.ai) ## Deployment models and subscription plans For information about deployment types, subscription plans, and features: * [Deployment models](/deployment-models) * [Subscription plans](/subscription-plans) # Set up your Qodo organization as an admin Source: https://docs.qodo.ai/set-up-your-qodo-organization Create your Qodo account, set up code review for your organization with the onboarding wizard, and bring your team on board. As an organization admin, you set up Qodo once for everyone on your team. The onboarding wizard covers the essentials, and a few recommended steps connect your tools and bring your team on board. Once you finish, Qodo automatically reviews every new pull request in your connected repositories. ## Step 1: Create your account Go to [app.qodo.ai/signin](https://app.qodo.ai/signin) and choose how you'd like to sign in. Select your Google account and you'll be redirected back to Qodo automatically. Enter your GitHub credentials, click **Authorize**, and you're in. Enter your email, check your inbox for a verification link, and click to activate. ## Step 2: Set up Qodo using the onboarding wizard The first time you sign in, the onboarding wizard opens and guides you through the setup that matters most. Each step walks you from start to finish, and by the end, Qodo is reviewing your team's pull requests with settings that fit how your team works: * Connecting Qodo to your Git provider * Building a Review preset from your answers about your team * Setting up the Agentic Toolbox for your developers You can leave the wizard at any point and complete it later. See [Set up Qodo with the onboarding wizard](/onboarding-wizard). ## Step 3: Connect your tools Connect the tools that give Qodo more context about your team's work. Every user links their own Git account, which lets Qodo identify their pull requests and commits. 1. Click your name at the bottom of the left sidebar. 2. Select **Link your Git user account**. See [Account management](/account-management/manage-your-qodo-account#additional-settings). Connect your team's ticketing tools, which lets Qodo check each pull request against its linked ticket. 1. Navigate to **Integrations**. 2. Select your ticketing tool and follow its setup guide. To let other users connect tools, grant them edit access to Integrations. See [Delegate edit permissions](/account-management/delegate-edit-permissions) and [Use ticket context in code reviews](/integrations/ticketing-integrations). ## Step 4: Invite your team Bring the rest of your team into Qodo. On Enterprise plans, team owners can also invite users to their own team. Navigate to **Users**. In the top-right corner of the page, click **Invite members**. Enter one or more email addresses. To invite users in bulk, upload a file instead. Click **Invite**. Each invited user receives an email to join your organization. See [Manage users in the Qodo portal](/account-management/users#invite-team-members). ## Step 5: Open a pull request Once connected, Qodo automatically reviews every pull request in your linked repositories. Open a pull request and Qodo will: Your team's standards enforced on every change, automatically. Bugs, risks, and standard violations, explained and prioritized. Multi-agent review across your entire codebase, not just the diff. ## Next steps * [Set up Qodo with the onboarding wizard](/onboarding-wizard): Walk through each step of the onboarding wizard. * [The Qodo Code Review experience](/code-review): Learn how Qodo reviews your pull requests. * [Qodo portal quick tour](/qodo-portal-quick-tour): Find your way around the Qodo portal. # Sunsetting legacy v1 commands Source: https://docs.qodo.ai/sunsetting-legacy-v1-commands Learn which legacy v1 commands are being deprecated and removed, the timeline for each batch, and what v2 alternatives are available. Qodo is sunsetting selected legacy v1 commands as we consolidate functionality around the current Qodo experience. The sunset happens in two batches: * September 1, 2026: Selected v1 commands are deprecated. When you use a deprecated command, Qodo provides guidance and, where available, links to the recommended alternative. * October 1, 2026: The remaining affected v1 commands are permanently removed. If you use any of the affected commands listed below, update your workflows before the commands are removed. ## Timeline | **Date** | **What happens** | | - | - | | September 1, 2026 | Batch 1: Selected v1 commands are deprecated. When you use a deprecated command, Qodo provides guidance and, where available, links to the recommended alternative. | | October 1, 2026 | Batch 2: The affected v1 commands are permanently removed. | ## Batch 1: Commands being deprecated The following v1 commands are deprecated starting September 1, 2026: | **v1 command** | **v2 alternative** | | - | - | | `test` | No direct replacement | | `improve_multi` | `agentic_review` | | `update_changelog` | No direct replacement | | `custom_prompt` | `agentic_review` | | `improve_code` | `agentic_review` | | `config` | No direct replacement | | `add_docs` | No direct replacement | | `help` | Qodo documentation | | `create_ticket` | No direct replacement | | `inline_comment_router` | Handled by the agentic engine | | `improve_component` | `agentic_review` | | `implement` | `fix` | ## Batch 2: Commands moving to v2 alternatives The following v1 commands are being migrated to their v2 alternatives: | v1 command | v2 alternative | | - | - | | `describe_legacy` | `agentic_describe` or `describe` | | `agentic_describe_legacy` | `agentic_describe` | | `generate_labels` | `agentic_describe` | | `checks` | No direct replacement | ## What you need to do If you use an affected v1 command: 1. Identify where the command is used, including scripts, automation, and regular workflows. 2. Check which batch applies to the command. 3. Review the recommended v2 alternative, if one is available. 4. Update your workflows before the command is permanently removed. 5. Test your updated workflows to make sure they continue to work as expected. If a command does not have a direct replacement, its functionality will no longer be available after removal. ## Frequently asked questions Qodo is consolidating functionality around the current Qodo experience. This reduces duplication, simplifies the command experience, and allows Qodo to focus improvements on current product capabilities. No. This announcement applies only to the v1 commands listed in the two batches on this page. See the tables above for the recommended v2 alternative for each affected command. Some commands do not have a direct replacement because their functionality is being removed or is now handled elsewhere in Qodo. Starting September 1, 2026, Qodo displays a message explaining the change and, where available, provides links to the relevant documentation and recommended alternatives. The affected commands are scheduled for permanent removal on October 1, 2026. Yes. If you use an affected command in scripts, automation, or regular workflows, update them to use the recommended alternative before the command is permanently removed. If you have questions about the sunset or need help identifying the appropriate alternative, contact your Qodo account manager. # Qodo's daily tips Source: https://docs.qodo.ai/tips-and-tricks Qodo appends a rotating tip to every pull request (PR) summary comment, each one a way to discover and take full advantage of Qodo's code review capabilities. This page collects them all in one place, instead of waiting for each one to appear on a PR. Tip of the day section in a pull request summary comment, with links to more tips, customizing Qodo, and the Qodo docs To stop seeing daily tips in your code review, disable **Show tip of the day** under **Comment parts** on the [Display](https://app.qodo.ai/configurations?tab=display) tab in your Qodo portal. Open a finding's Evidence section to jump directly to the source. Rule violations link to the rule on the **Rules** page, and cross-repo conflicts link to the relationship that caused them. Use these links to check or fix the underlying cause. See [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#unpack-a-code-review-finding) for the full guide. Click **Import rules and skills**, then select only the Git organizations or repositories whose standards matter to your team. Qodo imports rules and skills from those sources alone, so findings stay focused and noise-free. See [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills) for the full guide. By default, findings you fix stay in the review comment, struck through. To keep the comment focused on open findings, navigate to **Configurations** > **Display** > **Resolved findings** and move resolved findings to a separate Resolved findings section, or turn off **Show resolved findings** to hide them entirely. See [Track resolved findings](/code-review/track-resolved-findings). Choose Lean, Balanced, Robust, or Custom from the display mode selector to instantly shape how much detail Qodo surfaces in your reviews. No need to toggle each Display setting one by one. See [Configure Qodo using the portal](/configuration/display#display-modes) for the full guide. Qodo scores each pull request as Large, Medium, or Small blast radius based on the scope and sensitivity of the change, and posts it as a native PR label so you can triage review effort straight from the PR list. See [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius) for the full guide. Start any PR comment, review comment, or inline code comment with `qodo`, `@qodo`, or `/qodo`, or open with a greeting like `Hey qodo`, to chat with Qodo about a finding. Ask it to explain the issue, discuss the suggestion, or ask follow-up questions in natural language. Qodo only responds when addressed, so reviewer discussions are never interrupted. See [Chat with Qodo in your pull requests](/code-review/chat-with-qodo-in-your-pull-requests) for the full guide. Tell Qodo to dismiss a finding and explain why. The finding is struck through and marked as Dismissed in the review comment, so the rest of the team sees the decision. See [Chat with Qodo in your pull requests](/code-review/chat-with-qodo-in-your-pull-requests) for the full guide. Reply to any finding to push back on a suggestion, request a deeper explanation, or refine the recommendation. Your feedback shapes the conversation on the PR. See [Chat with Qodo in your pull requests](/code-review/chat-with-qodo-in-your-pull-requests) for the full guide. **Displayed labels** controls which labels appear on each finding (severity, finding type, finding category, relevance), and **Label style** controls whether they show as icon and text or icon only. Find both in the portal under **Configurations > Display > Labels**, which has a live preview of your review comment. See [Configure Qodo using the portal](/configuration/display#labels) for the full guide. Under **Configurations > Remediation**, turn on the Remediation agent and Qodo fixes review findings for you, delivered as a dedicated fix PR or pushed directly to your source branch. Set an auto-fix severity threshold to control which findings it picks up. See [Remediate findings in your pull request](/code-review/remediate-findings-in-prs) for the full guide. Type `qodo, fix the null pointer issue in this PR` and the chat agent applies the fix without you leaving the PR. This is best for targeted fixes where you want control over what changes. See [Remediate findings in your pull request](/code-review/remediate-findings-in-prs) for the full guide. On the **Rules** page in the portal, describe the rule you want in plain language, such as "Restrict console.log in prod builds", and Qodo drafts it for you, complete with examples and severity. See [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules) for the full guide. Turn on the rule miner and Qodo discovers your team's standards automatically from your code review history, turning them into enforceable rules. See [Generate rules from pull request history with Rule Miner](/governance/rule-enforcement/rule-miner) for the full guide. Add a `REVIEW.md` file at your repository root and Qodo applies the review instructions and guidelines it contains on every PR. It is a simple, repo-local way to customize your review. See [Apply REVIEW.md instructions to code review](/governance/use-review-md) for the full guide. Under **Advanced comment routing overrides** on the Display tab, decide where each severity lands: inline comments, the summary comment, both, or dropped entirely. High-severity findings always stay on at least one surface. See [Control review verbosity in pull requests](/code-review/review-verbosity) for the full guide. **Findings visible per group** collapses all but the top findings per severity behind a "View" link, so the summary stays scannable on busy PRs. See [Reduce review noise on pull requests](/code-review/reduce-review-noise) for the full guide. The description, code snippet, relevance, evidence, and agent prompt can each be set to hidden, collapsed, or expanded, so you can tune the comment from lean to verbose. See [Control findings visibility and expansion in pull requests](/code-review/findings-visibility) for the full guide. Every finding can include a copy-paste agent prompt. Hand it to your IDE agent to implement the fix with full context. See [Anatomy of a Qodo Code Review](/code-review/comment-anatomy) for the full guide. Adjust your Display settings in the portal and a live preview shows exactly how your review comment will render as you change settings, so you can see the result before it ships. See [Configure Qodo using the portal](/configuration/portal-configuration) for the full guide. Enable committable code suggestions to apply Qodo's fix directly from the inline comment. Supported on GitHub and GitLab. See [Commit code fixes directly in the pull request](/code-review/commitable-code-suggestions) for the full guide. Prefer not to see the rotating tip on your PR comments? Turn off **Show tip of the day** in the portal under **Configurations > Display > Comment parts**. With the daily tip disabled, Qodo stops appending it to your PR summary comments. Open [Display](https://app.qodo.ai/configurations?tab=display) in the Qodo portal. Turn off **Show images and animations** under **Configurations > Display > Notification comments** and Qodo renders text and markdown equivalents instead of the illustrations, dividers, section badges, and footer logo. Handy for air-gapped setups where the image host is unreachable, or if you simply prefer a plain comment. See [Configure Qodo using the portal](/configuration/portal-configuration) for the full guide. Each block in a finding can be hidden outright rather than just collapsed, so the parts your team never opens stop taking up room in the comment. Set them under **Configurations > Display > Findings**. See [Control findings visibility and expansion in pull requests](/code-review/findings-visibility) for the full guide. # What's new Source: https://docs.qodo.ai/whats-new Explore the highlights of our most significant releases. For a full version-by-version breakdown, see the [Qodo Changelog](/changelog).
## Qodo 3.0 *Released 1 October 2026* ### Manage pull request bottlenecks with PR Triage (Research Preview) Introducing PR Triage, a new way to manage review work across your organization. See your open pull requests across repositories and Git providers in one shared queue, with a default triage policy applied automatically. You can customize how pull requests are prioritized using SLA, priority, and blast radius, and apply policies at the workspace, Git organization, or repository level for more granularity. Use PR Triage to: * **Prioritize review work:** Apply configurable policies for SLA, priority, and Blast radius. * **Find bottlenecks:** Identify pull requests that need attention and understand what is blocking progress. * **Explore related work:** See PR stacks and cross-repository relationships that affect the review workload. * **Investigate pull requests:** Review findings, checks, effort, ownership, and prioritization signals in one place. For more information, see [Manage review bottlenecks using PR Triage](/governance/pr-triage). ### New Onboarding wizard: Set up Qodo end to end The new onboarding wizard takes organization admins through the complete Qodo setup in one guided flow, from connecting your Git provider and customizing code review for your team to bringing the Agentic Toolbox to your developers. To customize code review, answer a few questions about how your team works, and Qodo builds a Review preset from your answers. Review presets are ready-made code review configurations, each tuned to a different goal, such as catching more issues, reducing noise, or getting through pull requests faster. You can switch presets at any time from the Configurations page. For more information, see [Set up Qodo with the onboarding wizard](/onboarding-wizard). ### Gerrit integration across all deployment types Qodo now fully supports Gerrit across multi-tenant, single-tenant, and on-premises deployments, enabling AI-powered code reviews and findings directly in your Gerrit changes. Connect your Gerrit instance to Qodo to automatically analyze changes, publish findings, and control code review at the project level. For more information, see [Install Qodo on Gerrit](/install-qodo/gerrit). ### Code review analytics dashboard (Beta) The new Analytics dashboard in the Qodo portal shows how your team responds to Qodo findings across pull requests, repositories, and PR authors. * **Impact:** See how Qodo findings affect pull requests and how many lead to accepted code changes. * **By repository:** Compare finding activity and acceptance rates across repositories. * **By PR author:** Understand how individual PR authors respond to Qodo findings. Filter by date range, repository, PR author, severity, category, and finding type. Select any number to open the findings behind it, or export findings to CSV. For more information, see [Qodo code review analytics dashboard](/governance/code-review-analytics). Code review analytics dashboard ### Rules and skills: Reduce noise by choosing exactly which rules and skills you import You control which rules and skills Qodo enforces, keeping every finding focused on the standards that matter to your team. Click **Import rules and skills**, select the Git organizations or repositories you want, and Qodo imports rules and skills only from those repositories. For more information, see [Importing rules and skills](/governance/rule-enforcement/building-review-standards#importing-rules-and-skills). Import rules and skills ### Open rules and relationships from a finding's evidence A finding's Evidence section now links to what caused it. Rule violations link to the rule on the Rules page, and cross-repo conflicts link to the exact repository relationship on the Relationships tab, so you can check or fix the source of a finding in one click. For more information, see [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#unpack-a-code-review-finding). ## Qodo 2.10 *Released 15 September 2026* ### View your Software Map across repositories (Beta) Software Map gives you a live view of your software system across repositories. Qodo automatically discovers your repositories and maps the dependencies and connections between them, including service relationships, contracts, and the potential blast radius of changes. The map updates with every pull request, so it reflects your current code without requiring you to create or maintain diagrams. Use Software Map to understand your system, assess the impact of changes, and identify areas where code review findings, risk, and technical debt are concentrated. Software Map also provides the system-level context that Qodo's agents use to understand your codebase. For more information, see [Gain insight with Software Map](/governance/repositories/gain-insight-with-software-map). ### Cross-repo auto-discovery across your organization (Beta) Qodo now maps relationships across your entire organization automatically, instead of one repository at a time. Repositories connected using a Qodo 2.10 Git provider installation wizard get their cross-repository relationships discovered automatically, with no manual setup, whether selected during installation or added later. For more information, see [Manage cross-repository relationships](/governance/cross-repo-code-review/repository-relationships#automatic-discovery-across-your-organization). ## Qodo 2.9 *Released 7 September 2026* ### Get Agentic Toolbox from leading marketplaces Agentic Toolbox is now available as verified plugins and a Power in leading marketplaces, and is now generally available (GA). Bring Qodo's review capabilities directly into your coding agent, with access to code understanding and coding standards: * [Claude plugin](/agentic-toolbox/claude-code-plugin) * [Codex plugin](/agentic-toolbox/codex-plugin) * [Kiro Power](/agentic-toolbox/kiro-power) For more information, see [Agentic Toolbox](/agentic-toolbox). ### Install Qodo on Bitbucket Data Center (on-premises) A new guided installation wizard for Bitbucket Data Center on-premises deployments connects your self-hosted server to Qodo in a few easy steps. Configure selected projects or your entire server, typically in around 5 minutes. For more information, see [Install the Bitbucket Data Center integration for Qodo on-premises](/on-prem/git-integration/install/bitbucket-data-center). ### Agentic Toolbox available on major marketplaces The Qodo Agentic Toolbox is available as a verified plugin on the Claude Code, Kiro, and Codex marketplaces. Install the Agentic Toolbox directly from your preferred marketplace to extend your coding agent with Qodo's code understanding, review, and coding capabilities. * [Claude Code marketplace](https://claude.com/plugins/qodo?utm_source=chatgpt.com) * Kiro marketplace * Codex marketplace See [The Agentic Toolbox](/agentic-toolbox/agentic-toolbox-overview) for more information and installation options. \*/} ### Assess code change risk using blast radius (Research Preview)
GitHub GitLab Azure DevOps
Qodo classifies the risk of a code change based on its scope and sensitivity, and can publish it as a native pull request label (a tag on Azure DevOps), helping teams triage which pull requests need the closest review directly from the pull request list. Each pull request receives one of three risk levels: **Large**, **Medium**, or **Small** blast radius. For more information, see [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius). ### Apply a code review configuration preset that matches your needs Easily select a code review configuration preset to match your needs, without having to set each Display option individually. Choose **Minimal** for a lean, low-noise review, **Comprehensive** for every label and group visible, **Standard** for the default balance, or **Custom** to configure each setting yourself. For more information, see [Configure Qodo using the portal](/configuration/display#display-modes). ### Visualize cross-repository relationships (Beta) Now you can get a visual representation of the state of your cross-repository relationships. Explore how your repositories connect, identify the repositories at the center of your architecture, and group related repositories into clusters. Switch between Map for exploring repository relationships and Monitor (Alpha) for seeing code review findings across related repositories, with filters for severity, category, and pull request state. Relationships tab in Map view showing repositories connected by relationship type, sized by connection tier For more information, see [View cross-repository relationships](/governance/repositories/relationships). ### Monitor background activity from anywhere in the portal Connecting a repository to Qodo automatically kicks off background processes, including repository sync, PR history indexing, cross-repo discovery, and rules import. **Background activity**, in the top navigation, shows these processes as they happen from anywhere in the portal. Each row is clickable, taking you straight to the relevant page. Background activity panel showing Repository sync, Pull request indexing, Cross-repo discovery, and Rules import status For more information, see [Qodo portal quick tour](/qodo-portal-quick-tour#monitor-background-activity). ### Sunsetting legacy v1 commands Selected legacy v1 commands are being deprecated starting September 1, 2026, and will be permanently removed on October 1, 2026. See [Sunsetting legacy v1 commands](/sunsetting-legacy-v1-commands) for affected commands, timelines, and recommended alternatives. ## Qodo 2.8 *Released 16 August 2026* ### Qodo's Agentic Toolbox (Beta) Bring Qodo’s code understanding, coding standards, review, and finding resolution directly into your coding agent workflow. The Agentic Toolbox extends your existing coding agent with Qodo tools it can use throughout development: * **Codebase Wisdom**: Understand your codebase, dependencies, relationships, and recent changes. * **Get Rules**: Retrieve the rules that apply to the current task before writing code. * **Review**: Review local changes using Qodo Review before creating a pull request. * **Review Resolver**: Retrieve and resolve Qodo Review findings from your agent workflow. * **Manage Standards**: Manage your organization’s Review Standards directly from your agent. The Agentic Toolbox works with supported coding agents through agent skills and is also available through the CLI, MCP Server, and other interfaces. For more information, see [Qodo's Agentic Toolbox overview](/agentic-toolbox/agentic-toolbox-overview). ### Advanced Git configurations
GitHub GitLab Azure DevOps
The **Configurations** page in the Qodo portal has been reworked with more intuitive categories organized around what each setting affects: **Display**, **Workflow**, **Context**, **Remediation**, and **Prompts**. You now have more control over how review results are organized, including the ability to group, order, count, and label findings by any finding dimension. Display settings are also more granular, with dedicated controls for counters, labels, grouping, ordering, overflow, finding content, and comment structure, each with a live preview of how changes appear in review comments. Severity terminology has also been updated for greater consistency. Configurations page Display tab showing Counters and Labels settings alongside a live preview of the review comment in a pull request For more information, see [Configure Qodo using the portal](/configuration/portal-configuration). ### Gerrit integration for on-premises deployments Qodo now supports native integration with Gerrit for on-premises deployments, bringing AI-powered code review directly into your self-hosted development environment. Qodo connects securely to your Gerrit instance using a dedicated Qodo user and webhooks, allowing it to receive change events and publish review findings directly in Gerrit. With this integration, Qodo: * Publishes AI-powered reviews and findings directly on Gerrit changes * Automatically analyzes changes when configured Gerrit events occur * Supports repository-level or global webhook configuration for flexible deployment * Lets you control which imported projects have code review enabled Once configured, Qodo automatically analyzes changes and delivers prioritized findings directly in the Gerrit workflow you already use. For more information, see [Install the Gerrit integration for Qodo on-premises](/on-prem/git-integration/install/gerrit/). ### Web search for dependency context (Research Preview) Qodo can search the web for current documentation, specifications, and release notes for third-party dependencies, helping produce more accurate review findings. Sources used by the review agent are shown in the Context sources section. For more information, see [Enrich context with up-to-date dependencies](/code-review/use-qodo-in-prs/third-party-dependencies-context). ### Daily tips in pull requests Discover more Qodo features and configurations directly from your pull requests with a rotating daily tip. Each tip links to relevant documentation and configuration pages, making it easier to find and use capabilities you may not know about. For more information, see [Qodo's daily tips](/tips-and-tricks). ## Qodo 2.7 *Released 29 July 2026* ### Review effort mode (Research Preview) Optimize AI code review effort by automatically matching review depth to the risk of each code change. Review effort mode analyzes each change and routes reviews to the appropriate level of analysis, helping reduce review time for low-risk updates while applying deeper scrutiny to higher-impact changes. You can also configure a fixed review mode for a repository. For more information, see [Optimize AI effort with Review effort mode](/code-review/use-qodo-in-prs/control-review-effort). ### PR history indexing PR history indexing is a core capability of [Qodo's Context Engine](/core-concepts/context-engine): it indexes your team's pull request activity, turning your repositories into an evolving record of how you actually review and ship code. That process has always run quietly in the background. Now it's exposed directly in the Qodo portal. A new PR history indexing column in the repository table shows this status for every repository, tracking indexing from the first pull request through ongoing updates. Open any repository's sidebar for the full detail: how many pull requests have been indexed, how many findings Qodo has learned from that history, and exactly which learning features, Rule Miner and Relevance, it has unlocked for that repository. Repository sidebar showing PR history indexing status Active, indexed date range, pull requests and findings learned counts, and Rule miner and Relevance availability For more information, see [Monitor and manage repositories](/governance/repositories/manage-repositories#check-repository-pr-history-indexing-status) and [Understanding PR history](/core-concepts/pr-history). ## Qodo 2.6 *Released 15 July 2026* ### Support for IdP-initiated SSO login Qodo now supports Identity Provider (IdP)-initiated login for Single Sign-On (SSO). Users can launch the Qodo application directly from their identity provider portal, such as Microsoft Entra ID or Okta, without first navigating to the Qodo sign-in page. This feature complements the existing Service Provider (SP)-initiated login flow, giving organizations the flexibility to choose the authentication experience that best fits their environment. For more information, see [Configure Single Sign-on (SSO)](/account-management/single-sign-on-sso). ### Repository-specific review guidance with REVIEW\.md (Research Preview) Customize Qodo code reviews by defining repository-specific instructions in a `REVIEW.md` file. Qodo uses these guidelines to tailor review feedback, prioritize important findings, reduce noise, and enforce your team's engineering standards across pull requests. For more information, see [Apply REVIEW.md instructions to code review](/governance/use-review-md). ## Qodo 2.5 *Released 30 June 2026* ### Automatic discovery of cross-repository relationships (Beta) Mapping how your repositories depend on one another just got automatic. For any repository, Qodo can discover its related repositories for you, instead of you defining every relationship by hand. Open a repository's cross-repository relationships, select **Auto-discover**, and Qodo surfaces the repositories it connects to. From there, it automatically reviews every relevant pull request for cross-repository impact. Prefer to map them yourself? Manual relationships are still fully supported. Repositories page with a repository's Cross repository relationships panel open, showing the Auto-discover button and a list of automatically discovered related repositories For more information, see [Cross-repository code review](/governance/cross-repo-code-review). ### Spec agents (Research Preview) Reviews pull requests against linked specification documents to verify that implementation matches documented requirements. It identifies missing requirements, incomplete implementations, and deviations from the intended design before code is merged. For more information, see [View requirement gaps in findings](/code-review/view-requirement-gaps-in-findings). ### Design review agent (Research Preview) Reviews pull requests against linked Figma designs and design system components to verify that UI implementations match approved designs. It helps identify UX deviations, missing design requirements, and design system inconsistencies before code is merged. For more information, see [View UX deviations in findings](/code-review/view-ux-deviations-in-findings). ## Qodo 2.4 *Released 16 June 2026* ### Catch breaking changes across repositories (Beta) Breaking changes that cross repository boundaries are the hardest to catch in review. A function signature shifts in a shared library, an API contract changes, or a schema evolves. Each passes single-repository review cleanly, and the breakage only shows up in production. Cross-repository code review closes that gap. You define the relationships between repositories, and Qodo automatically reviews every relevant pull request for cross-repository impact, across providers.