The credential your review bot authenticates with is the part of the setup that breaks first. Commenting on a merge request is the same job on GitLab, Azure DevOps and Bitbucket, but it is done by four different kinds of token, and two of those token types are being retired during 2026. Teams usually notice when the comments stop appearing while the pipeline stays green.
The dates set the scope for this page. Global personal access tokens in Azure DevOps Services stop working on 1 December 2026, and Microsoft states that Azure DevOps Server is not affected. On Bitbucket Cloud, app passwords could no longer be created from 9 September 2025 and all remaining ones are disabled on 9 June 2026. GitLab splits project and group access tokens by offering, which decides whether the credential a bot needs exists at all on your instance.
What the reviewer credential decides
Four properties of a token shape how a review bot behaves, and none of them depend on the model behind it.
The identity comes first. An OAuth app posts as a dedicated bot account, so the merge request shows something clearly not human. A personal token posts as whoever owns it, which puts a person’s name on machine comments and removes the distinction between a human review and a bot review from the audit trail. On a codebase with any compliance requirement, that difference usually settles the choice.
Reach comes second. Scopes decide which repositories the token can read, and on Azure DevOps a personal access token cannot grant more permission than its owner has, so a bot running on a senior engineer’s PAT carries that engineer’s access to every project the token was scoped for.
Write ability comes third, and this is where editions diverge. Approving, commenting, applying a suggestion and merging are separate permissions, and not every token type on every edition can do all of them.
Lifetime comes last. GitLab invalidates a rotated token immediately, so rotation is a deploy rather than an edit. Azure DevOps deactivates PATs in Entra-backed organizations after 90 days without sign-in. Bitbucket Cloud tokens cannot be edited after creation, so a rotation means issuing a replacement and updating the integration.
GitLab access tokens are split by offering, and Self-Managed is the generous side
This is the single most useful fact for a team on GitLab Self-Managed, and it is the reverse of what most people assume about self-managed software. Per the project access token documentation, project access tokens require a Premium or Ultimate subscription on GitLab.com, where a trial is limited to one token. On GitLab Self-Managed and GitLab Dedicated they are available with any license, and the group access token documentation states the same for group tokens. A team on a free self-managed instance can hand a reviewer a project-scoped token with a defined role and scope, while a team on GitLab.com without a paid subscription cannot.
Personal access tokens sit at Free, Premium and Ultimate on every offering, and the personal access token documentation gives the lifetime rules: 365 days by default, extendable to 400 days from GitLab 17.6 through a feature flag named buffered_token_expiration_limit, with the instance administrator able to change the maximum. That default matters more than it looks, because a bot whose token was issued a year ago stops working on a date nobody wrote down.
The cleaner identity is a service account. Service accounts do not use a seat, are always marked as external users, cannot sign in through the UI, and authenticate with a personal access token. Premium and Ultimate allow an unlimited number, while Free allows 100 per top-level group on GitLab.com and 100 for the entire instance on Self-Managed. A reviewer running as a service account survives staff changes; a reviewer running as a maintainer’s PAT does not. The setup for a self-managed review that follows your own rules covers the configuration side of that, and the credential is the prerequisite for all of it.
Azure DevOps is narrowing PATs to one organization, and Server is untouched
Microsoft’s personal access token page now opens with the retirement notice rather than the instructions: all existing global PATs stop working on 1 December 2026, and the guidance is to migrate to organization-scoped PATs or Microsoft Entra authentication. The same page tells you to avoid PATs where a better option exists and to prefer Entra tokens, managed identities or service principals for applications and automation, falling back to an organization-scoped PAT with the minimum scopes and shortest practical lifetime when a tool does not support Entra.
For a reviewer bot that distinction is concrete. An organization-scoped PAT can only reach one organization, which is the intended outcome of the change, and a service principal or managed identity removes the human owner entirely. The global token was convenient because it reached every organization the user could see, and that is exactly the property being removed.
PAT usage itself has not changed. Azure DevOps accepts one through an HTTP Basic header, base64-encoding the string :{PAT} with the username left empty, and the token expires on the date set at creation, with a notification sent before it does. On an Entra-backed organization, signing in with a new PAT within 90 days is required or the token becomes inactive, which is a policy interaction worth knowing before a long-lived CI credential quietly goes dormant.
Azure DevOps Server is a separate product line and the retirement notice does not apply to it. Server PATs are scoped to a collection rather than an organization, and Microsoft states that no changes are being made to global PATs there. A team on Server 2022 or 2020 that reads the announcement and starts a migration project is solving a problem it does not have. The edition differences between Azure DevOps Services and Server for code review tooling are wider than the credential, and the token change is one of the few places where Server comes out ahead.
Bitbucket Cloud app passwords are gone, and Data Center tokens cannot merge
Atlassian replaced app passwords with API tokens, and the API token page describes the shape: user-based, scoped at creation, optionally scoped to a single workspace, intended for a single purpose, and impossible to view or edit afterwards. Two limitations are relevant to a review bot. API tokens cannot be used to log in to bitbucket.org, and they cannot manage workspace actions.
The other credential family on Cloud is access tokens, which are tied to a repository, project or workspace rather than a user. That is a better fit for a bot because there is no human owner to lose access, with two catches. Workspace and project access tokens require the Premium plan, and each workspace, project and repository has a hard limit of 25 tokens that cannot be increased. A repository access token is available without Premium, which makes it the practical choice for a per-repository reviewer.
Bitbucket Data Center keeps its own HTTP access tokens, and the Data Center edition has a credential advantage Cloud does not. Project and repository tokens require a Data Center license, and once you have one you can issue a token that belongs to a project rather than to a person, which is the cleanest bot identity on any of the three forges. Two documented limits follow from that. Project and repository tokens work with Bearer authentication only and must not be paired with a username in Basic authentication, which breaks the copy-paste git clone patterns people reuse from Cloud. A token also cannot merge a pull request, because a merge creates a commit and only a user with a valid email address can create one. Since Bitbucket 8.8, project admins can additionally restrict repository admins from managing repository-level tokens, and the restriction does not delete tokens those admins already created.
The credential matrix for a review bot
| Forge and edition | Credential a bot can use | Authenticates as | Expiry | Limit worth knowing |
|---|---|---|---|---|
| GitLab Self-Managed | Project or group access token with any license, or a service account PAT | A bot user or service account | 365 days by default, 400 with a feature flag in 17.6+ | Free tier allows 100 service accounts for the whole instance |
| GitLab.com | Project or group access token requires Premium or Ultimate | A bot user | Same default | A trial is limited to one project access token |
| Azure DevOps Services | Organization-scoped PAT, Entra token, service principal or managed identity | The PAT owner, or an app registration | Per organization policy; Entra-backed PATs go inactive after 90 days without sign-in | Global PATs stop working 1 December 2026 |
| Azure DevOps Server | PAT scoped to a collection | The PAT owner | Per collection policy | No change to global PATs announced for Server |
| Bitbucket Cloud | API token with scopes, or a repository access token | The API token’s user, or the repository | Set at creation and not editable afterwards | Workspace and project access tokens require Premium; 25 tokens per workspace, project and repository |
| Bitbucket Data Center | User HTTP access token, or a project or repository HTTP access token | The user, or the project or repository | Optional, fixed at creation | Project and repository tokens are Bearer only, and a token cannot merge a pull request |
What this changes when you pick a reviewer
The credential path is one of the few ways to compare review tools on something other than model quality, because it is documented per forge rather than described in marketing terms.
PR-Agent runs as a CLI or a webhook, so the token comes from your own environment and never from the vendor. Its platform matrix lists the CLI and app/webhook usage across GitHub, GitLab, Bitbucket, Azure DevOps and Gitea, which is why it works on self-managed editions where a hosted app cannot be installed. The trade-off is that you own the token lifecycle, including the rotation and the expiry, and the matrix is honest about where output degrades: Generate Labels and Update CHANGELOG run on Bitbucket and Azure DevOps but post as a pull request comment because those providers cannot set labels or accept a pushed file.
Kodus documents both credential paths and the split follows the forge. Its quickstart offers OAuth or a token for GitHub and GitLab, where OAuth produces a dedicated bot identity in pull requests and a clearer audit trail, and token-only setup for Bitbucket and Azure DevOps, where comments appear under the account that owns the token. Its Bitbucket setup page points at an Atlassian API token with a listed scope set rather than an app password, which is the migration the June 2026 deadline requires anyway. Self-hosting is available, and the license is AGPL-3.0 apart from files and directories marked as enterprise edition, with the Community tier capping Kody Rules at 10 and plugins at 3 while leaving reviews unlimited. For a self-managed instance, that combination of OAuth-or-token plus your own model keys is the part that decides whether the reviewer can run behind the firewall at all, which is the same constraint that shapes the self-hosted editions of CodeRabbit and Qodo.
Write ability separates the options further. GitLab merge request suggestion blocks are applied through the suggestions API and are available on Free tier, so a bot on GitLab can post a fix a human accepts in one click. Bitbucket Data Center exposes an apply-suggestion endpoint, Bitbucket Cloud does not, and Azure Repos has no apply operation in the REST API, so a bot there posts the replacement as comment text and a human applies it. A reviewer that cannot apply its own suggestion is still useful, but it adds a manual step that a GitLab team never sees, and that difference lives in the forge, not in the tool.
What to check before you roll it out
Confirm the identity first. If the vendor offers OAuth on your forge, use it, because it gives you a bot account that survives staff turnover and keeps machine comments distinguishable from human ones. If you are on Bitbucket or Azure DevOps and the only documented path is a token, plan for that token to belong to a service account rather than a person.
Then check the expiry against your calendar. A GitLab token issued with the 365-day default, a Bitbucket Cloud token whose expiry was set at creation and cannot be edited, and an Azure DevOps PAT in an Entra-backed organization all stop working on dates that have nothing to do with your release schedule. Rotating on purpose is a maintenance task; discovering the rotation because reviews went quiet is an incident.
Finally, check the scope against the job. A review bot needs to read code and write comments, and on Azure DevOps it cannot exceed its owner’s permissions anyway. Anything beyond that, including merge rights, is access you are granting for convenience rather than necessity.
Two of the four credential families covered here change during 2026, and both changes remove a credential that was convenient and broad. If you have a review bot running on a global Azure DevOps PAT or a Bitbucket Cloud app password, the migration is not optional, and it is cheaper to do it on your own schedule than on the vendor’s.