GitHub Auto-Merge Bug: Undocumented Change Disrupts PR Workflows and Developer Performance

GitHub's Auto-Merge Feature Faces Undocumented Behavior Change, Impacting Developer Workflows

A recent, undocumented change to GitHub's auto-merge functionality has caused significant disruption for development teams relying on efficient Pull Request (PR) workflows, particularly those utilizing merge queues and repository rulesets. As of March 25, 2026, users are reporting that auto-merge can no longer be enabled on a PR until all requirements—such as status checks and approvals—are already met. This new behavior contradicts official GitHub documentation and the feature's original intent, directly hindering developer productivity and potentially affecting how teams measure performance of software developers.

The Core Issue: Auto-Merge Defeats Its Purpose

Historically, GitHub's auto-merge allowed developers to enable the feature immediately after opening a PR. The system would then automatically merge the PR once all specified requirements were satisfied. This was a crucial time-saver, preventing developers from having to constantly monitor PRs for completion. The official documentation still reflects this expected behavior, stating: "If you enable auto-merge for a pull request, the pull request will merge automatically when all required reviews are met and all required status checks have passed."

However, users are now encountering an HTTP 422 error when attempting to enable auto-merge on PRs with pending requirements. The error response observed is:

{"error":"Failed enabling auto-merge for pull request"}

This means that if a PR needs an approval or is waiting for CI/CD checks to complete, auto-merge cannot be activated. As one user aptly put it, "This defeats the entire purpose of auto-merge — if all requirements are already met, you can just merge directly."

Technical Context: Rulesets and Merge Queues

The issue appears to be particularly prevalent in repositories configured with GitHub's newer repository rulesets and merge queues. The original reporter detailed a setup using rulesets for their default branch, enforcing a merge queue with a grouping_strategy: ALLGREEN, required status checks, and a single required approval. No classic branch protection rules were in use, and no changes had been made to their configuration prior to the observed behavior change.

This scenario highlights a critical dependency for maintaining high-velocity development. Merge queues are designed to ensure that the main branch remains green by processing PRs sequentially and validating them against the latest target branch. Auto-merge is an integral part of this process, allowing developers to "fire and forget" their PRs, trusting the system to handle the final merge once conditions are met. When this automation breaks, it introduces manual bottlenecks, directly impacting the efficiency and flow that contribute to positive software developer kpis.

Community Impact and Awaiting Resolution

The community discussion quickly gathered other developers experiencing the same problem, echoing the frustration. Reports included issues with gh pr merge --auto failing for GitHub app tokens and the general sentiment that "The merge queue is pretty much useless right now." The bug forces developers to manually track PR status and intervene at the precise moment all checks pass, which is precisely what auto-merge was built to avoid.

Fortunately, GitHub staff have acknowledged the issue. A reply from `willsmythe` confirmed: "Thanks for reporting. A fix is in the queue." While a timeline for the fix is not yet public, the acknowledgment offers relief to affected teams.

Maintaining Developer Performance in Automated Workflows

This incident underscores the delicate balance between robust branch protection and seamless developer experience. Features like auto-merge and merge queues are vital tools for modern software development, enabling teams to maintain high code quality and fast iteration cycles. When these tools malfunction, the ripple effect can be significant, slowing down deployments and requiring more manual oversight, which in turn makes it harder to accurately measure performance of software developers and identify areas for improvement. As the fix rolls out, the community will be watching closely to ensure the return of reliable, efficient PR workflows.