Repository navigation
[Bug]: Refused merge tells you to check write access when the branch only needs a review #13065
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- On a GitHub repo you admin, add a ruleset on the default branch that requires 1 approving review.
- Open a PR against it yourself and let the checks pass.
- Press Merge in the PR panel.
Approving the PR yourself changes nothing, because your own approval doesn't satisfy the rule.
Expected behavior
The toast says the branch needs an approving review.
Actual behavior
It says:
The host refused the merge. Check that you have write access, that the checks it requires have passed, and that the branch is not conflicting.
I'm the repo admin, the checks were green, there were no conflicts, and I had approved the PR. Nothing in that message pointed at the cause. I only understood it when I opened the PR on github.com and saw the option to bypass the rules and merge.
The server throws away gh's error output, so the client falls back to the generic hint. Passing that output through wouldn't help much either. When the merge state is BLOCKED, gh only prints "the base branch policy prohibits the merge".
The panel already has what it needs to name the cause. Its summary has reviewDecision, checksState and mergeability. GitHub only sets reviewDecision to review-required when a rule requires a review, so it's safe to say that in the toast.
Proposed fix
I have a small web-only change ready and can open a PR. The failed-merge toast picks its hint from that state, checking in this order: conflicts, required review, changes requested, then failing or pending checks. If none of those apply, it keeps the current generic text. It adds no new requests and doesn't change the contracts.
Something like #8225 would pair well with it (though i think it could be better integrated in the ui). Once the toast says a review is missing, an admin's next question is how to merge anyway, and right now the answer is to leave T3 Code for github, or run a command. I know #8225 was closed, so I'm not asking for it here, just saying maybe it could be reconsidered? The error fix works without it anyway.
Impact
Minor bug or occasional failure
Version or commit
Environment
Linux, GitHub repo with a ruleset on the default branch, gh 2.101.0
Logs or stack traces
$ gh pr view 5 --json mergeable,mergeStateStatus,reviewDecision
{"mergeStateStatus":"BLOCKED","mergeable":"MERGEABLE","reviewDecision":"REVIEW_REQUIRED"}
Workaround
Merge on github.com with the bypass option, or run gh pr merge --admin.
Activity
juliusmarminge commentedon Sep 22, 2026
Triage
Confirmed bug. Reproduced in code paths (no live GitHub ruleset exercise needed).
When
gh pr mergeis refused, stderr is stripped at the VCS boundary and the client only gets tool-noise likeGitHub CLI command failed.That matchesTOOL_NOISEinreadableFailure, so the PR panel always shows the static merge hint about write access / checks / conflicts — even when the panel already knows the branch is mergeable, checks are green, and a review is still required.Where
apps/web/src/components/pullRequest/PullRequestDetailPanel.tsx(ACTION_FAILURE_HINTS.merge+finishAction)apps/web/src/components/pullRequest/pullRequestDetail.logic.ts(readableFailure)packages/contracts/src/vcs.ts(VcsProcessExitError.fromProcessExit) →apps/server/src/sourceControl/GitHubCli.ts(GitHubCliCommandError.detail="GitHub CLI command failed.")State for a better hint is already on the summary/list side (
reviewDecision,checksState,mergeability);PullRequestDetaildoes not carryreviewDecision.Suggested fix
Web-only, as proposed: pick the merge-failure hint from current panel state (conflicts → required review → changes requested → failing/pending checks → keep today’s generic text). No new requests, no contract change required.
Caveat for implementers: T3 enriches GitHub’s
reviewDecisionintoReviewDecisionWithReviews(apps/server/src/pullRequest/gitHubPullRequestJson.ts). A hostREVIEW_REQUIREDcan become display"approved"when latest reviews include an approval (e.g. self-approval that does not satisfy the ruleset). Keying the toast only on summaryreview-requiredmay miss that case — prefer a hint that still covers “mergeable + checks ok + merge refused” / policy-blocked, not only the display glyph.Related
Next step
Please open the small web-only PR you mentioned. Happy to review that scoped change; we are not revisiting admin-merge as part of this issue.
andrew-metaplanet commentedon Oct 7, 2026
Same here, on a repo whose ruleset lets a named admin team bypass the review requirement. The clearer toast would help, but what we actually need is the bypass itself: a "merge with bypass" option in the PR panel for users GitHub already allows to bypass (the equivalent of
gh pr merge --admin, or the "bypass rules" checkbox on github.com). Without it, every self-authored PR means leaving T3 Code to merge. +1 to reconsidering #8225.TonybynMp4 commentedon Oct 7, 2026
Yep would be nice to have the bypass in the UI
t3dotgg commentedon Oct 21, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Thanks for the report. This is fixed in current main: since #19224, GitHub merges go through the GraphQL merge mutation, so GitHub's own refusal reason (for example a ruleset or required review) now reaches the toast instead of the generic write-access hint. Please test on the nightly built from main on 2026-10-21, or on the next stable release. If the problem still occurs there, please open a new issue that links to this one, with your version and steps to reproduce it.