### Summary `git push -o merge_request.auto_merge` is accepted from a user who lacks merge permission on the protected target branch. The push succeeds, nothing is written to the `remote:` channel about the option for the user, and GitLab records the auto-merge with that user as `merge_user`. The merge request is then unmergeable by anybody: a user who does hold merge permission sees "You are not allowed to merge this merge request. Try again." and is given no Merge button. The merge request stays open indefinitely until the auto-merge is cancelled. The API state is self-contradictory while this persists. `detailed_merge_status` reports `mergeable` and `merge_status` reports `can_be_merged`, yet `merge_error` reads "You are not allowed to merge this merge request". The refusal is therefore recorded server-side; it is simply not surfaced to the pushing user, not surfaced in `detailed_merge_status`, and not distinguishable in the widget from an ordinary permission problem belonging to the viewer. Two separable defects appear to be in play: the automerge push option is accepted from an account that cannot satisfy it, and the resulting refusal is not propagated to either the git channel or `detailed_merge_status`. ### Steps to reproduce 1. Create a project with a README so that `main` exists as the default branch. 2. Confirm `main` is protected with "Allowed to merge" set to Maintainers, so that the Developer role is excluded. Read it back with `GET /api/v4/projects/:id/protected_branches` and check for `"access_level":40` under `merge_access_levels`. 3. Create a user and add it to the project with the Developer role. 4. Create a token for that user with the `write_repository` scope only. 5. Clone the project as that user over HTTPS, authenticating with the token. Create a branch, commit, and run `git push -o merge_request.create -u origin <branch>`. 6. Add a second commit and run `git push -o merge_request.auto_merge`. 7. Open the merge request as a user who does hold merge permission, such as the Owner or a Maintainer. 8. Observe blocked/unmergeable MR Reproduced on a self-managed instance running 19.2.4-ee. ### What is the current _bug_ behavior? The step 6 push succeeds. Its `remote:` output is identical to the step 5 push, repeating the "View merge request" block for the merge request that already exists: ``` remote: remote: View merge request for am-repro-branch: remote: https://example.net/root/am-repro-2026-08-26/-/merge_requests/1 remote: ``` Nothing is printed about `merge_request.auto_merge`. There is no acknowledgement that it was applied, no warning, and no refusal. The merge request widget then shows all three of the following at once, to a user with merge permission: - "You are not allowed to merge this merge request. Try again." - "Set by am-dev-2026-08-26 to be merged automatically when all merge checks pass", with a "Cancel auto-merge" link - "Ready to merge!", listing "Auto-merge enabled" No Merge button is rendered. The only actions offered are Approve, Cancel auto-merge, Assign reviewers, and Close merge request. No merge occurs. The target branch was polled after six minutes and eighteen seconds and was still at its original commit. `GET /api/v4/projects/:id/merge_requests/:iid` immediately after the step 6 push returns `merge_status: "checking"`, `detailed_merge_status: "checking"` and `merge_error: null`. About a minute later the same endpoint returns `merge_status: "can_be_merged"`, `detailed_merge_status: "mergeable"` and `merge_error: "You are not allowed to merge this merge request"`. `merge_user` is the Developer account throughout. ### What is the expected _correct_ behavior? One of the following, in rough order of preference: The push option should be rejected at push time when the pushing user lacks merge permission on the target branch, with an explanatory line on the `remote:` channel naming the branch and the missing permission. Failing that, if the auto-merge is going to be recorded, it should not render the merge request unmergeable for users who do hold merge permission. A Merge button should remain available to them. Independently of which of the above is chosen, `detailed_merge_status` should not report `mergeable` at the same time as `merge_error` reports that the merge was refused. A caller reading `detailed_merge_status` to decide whether a merge request is ready has no way to detect this state. ### Relevant logs and/or screenshots Step 5, `git push -o merge_request.create`: ``` Switched to a new branch 'am-repro-branch' [am-repro-branch 7bb3e76] first commit 1 file changed, 1 insertion(+) create mode 100644 file.txt Password for 'https://am-dev-2026-08-26@example.net': remote: remote: View merge request for am-repro-branch: remote: https://example.net/root/am-repro-2026-08-26/-/merge_requests/1 remote: To https://example.net/root/am-repro-2026-08-26.git * [new branch] am-repro-branch -> am-repro-branch branch 'am-repro-branch' set up to track 'origin/am-repro-branch'. ``` Step 6, `git push -o merge_request.auto_merge`: ``` [am-repro-branch 3362b4a] second commit 1 file changed, 1 insertion(+) Password for 'https://am-dev-2026-08-26@example.net': remote: remote: View merge request for am-repro-branch: remote: https://example.net/root/am-repro-2026-08-26/-/merge_requests/1 remote: To https://example.net/root/am-repro-2026-08-26.git 7bb3e76..3362b4a am-repro-branch -> am-repro-branch ``` Protected branch configuration, `GET /api/v4/projects/58/protected_branches`: ```json [{"id":59,"name":"main","push_access_levels":[{"id":59,"access_level":40,"access_level_description":"Maintainers","deploy_key_id":null,"user_id":null,"group_id":null}],"merge_access_levels":[{"id":59,"access_level":40,"access_level_description":"Maintainers","user_id":null,"group_id":null}],"allow_force_push":false,"unprotect_access_levels":[],"code_owner_approval_required":false,"inherited":false}] ``` Merge request state, `GET /api/v4/projects/58/merge_requests/1`, abridged to the relevant fields: ```json { "iid": 1, "state": "opened", "target_branch": "main", "source_branch": "am-repro-branch", "author": {"id": 143, "username": "am-dev-2026-08-26"}, "merge_user": {"id": 143, "username": "am-dev-2026-08-26"}, "merge_when_pipeline_succeeds": true, "merge_status": "can_be_merged", "detailed_merge_status": "mergeable", "merge_error": "You are not allowed to merge this merge request", "merged_at": null, "merge_commit_sha": null, "has_conflicts": false, "blocking_discussions_resolved": true, "pipeline": null, "head_pipeline": null, "sha": "3362b4a6872b6519ebbc6d94f7dc82549e9feab0" } ``` {width=702 height=600} ^ Visible when viewing as a Maintainer or Owner of the project who should be able to merge the MR. ### Possible fixes Not traced to a line. Two places are worth looking at. The first is the push options handler that consumes `merge_request.auto_merge`, which appears to record the auto-merge without checking whether the pushing user can merge into the target branch. A permission check there, with the failure returned on the `remote:` channel alongside the existing "View merge request" output, would close the silent-failure half of this. The second is whichever code computes `detailed_merge_status`, which returns `mergeable` while `merge_error` holds a permission refusal. Those two should not be able to disagree. ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!--If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`-->