Every coding agent can open a merge request. The question is what happens next. DevBench's answer has been the same from the first commit: a person presses Merge, and nothing else can.
The last place someone reads the diff#
A merge request is the last point at which a change is still a proposal. Before the button it can be read, run, recorded and refused at no cost. After it, the change is on a shared branch and on its way to the people who use the product.
That is why the button is the control a team refuses to give up. Not because agents are bad at code, but because the button is where responsibility changes hands. Whoever presses it is saying: I have seen this, and I want it on the branch. An agent cannot say that. It can only report what it did.
Enforced once, for every caller#
The rule is not a checkbox each screen remembers to honour. It is one permission class on the server, applied to the merge endpoint for every caller: the web app, the desktop app, the phone, an API key, a scheduled run, and the agent inside the box. A box holds no provider token of its own, so it cannot go around DevBench to the provider either.
Protected branches get the same treatment twice. The agent's git refuses a push to any branch in your flow inside the box, and the push relay refuses it again on the server before any objects move. Reaching main happens through a merge request or a release, never a raw push.
What the button has to show#
A button is only a decision if the screen shows why to press it. Every branch gets a live preview. Every run leaves a test note with the log attached. The agent records a video of the deployed application doing what was asked. All of it sits in the task's timeline, next to the button.
We are not finished here. The diff, the pipeline status and the provider's review comments still live in another tab. Closing that gap is next, because a Merge button with the evidence somewhere else is a formality, and a formality gets pressed without reading.
The one exception, and why it is loud#
There is a case where the rule is wrong: a sandbox where the agent owns the whole loop, a workspace whose output nobody ships. Forcing a person to press Merge there is friction with no safety behind it.
So self-merge exists, as a per-workspace setting, off everywhere by default. Only an owner can switch it on, the same bar as granting a box cloud access. It can never be on for an info-only workspace, because nothing is ever merged out of one. And every self-merge is audited and announced to the organization. The human read is skipped, so the organization finds out it happened rather than discovering it later in the git history.
Undoing a merge has no such exception. Reverting something already on a shared branch is a different act, usually taken in a hurry, and it goes through a merge request of its own.
The short version#
Agents open. People merge. The rule is enforced on the server for every caller, the evidence sits next to the button, and the only way around it is a switch an owner turns on, in the open, per workspace.