- Automated code reviews for newly created merge requests
- AI-powered suggestions displayed directly on merge requests
- Interactive assistance through the CodeRabbit bot for real-time feedback
- Seamless integration with your existing GitLab workflow
@coderabbitai — or the username of the service account you configure below, if it differs.GitLab Access Tokens
To enable CodeRabbit to interact with your GitLab repositories, you need to provide an access token that grants the necessary permissions for the Merge Requests and Discussions APIs.Group scope and permissions
For group-based setup, the person installing CodeRabbit and the identity behind the review token have separate permission requirements:Personal Access Token
Group Access Token
Personal Access Token
We recommend creating a new user as a service account, adding this user to the top-level GitLab group selected in CodeRabbit, and providing CodeRabbit with the personal access token to allow access. During the installation process, CodeRabbit will automatically configure the required webhook for seamless integration.

Best Practices for Service Account Setup
Follow these recommendations when setting up your CodeRabbit service account:- Username: Use “CodeRabbit” as the username for easy recognition
- Email: Use a dedicated email address for easy identification and management
- Profile picture: Use the CodeRabbit logo for easy recognition. Download our logo here
- Permissions: Ensure the dedicated user has at least Developer access to the top-level GitLab group selected in CodeRabbit
Important Considerations
- Navigate to the GitLab User page in the sidebar
- Enter the new access token and click the Update button
Generating a Personal Access Token
Log in to your CodeRabbit service account
Navigate to access tokens
- Select your avatar on the left sidebar 2. Choose Edit Profile 3. Select Access Tokens from the left sidebar 4. Click Add New Token
Configure token settings
- Enter a descriptive name for the token (e.g., “CodeRabbit Integration”)
- Set an expiry date for the token
Select required scopes
api - Full API access -
read_api - Read-only API access - read_user - Read user informationCreate and save the token
- Click Create Personal Access Token 2. Important: Copy and securely store the token immediately as it will only be displayed once

Fine-Grained Personal Access Token
api scope. If your security review cannot approve “complete read and write access to the API”, this is the option to use.
CodeRabbit accepts a fine-grained token anywhere a personal access token is accepted — paste it into the same field. Nothing else changes.
Generating a fine-grained token
Log in to your CodeRabbit service account
Add a fine-grained token
Set name, expiry, and resources
GET /user) sit on GitLab’s User boundary, so a group or project selection alone does not grant them.Selecting a group here is only about scope (covering every project under it in one token) — it does not require the group-level permissions below. Those are needed only for a group-level install (see Group access).Select permissions
api, read_api, or read_user scopes — those apply only to classic tokens; fine-grained tokens use the resource permissions below instead.Create and save the token
Required permissions
Grant these to the group or projects CodeRabbit reviews. This is the complete set CodeRabbit may call across the REST features below. For a review-only service account, the Project access and User access permissions are sufficient — the Group access permissions are needed only when CodeRabbit is installed on a group rather than on individual projects. A narrower set works if you do not use every feature — committing fixes needs Branch: Create, Branch: Delete and Commit: Create; CI failure analysis needs Pipeline: Read and Job: Read. Reviewing linked repositories for cross-repo context additionally needs Code: Read and Code: Download (clone access) on GitLab’s GraphQLRepository type, and each linked repository must itself be selected as a token resource — its clone uses the same token and otherwise falls outside the token’s resource boundary. The REST tables below do not cover these.
Project access
Group access
Required when CodeRabbit is installed on a group rather than on individual projects.User access
Identifies the service account itself and resolves the namespaces it can reach.If a permission is missing
GitLab rejects the call and names what it needed:Group Access Token
Creating a Group Access Token in GitLab automatically generates a bot user. Create the token in the top-level group selected in CodeRabbit, with Developer access or higher and theapi scope. The bot inherits access to that group’s subgroups and projects, but a token created in a subgroup does not grant access to its parent. To configure another top-level group, create a separate Group Access Token for that group.
Generating a Group Access Token
Navigate to your group
Access token settings
- Select Settings from the left sidebar 2. Select Access Tokens within the Settings heading
Create the token
- Select the
apiscope. - Select Developer or higher for the token’s role. The token itself does not need the Owner role.
- Create the Group Access Token.
group_63_bot_5753...). If you prefer a more descriptive username for your CodeRabbit bot, you can customize it using the GitLab API.You can find the user ID of the bot through the CodeRabbit UI if connected, or by visiting the bot user’s profile from your Group Members page in GitLab.Configuring Access Tokens in CodeRabbit
GitLab project Owners and Maintainers can install CodeRabbit on individual projects from the Repositories page without requiring top-level GitLab group Owner access, including projects inside subgroups. The Install Group action is restricted to GitLab group Owners. These installer permissions are separate from the review token’s group access requirements. By default, if no access token is provided, CodeRabbit prompts you to provide one during installation. To provide the token beforehand, open Account in the left sidebar, then under Provider settings, click GitLab User. Once you enter the token, CodeRabbit validates it and saves it for future use. You can confirm the correct user is being selected by verifying the user ID shown on the UI with the user ID of the service account user you created.Repository Installation
You can install CodeRabbit on individual GitLab projects or across a full GitLab group, depending on your GitLab role. Projects are selectable based on your permissions:- Project installation: GitLab project Owners and Maintainers can install CodeRabbit on the selected projects without top-level group Owner access.
- Group installation: Installing CodeRabbit for an entire GitLab group requires GitLab group Owner access, and the installation covers repositories in that group and its subgroups, including repositories added later. Group-wide install and uninstall actions are managed from the top-level group; when browsing a subgroup, the group-wide action is not shown, but you can still select individual repositories or, if you manage the top-level group, choose View top-level group to manage the group installation.
Access repository settings
Select repositories
Install CodeRabbit

Selectable and unavailable GitLab projects on the CodeRabbit Repositories page
https://coderabbit.ai/gitlabHandler will now be installed for the projects selected.

Automatic installation for new group repositories
After a GitLab group Owner completes the Install Group action, CodeRabbit also covers repositories that are later created in or added to the installed group and its subgroups. You do not need to select and install each new repository individually. This behavior relies on the group-level webhook and token installation. Use a Group Access Token where applicable, and complete the group installation as a GitLab group Owner.Manual webhook installation
If you install repositories from the Repositories page, CodeRabbit configures the webhook automatically. Use this flow only when you need to install the webhook manually or rotate the shared webhook secret. The Webhook Secret page is available in CodeRabbit for supported Git providers, including GitLab.com and self-managed GitLab. For an instance-wide shared secret on self-managed GitLab, use Workspace Git credentials.Open Webhook Secret settings
Copy the webhook URL
Save or change the webhook secret
Configure the GitLab webhook
- Merge request events
- Comments
- Issues events
- SSL verification enabled
Troubleshooting
Token requires Developer access
The error “The token requires Developer access to the selected GitLab group” refers to the service account or bot identity behind the token. Check its access to the top-level group selected in CodeRabbit, even if the person installing CodeRabbit is a group Owner. For example, if you selectexample-org in CodeRabbit and create a Group Access Token in example-org/backend, the token can have Owner access to backend and still fail validation for example-org. Increasing its role within backend does not grant access to the parent group.
If access across the parent group is acceptable, use a Group Access Token created in example-org with Developer access or higher and api, or a personal access token for a service account with the required access to example-org and personal token scopes. If you need subgroup-only or project-only access, contact support before expanding permissions; choosing a subgroup later in repository selection does not change the group used to validate the token.
If the token identity already has Developer access or higher in the selected top-level group, confirm the token is active and has the required scopes, then contact support with the selected group URL and error message. Do not share the token value.