Facing itermittent issue with copilot review feature in azure devops

Question

Facing itermittent issue with copilot review feature in azure devops

Abhiram PADYANA 20

Copilot Functionality has been activated for all repos in the our Azure Devops organization .It seems working well for all repos except for one of the repos

error :

User's image

Sometimes (rare case when you click 20x in a row) we can get the Copilot Code Review:

This issue seems to happen only for one of the git repository.

tried what is suggested on the error message:

I tried to deactivate and re-activate at repo level:

I tried also at org level

I tried also to "Disable all" and then "Enable all" back.

None of those workaround worked.

Can you please advise on the way to proceed to successfully activate Copilot Code Review on git repository ?

Tejaswini Billakurthi 250 Reputation points Microsoft External Staff Moderator

2026-09-08T16:03:35.74+00:00
Hello @Abhiram PADYANA ,

Thank you for reaching out to Microsoft Q & A!

Since it's one repo out of many and toggling enablement at repo and org level changed nothing, the enablement path is unlikely to be the cause — the per-repo requirements are the better first check.

Copilot code review only runs when the PR is Active, shows Merge Succeeded (no conflicts), and sits within 10 GB repository size, 100 or fewer changed files, and 100 or fewer changes. One repo crossing a single bound would explain why only that one behaves differently. These are preview limits and can change.

If those all check out, the documented way to see the real failure reason is Organization settings > Agent pools → the pool used for Copilot code reviews (default Azure Pipelines) → open the failed job and read the raw JSON log.

Two things that would help narrow this down:

The exact error text on the PR — the screenshots didn't come through in the post.

Whether a minimal PR in that same repo (one small text file, no conflicts) reviews successfully. If it does, the cause is repo/PR size rather than enablement.

Secondary check if reviews are being requested in bursts: the limits of 1 concurrent review per PR, 2 per user, and 5 per organization can stop a request from starting.

Docs:

Requirements and limits: [https://learn.microsoft.com/azure/devops/repos/git/copilot-code-reviews?view=azure-devops](https://learn.microsoft.com/en-us/azure/devops/repos/git/copilot-code-reviews?view=azure-devops) Troubleshoot failed code reviews: [https://learn.microsoft.com/azure/devops/repos/git/copilot-code-reviews-faq?view=azure-devops](https://learn.microsoft.com/en-us/azure/devops/repos/git/copilot-code-reviews-faq?view=azure-devops)

Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.

1 answer

Your answer

Tejaswini Billakurthi 250 Reputation points Microsoft External Staff Moderator

2026-09-08T16:03:35.74+00:00

Hello @Abhiram PADYANA ,

Thank you for reaching out to Microsoft Q & A!

Since it's one repo out of many and toggling enablement at repo and org level changed nothing, the enablement path is unlikely to be the cause — the per-repo requirements are the better first check.

Copilot code review only runs when the PR is Active, shows Merge Succeeded (no conflicts), and sits within 10 GB repository size, 100 or fewer changed files, and 100 or fewer changes. One repo crossing a single bound would explain why only that one behaves differently. These are preview limits and can change.

If those all check out, the documented way to see the real failure reason is Organization settings > Agent pools → the pool used for Copilot code reviews (default Azure Pipelines) → open the failed job and read the raw JSON log.

Two things that would help narrow this down:

The exact error text on the PR — the screenshots didn't come through in the post.

Whether a minimal PR in that same repo (one small text file, no conflicts) reviews successfully. If it does, the cause is repo/PR size rather than enablement.

Secondary check if reviews are being requested in bursts: the limits of 1 concurrent review per PR, 2 per user, and 5 per organization can stop a request from starting.

Docs:

Requirements and limits: [https://learn.microsoft.com/azure/devops/repos/git/copilot-code-reviews?view=azure-devops](https://learn.microsoft.com/en-us/azure/devops/repos/git/copilot-code-reviews?view=azure-devops) Troubleshoot failed code reviews: [https://learn.microsoft.com/azure/devops/repos/git/copilot-code-reviews-faq?view=azure-devops](https://learn.microsoft.com/en-us/azure/devops/repos/git/copilot-code-reviews-faq?view=azure-devops)

Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.

Answer 1

Hassan Mohammad Hassan Sharahili 80

When Copilot Code Review works across all repositories except one—and intermittently works only after repeatedly clicking—the problem is typically tied to that specific repository's characteristics, Azure DevOps Code Search indexing, or service account permissions rather than the global toggle.

Inspect and resolve the issue through the following troubleshooting steps:

1.Check Repository Size and PR Limits:Preview limits.Copilot Code Review in Azure Repos enforces strict size and file limits:

Total repository size must not exceed 10 GB.

Pull requests must change 100 files or fewer and have no active merge conflicts.

Repositories with large binary assets, deep submodule nesting, or large files (e.g., node_modules or unignored build artifacts committed to the tree) often cause background git-traversal timeouts.

Verification: Test with a minimal PR in this repository (modifying a single Markdown or text file). If that PR reviews immediately, the failure is linked to diff/tree size constraints.

2.Verify Searchable Branches and Code Search Indexing:Azure Repos Code Search.Azure DevOps Copilot Code Review relies on Azure DevOps Code Search to build context. If the target branch of the PR is not indexed, Copilot falls back to a deep filesystem/git walk that frequently hangs or gets canceled by the internal agent:

Go to Project Settings > Repositories > select the affected repository.

Check the Searchable branches tab.

Ensure the PR target branch (e.g., main, develop, or release branch) is listed as an indexed searchable branch.

Verification: Perform a manual search query across this repo using the top search bar. If search results return immediately for the target branch, indexing is healthy.

3.Inspect Backend Agent Pool Logs:Failure diagnostics.Copilot code reviews execute as background jobs on your hosted pipeline agent pool:

Go to Organization Settings > Agent Pools.

Open the pool designated for Copilot compute (by default, Azure Pipelines).

Locate the failing code review job and inspect the raw JSON logs to see the exact terminating exception (e.g., checkout lock, token budget exceeded, or directory traversal timeout).

Verification: The log entries will display whether the job hit an agent cancellation (exit code 128 / timeout) or an API authorization error.

4.Validate Project-Level Build Service Permissions:Permissions check.The backend review agent requires read permissions to the Git repository to checkout and post annotations:

Go to Project Settings > Repositories > select the affected repository.

Under the Security tab, locate Project Collection Build Service ([OrgName]) and [ProjectName] Build Service.

Confirm both accounts have Read and Contribute to pull requests set to Allow (not inherited Deny).

Verification: Ensure neither service account is set to explicit Deny anywhere in the inheritance tree.

Abhiram PADYANA 20 Reputation points

2026-09-09T03:03:19.65+00:00
3.Inspect Backend Agent Pool Logs:Failure diagnostics.Copilot code reviews execute as background jobs on your hosted pipeline agent pool: Go to Organization Settings > Agent Pools. Open the pool designated for Copilot compute (by default, Azure Pipelines). Locate the failing code review job and inspect the raw JSON logs to see the exact terminating exception (e.g., checkout lock, token budget exceeded, or directory traversal timeout). Verification: The log entries will display whether the job hit an agent cancellation (exit code 128 / timeout) or an API authorization error.

with this were able to get the error info .

Error: all files are too large to fit within the prompt budget",

Looks like there were some .png files in the PR , which could have caused the issue. You can re-check from your end if this is actually an issue that needs to be handled. Anyways thanks for the response.
Tejaswini Billakurthi 250 Reputation points Microsoft External Staff Moderator

2026-09-10T07:08:54.1266667+00:00

Hi @Abhiram PADYANA ,

Good catch getting to the actual error through the job logs - "all files are too large to fit within the prompt budget" is a different constraint from the documented file and change-count limits, so a PR can meet those limits and still hit this one.

The documentation notes that token consumption depends on the size of the repository, the size of the change, and the complexity of the code being reviewed, and that higher review effort levels analyze more context and consume more tokens.

So lowering the review effort level for that PR, or splitting the changes so large binaries are submitted separately, are worth trying: I haven't found public documentation confirming whether binary files such as .png are excluded from the prompt budget, so I can't verify that hypothesis from the docs.

If you'd like the product team to review this behavior, Azure DevOps Developer Community is the appropriate feedback channel. Including the exact error message and PR characteristics would help them evaluate whether the current prompt-budget handling can be improved. — posting the exact error message and the PR characteristics there would give them what they need to evaluate whether the current prompt-budget handling can be improved: https://developercommunity.visualstudio.com/AzureDevOps‌
Abhiram PADYANA 20 Reputation points

2026-09-10T12:02:41.55+00:00

Hello Tejaswini Billakurthi ,
We are continuing to face the same issue ,

Whether a minimal PR in that same repo (one small text file, no conflicts) reviews successfully. If it does, the cause is repo/PR size rather than enablement.

I have created a small dummy PR for testing review on small changes , still facing the same error.

I treid to explore these settings :

Project Setting > repositories > security >

Project setting > repositories > <my-repo-name> > security

Repos > branches > branch policies > security >

at all these places the account "Github Copilot <Org-Name>" had : Contribute , Contribute to pull requests , Create branch , Read Permission .

Automatic Copilot code review skipped: The Copilot code review identity does not have sufficient permissions on this repository. Try disabling and re-enabling Copilot code review in the repository settings.

the other inital checks suggested by other user has also been done :

1.Check Repository Size and PR Limits:Preview limits.Copilot Code Review in Azure Repos enforces strict size and file limits: Total repository size must not exceed 10 GB. Pull requests must change 100 files or fewer and have no active merge conflicts. Repositories with large binary assets, deep submodule nesting, or large files (e.g., node_modules or unignored build artifacts committed to the tree) often cause background git-traversal timeouts. Verification: Test with a minimal PR in this repository (modifying a single Markdown or text file). If that PR reviews immediately, the failure is linked to diff/tree size constraints.

The repo size as well as the health check was fine .

2.Verify Searchable Branches and Code Search Indexing:Azure Repos Code Search.Azure DevOps Copilot Code Review relies on Azure DevOps Code Search to build context. If the target branch of the PR is not indexed, Copilot falls back to a deep filesystem/git walk that frequently hangs or gets canceled by the internal agent: Go to Project Settings > Repositories > select the affected repository. Check the Searchable branches tab. Ensure the PR target branch (e.g., main, develop, or release branch) is listed as an indexed searchable branch. Verification: Perform a manual search query across this repo using the top search bar. If search results return immediately for the target branch, indexing is healthy.

was able to properly fetch both the source / target branch as well. the indexing also looked fine.

There were no agent jobs triggered . It didn't trigger any job failed before that I guess.

Thank you for you response.