Merging stack consistently fails with message: "auto-merge was automatically disabled / Pull Request is not mergeable"

[bencdelaney]

We're just starting to use stacked PRs, and have run into issues while attempting to merge our first stack from the GitHub UI.

Our stack consists of four small changes, which we have successfully stacked and approved. The topmost PR indicates that the whole stack is ready to merge.

However, when I attempt to merge the stack, I consistently see this experience:

1. All four commits start spinning, as expected.

2. All four commits switch to the purple "merging" state, as expected.

3. This message appears in the PR conversation:

   

4. All four commits revert to their pre-merge state.

I don't see any further information regarding why the merge failed, so am unsure what we should try to resolve the issue.

[sumedha-lab]

CleanShot.2026-07-21.at.15.54.23.mp4

I encountered the same problem.

[steve-gore-snapdocs]

We are running into a similar issue. What are your branch protection setting?

[wolszews]

Also having the same issue

[skarim]

Hey all, thanks for the reports. We've identified a bug where approvals are not being appropriately evaluated when merging a stack of multiple PRs. We're actively investigating and will update when we've released a fix.

In the meantime, you can get around this by merging one PR at a time. I know it's not ideal, but hopefully that will unblock your workflows in the short-term. Appreciate your patience!

[lukemassa]

In the meantime, you can get around this by merging one PR at a time. I know it's not ideal, but hopefully that will unblock your workflows in the short-term. Appreciate your patience!

This workaround unfortunately doesn't work for me. If I merge one-at-a-time, it dismisses the approvals of the next PR on the stack, which means I have to go back to the reviewers and get them to re-review, which somewhat defeats the convenience. It might be something something specific to my setup, shown here in terraform:

  rules {
    required_linear_history = true

    pull_request {
      allowed_merge_methods             = ["merge", "rebase", "squash"]
      dismiss_stale_reviews_on_push     = true
      require_code_owner_review         = true
      require_last_push_approval        = true
      required_approving_review_count   = 1
      required_review_thread_resolution = true
    }
...

I'm not sure if the fact that these approvals are dismissed are expected due to my configuration, whether that's part of this bug, or another bug, just wanted to call out that the "merge all PRs in the stack" aspect of this feature doesn't work for me.

Otherwise I've been a big fan of the feature, very useful!

[d12]

Yeah merging one-at-a-time rebases all of the other PRs and invalidates the reviews unfortunately. We'll just need to wait for the proper fix from GitHub.

[Techassi]

Merging stacked PRs individually (starting at the base) also breaks. Apparently, when GitHub automatically changes the base in a PR futher up the stack (which I assume is a rebase underneath), it doesn't carry over the commit signature. This leads to the PR to be unmergeable in repositories which require signed commits.

It requires locally re-signing the commit(s) and then force pushing to fix it.

[svix-jplatte]

This happens every time when trying to merge multiple PRs at once for me. Merging a single one invalidates reviews on the rest with the automatic rebase. This is.. not ideal.

[d12]

We're hitting this now. Is there a rough timeline for a fix, or any workarounds besides merging everything one at a time?

[michal-samluk]

I am getting the same issue.

[hieu-amari]

Without this being fixed, Stacks are useless.

[ChxGuillaume]

Wouldn't say they are useless, would say they are less convenient ^^
Still makes the life of the reviewer easier and merging the branches one by one is just a question of a button a 2-3 commands

[oddsund]

➕ on useless without being able to merge the whole stack with one button. Compared to manually listing the stack in the PR descriptions, it's currently just chrome which adds CI status.

And it's not just 2-3 extra clicks if you require reviews. Since we require reviews I have to(for each subsequent PR);

• Rebase on main
• Ask and wait for a new review
  Which adds manual toil and time to each PR in the stack.

[ChxGuillaume]

Yes an d the rebase literally takes two commands given by the GH stack plugin which isn't so bad, + asking a re-review is yes annoying but not wasting all your times unless you don't trust your own developers to use the tool properly ^^

Anyway, using it frequently those days, its a bummer this doesn't work but it is FARRRR from making it USELESS ^^

But well, just don't use it :D

[gdavison]

We require reviews as well, but the only time I have to manually rebase is when there are actual merge conflicts. If I don't need to rebase, it keeps the approval status.

The "stealth" merge conflicts are surprising, however.

[rongeorge7]

Getting the same error

[ChxGuillaume]

Can't wait for a fix, would be really cool for the last part of the process to work properly 🙏

[bencdelaney]

Any updates on a fix, @skarim?

Our main pain point at the moment is this issue, that @lukemassa mentioned. Since merging the bottom PR dismisses approvals on later PRs, even if the diff hasn't changed, merging a stack requires manual reapproval from a reviewer between each merge.

Carrying forward those approvals - even if we still have to merge one by one - would make this process much smoother.

[mauricioklein]

Hitting the exact same issue here: stack of three PRs, all checks green, all approvals in, clean lane to main — and the stack merge still gets rejected.

To those saying it's "just less convenient": that's exactly the point. The one-click stack merge is the core value proposition of stacks, not a nice-to-have. Take that away and you're left manually merging PR-by-PR, re-triggering reviews on every rebase — which is precisely the workflow stacks were supposed to kill.

The most basic operation the feature exists for doesn't work. That's not "less convenient", that's broken — and it's embarrassing to GitHub.