Branch control check became case-sensitive: refs/heads/RC/* stopped matching refs/heads/rc/* branches (Nov 2026)

Keep the allowed pattern as refs/heads/rc/*; the observed evaluations show that Branch control now distinguishes it from refs/heads/RC/*, while the available Microsoft documentation does not establish whether that November change was intentional or a regression.

Recommended action

1. In Pipelines → Environments → your environment → Approvals and checks → Branch control, retain the exact-case pattern:

      refs/heads/master,refs/heads/env/prod,refs/heads/hotfix/*,refs/heads/rc/*
   

2. Audit other Branch control checks—including checks attached to service connections, repositories, variable groups, secure files, and agent pools—for case mismatches. Branch control evaluates every linked resource and fails the stage if any branch does not match the allowed list. Patterns must use fully qualified names such as refs/heads/rc/*. ^1^
3. Standardize allowed patterns to the repository’s actual ref casing. Azure Repos treats refs differing only by case as separate refs, and Microsoft recommends consistently using lowercase branch and tag names to avoid case conflicts. ^2^

Your workaround is therefore the safest permanent configuration unless Microsoft later confirms and reverts the changed evaluation behavior.

Answers to the three questions

1. Did Branch control matching recently become case-sensitive?

The two logs demonstrate an effective behavior change between 3 November and 6 November 2026 for your organization: the same task version and configuration first accepted and then rejected a case-mismatched ref.

However, the public documentation does not confirm a Branch control rollout changing matching from case-insensitive to case-sensitive. The Sprint 281 Azure Repos notes list Copilot review-comment and auditing changes, but no Branch control matching change. ^3^

The earlier Sprint 248 change is not evidence of this particular change. It concerns the cross-repository policy branch-candidate preview, which was corrected to reflect already-case-sensitive policy matching—not Environment Branch control. ^4^

Because both runs report Branch control task version 167.0.1, the evidence does not indicate an agent task-version update. It is consistent with a service-side behavior change, but the logs alone cannot establish its cause or intended status.

2. If intentional, should it be documented?

Yes. The current Branch control documentation says to provide a comma-separated allowed list, use fully qualified refs, and notes that a nonmatching branch fails the stage, but it does not explicitly state whether matching is case-sensitive. ^1^

A documentation issue should request explicit wording such as:

Branch control branch and wildcard matching is case-sensitive; allowed patterns must match the casing of the fully qualified Git ref.

Include your sanitized before/after logs because they demonstrate the operational impact without relying on assumptions about the rollout.

3. Will it be reverted?

No public source supplied here announces this as a regression or commits to a revert. Only the Azure DevOps product team can classify it and provide a disposition.

Open an Azure DevOps support request or Developer Community report containing:

• Organization and project identifiers through the private support fields.
• Environment name.
• Successful and failed run IDs.
• UTC timestamps and deployment geography, if known.
• The identical Branch control task version (167.0.1).
• The exact allowed pattern and evaluated ref.
• Confirmation that retry reproduced the failure.
• Confirmation that changing only RC to rc resolved it.
• A request to classify the change as intentional or regression and update the release notes/documentation accordingly.

Do not remove and recreate the environment or check: your A/B result already isolates casing, and recreating it would not answer whether the service behavior changed.

References

1. Define approvals and checks
2. Case sensitivity - Azure Repos | Microsoft Learn
3. Azure DevOps Release Notes - Azure Repos Sprint 281 Update
4. Azure Repos - Sprint 248 Update