Yes: open threads block the merge in Azure Repos if the target branch has the "Check for comment resolution" policy enabled. Without this rule, open discussions remain visible but do not automatically prevent the pull request from being completed.
A thread is the discussion relating to a specific place in the code or to the pull request as a whole. For teams using Azure DevOps Services, what matters most is that this block applies per branch and is one of the Branch Policies in Azure DevOps, not part of builds, reviewer votes or merge types.
This article covers three points:
- when open threads really do block,
- what counts as resolved in Azure Repos,
- and which team rules help in day-to-day work.
The basis for this is the Microsoft Learn pages "Branch policies overview", "Branch policies" and "Securely use Git pull requests and branch policies to protect your important branches", each consulted on 01/11/2026.
What the policy actually checks
In Azure Repos, "Check for comment resolution" is a separate branch policy. Like the other policies, it is not enabled automatically, but is switched off by default. That follows from the Microsoft Learn pages "Branch policies overview" and "Branch policies", consulted on 01/11/2026.
The distinction matters: this policy does not assess whether the code is good, whether the tests are sufficient, or whether enough people have approved it. It checks a narrower point: whether comment threads have been marked as resolved before the pull request is completed. A pull request is the proposal to bring changes from one branch into another.
In practice, this means that as soon as this policy applies to the target branch, a single relevant thread that is still open is enough to stop the pull request from being completed. Green builds or existing approvals do not change that by themselves.
Other rules remain separate alongside it. According to Microsoft Learn, "Branch policies overview", consulted on 01/11/2026, these include separate policies such as:
- minimum number of reviewers
- linked work items
- build validation
- status checks
- merge types
- automatically included reviewers
This is especially useful on important branches, because open review points cannot simply be overlooked just because formal approvals are already in place. In "Securely use Git pull requests and branch policies to protect your important branches", consulted on 01/11/2026, Microsoft lists for main, as part of a security baseline, at least two reviewers, automatically included reviewers for sensitive paths, linked work items, build validation and comment resolution.
Such policies can be configured in Azure DevOps via the user interface; in "Branch policies", consulted on 01/11/2026, Microsoft also mentions "az repos policy" and the REST API. If you want to consider permissions around completing, pushing and bypassing rules separately, the article on permissions in Azure Repos will help.
Mandatory or optional: when open threads really block
What matters is the target branch. Open threads block the merge only if the "Check for comment resolution" policy is enabled there. If the policy is missing, open discussions remain visible in the pull request, but are initially just a review note rather than an automatic merge block.
This is deliberately designed per branch in Azure Repos. Teams can set stricter rules on main or a release branch and use less strict requirements on short-lived feature branches if that suits the way they work. Branch policies are therefore not a global switch for the whole repository, but rules for specific target branches.
It is also important to keep the pull request mechanisms separate:
- Reviewer votes are one separate axis of rules.
- Status checks are external status signals from connected checks.
- Thread resolution is separate from both.
That leads to a common but mistaken assumption: a successful build does not close an open thread. Likewise, reaching the minimum number of reviewer approvals does not replace comment resolution. Each of these rules must be satisfied in its own right if it is active for the target branch.
There is also the question of permissions. Who is allowed to bypass policies when completing or pushing is controlled separately through permissions. In "Securely use Git pull requests and branch policies to protect your important branches", consulted on 01/11/2026, Microsoft recommends limiting these permissions to a small admin group. In day-to-day work, that creates clarity: anyone wanting to complete a pull request can see more quickly whether there are still genuine discussion points open or whether only formal approvals are missing.
How resolved and open threads work in practice
In Azure Repos, a resolved thread mainly means that the discussion has ended. That does not automatically mean the point has been resolved correctly from a technical or business perspective. The status describes the state of the conversation, not the quality of the change.
For reviews, the reasoning is therefore more important than the click on "Resolved". A thread is usually concluded properly when the history shows what was decided:
- code was changed,
- a point was dismissed after review,
- or a follow-up question was answered in a way that can be understood.
This becomes particularly relevant after new commits in the same pull request. An iteration is a new version of the pull request after a further push. In that situation, a discussion point that has already been closed can effectively feel open again, even though its thread formally remains resolved. So when there is a new iteration, do not just check open threads; also briefly check whether earlier decisions still fit the current state.
Reviewer rules run separately from that. In "Branch policies", consulted on 01/11/2026, Microsoft describes options such as "Require at least one approval on the last iteration", "Reset all approval votes" and "Reset all code reviewer votes". These settings affect votes, not the state of a thread.
If automated reviews are also involved, the same distinction is worth making. According to Microsoft Learn, "Review pull requests" and "Copilot code reviews", consulted on 01/11/2026, Copilot Code Review always leaves a Comment Review. Whether that becomes an obstacle to merging depends on the comment resolution policy.
If there are conflicts, you should first resolve the technical merge. For AI-supported workflows, data path, identities and guardrails should also be checked separately from the review status.
Team habits that make the policy work in everyday practice
The policy only becomes useful once your team interprets a thread's status in the same way. So define briefly who sets a point to "Resolved" and in which cases that should happen only after a response from the person who made the comment. That helps you avoid discussions about the status instead of the substance.
A small working rule for comments is practical:
- a clear observation,
- a specific location,
- and the expected clarification.
That keeps threads short and makes it easier later to see whether something is genuinely still open or whether there is only a loose remark hanging in the air.
A fixed final check immediately before completing the pull request is just as helpful: first open threads, then votes, then build and status signals. The sequence is simple, but it prevents a green build from carrying more psychological weight than a business or technical question that is still open.
For areas that need more coordination, a different team rule often helps: not everyone comments on everything; instead, designated reviewers are responsible for checking certain paths. That fits well with automatically included reviewers for sensitive areas. The question of squash, rebase or merge commit should be treated separately, because it mainly concerns history; you can find the classification in the article on choosing the merge type.
And one more day-to-day detail: do not close threads in a batch at the end just "for neatness' sake". If a point has been clarified, mark it then. That keeps the review history readable and reduces misunderstandings in longer pull requests.
Frequently asked questions
Can a pull request be completed despite open threads?
Yes, but only if the target branch does not have the "Check for comment resolution" policy, or if authorised people are allowed to bypass policies. For important branches, Microsoft recommends limiting the permissions "Bypass policies when completing pull requests" and "Bypass policies when pushing" to a small admin group; this is based on Microsoft's security baseline for important branches, consulted on 01/11/2026.
For day-to-day review work, the question is therefore not only technical, but also organisational:
- Does the policy apply on the target branch?
- Who is allowed to trigger exceptions?
- Is it clear within the team when that is acceptable at all?
Do resolved threads automatically count as open again after further commits?
No. A new push does not automatically reopen a thread that has already been marked as "Resolved". That is precisely why, after a new iteration, it is worth taking a brief look at earlier decisions. On the page about branch policies and iterations, consulted on 01/11/2026, Microsoft describes special rules only for reviewer votes, such as "Require at least one approval on the last iteration" or resetting votes.
In practice, for threads this means: the status remains, even if the context has changed.
Is Copilot Code Review a substitute here for required reviewers?
No. According to Microsoft Learn, Copilot Code Review always leaves a Comment Review and therefore does not fulfil a required reviewer policy. This is stated on the page about reviewing pull requests, consulted on 01/11/2026.
The operating status also matters: according to the documentation on Copilot code reviews, consulted on 01/11/2026, Copilot Code Review was in Public Preview. Preview features have no SLA and may change. If you want to track such changes properly internally, a public change log helps.
What should you assess soberly in claims about AI-supported reviews or coding agents?
Three points are especially useful:
- stage of development
- measured evidence from real runs
- data and operating model
Without real runs, customer operation or published measurements, you should not assume any effect. For a well-founded assessment, results belong on a page with measurable evidence, not in assumptions. And when it is a service still in development, the sign-up mode and status should be clearly separated from the functional promise; for that, a page on package logic and sign-up is the right place.
Next step
Carry out a short practical check for your target branch.
- Which open threads keep recurring in recent pull requests?
- Are these genuinely unresolved points, or rather loose remarks without a clear expectation?
- Who visibly decides between "Resolved" and "Active" when there is doubt?
That lets you review not only the setting in Azure Repos, but your team's actual review discipline.
It is also helpful to look together at special cases: architecture notes, security issues, later follow-up work and consciously accepted deviations should be clearly recognisable in the thread as decisions. Otherwise, there is unnecessary room for interpretation before the merge.
If you are evaluating the use of AI-supported workflows in Azure DevOps Services, keep a clear distinction between review comments, binding policies and automated status signals. Polier by ballmüller solutions is in development and not yet available; it is intended to turn an Azure Boards work item into a pull request in Azure Repos, while the customer's branch policies apply and the agent itself never merges.