Copilot code review on Azure Repos waits on three admins before its first comment

The order comes from Microsoft's prerequisites table, as laid out in a dev.to post that went to the primary docs for Azure Repos reviewers. A Project Collection Administrator turns Copilot code review on for the organization, then a Project Administrator for the project, then a repository owner or administrator for each repo ^[1]. The table spreads setup across four roles before Copilot comments on a single pull request ^[3]. On GitHub, the post notes, you install an app and it reviews ^[4].

The post's point is that those admin roles usually belong to different people, and all of them have to agree in sequence before the reviewer exists ^[4]. It describes a classic split: team leads administer repos, while a platform team holds organization settings. In that setup, the author wrote, enabling the reviewer is "a ticket you file across org boundaries just to try a preview feature" ^[5]. Four roles is a lot of governance for a feature whose documentation says it "might change or be removed without notice" ^[6]. The same docs say "This feature is in limited preview" and that preview features "have no Service Level Agreement (SLA) and limited support" ^[6]. Only Git repositories qualify. TFVC is not supported ^[7].

Billing also sits outside the pull request. Usage is billed through Azure Cost Management against an Azure subscription linked to the organization ^[8]. The docs say higher "review effort" levels consume more tokens and can cost more ^[9]. Effort has a project-level default, and a project admin can allow or lock per-repo overrides ^[10]. The depth of review on a repository is therefore a spend setting, held by whoever has the project admin role ^[10].

CodeRabbit, the other reviewer the post examines, does support Azure Repos. Its docs ask for repository and work-item access plus permission to manage service hooks ^[12]. There is no native OAuth app for the Azure DevOps integration. The connection runs on a Personal Access Token tied to an Azure DevOps user ^[13]. A practitioner write-up quoted in the post describes what happens to that token: "When they do, CodeRabbit silently stops reviewing PRs. If the PAT belongs to an engineer who leaves the company, you lose code review across the org with no warning." ^[14]

The recommended fix is a dedicated service account. It gets Reader at organization level and Contributor on the reviewed repos. Its scopes are Code and Pull Request Threads read-write, Project and Team read, and User Profile read, and its rotation date goes on a shared calendar ^[15]. The post contrasts this with GitHub, where the OAuth app handles credential rotation transparently ^[16].

Branch policy raises the stakes. If CodeRabbit is a required status check and the token lapses, merges can end up gated on a check that stopped reporting, the post argues ^[17]. The status name can also drift between CodeRabbit versions, so a required check can go stale after an update ^[18].

The two tools use different machinery with the same property: whether review runs depends on configuration held somewhere other than the diff ^[19]. I think the post's strongest point is about evidence. A reviewer that silently stopped three weeks ago produces the same output as one that ran and found nothing, which is a clean pull request ^[20]. Its author wrote that the better first question is "how do I know it's still reviewing" ^[21]. The post does not assess the quality of either tool's reviews. On Copilot, it says, "None of this is a knock on the model." ^[11]