The convenience of "reply YES to ship" only matters if it is also safe. A one-tap merge that could ship something different from what you reviewed would be worse than no button at all.
So the approve-to-merge flow is built like a production deploy gate, not a chat shortcut. Here is what stands between your reply and the merge.
The message you get
When a session parks for review, you get one message — in your CloudAxis inbox and on WhatsApp if linked — with the headline, the pull request link, the live preview, and a short instruction: reply "YES" with a code to ship, or "NO" to decline. The code is unique to that approval and to you, so a stray "yes" in a thread cannot merge anything. Prefer voice? You can also brief agents with voice notes instead of typing for the change that led to the PR.
Pinned to the exact commit you reviewed
When the proposal is created, it freezes the exact commit hash you are approving. The merge is executed against that hash. If the branch moved between the moment you looked and the moment you tapped — a new push, an automated fix — the merge is refused rather than shipping code you never saw. You approve a specific thing, and that specific thing is what merges, or nothing does.
Fail-closed preconditions
Before any merge runs, a set of checks must all pass — and if any is uncertain, the answer is "do not merge":
- You must be the owner of the session, approving through your own authenticated channel.
- The pull request must still be open, and the frozen repo must match the session's repo.
- A proof bundle must be present for the change — live preview, screenshots, and test results attached to the pull request, the same evidence bar we describe in pull requests that ship with live previews and test proof.
- CI must be green for the approved commit (or the repo genuinely has no CI) — a pending or failing check blocks the merge.
- Machine-merging must be allowed by your settings; a "notify only" policy means CloudAxis never merges for you, it just tells you it is ready.
One decision, done once
An approval is a one-shot, exactly-once action. A duplicated reply, a double-tap, or a replayed message cannot merge twice — the system claims the approval atomically before executing. You make the call once; the machinery makes sure it happens once.
The result: the convenience of shipping from your phone, with the guarantees of a careful deploy. You are the human in the loop, and the loop is built so that being human — tapping the wrong thing, replying late — cannot cause a bad merge. Those merge gates were pressure-tested before public beta — read our pre-beta security and billing audit on CloudAxis Coding after we fixed 22 issues. If you are weighing inline editor copilots against phone approvals, our honest Cursor Copilot and Devin comparison for operators spells out where each tool wins.
Frequently asked questions
Can it merge without me?
No. Merging always requires an explicit approval through your authenticated channel, with a typed code for this high-trust action.
What if the branch changed after I approved?
The merge is pinned to the commit you reviewed. If the head moved, GitHub refuses the merge — you can review the new commit and approve again.
How CloudAxis Coding works · Send commands over WhatsApp · Docs: approving from WhatsApp