On June 29, 2026, the AI code editor Cursor released an iPhone app. According to its official blog, you can pick a project on your phone and launch a coding agent, an AI assistant that reads code, edits files, and runs tests, in an isolated cloud virtual machine, or remotely direct an agent already running on your computer. When the agent finishes, it leaves demos, screenshots, and logs; you can review the diff on your phone, leave follow-up instructions, and merge directly.
Spotting a small bug before dinner and handing it to an agent from your phone really is convenient. But on the same phone, the merge button is right there too. With a small screen and fragmented time, the most likely thing to happen is pressing it after reading only the summary.
Phones are good for starting and tracking work. But “which changes can’t be merged under these conditions” shouldn’t rest on willpower in the moment; write it into the repository’s protection rules in advance and let the system stop you.
A small change isn’t a small impact
A small change doesn’t mean a small impact. A fix that seems to touch only a few lines may affect login permissions, payment flows, database migrations, or deployment settings, and an agent may have widened the scope you gave it along the way. On a phone, what you see is often a summary, not the full diff and test results.
On the other hand, the phone itself isn’t the problem. If tests are complete, the change is small, and it can be rolled back if something goes wrong, approving from a phone isn’t necessarily wrong. What’s wrong is using the phone as a rubber stamp when the evidence isn’t there.
Split what a phone can do into three layers
Watch only: receive notifications when an agent finishes, needs input, or fails tests; check progress, screenshots, and logs. No code changes, no merges.
Hand to an agent first: small, well-scoped tasks that can be undone, such as filling in docs, adding tests, or writing up reproduction steps for a bug. Specify which files may be touched and that deployment isn’t allowed; the agent only opens a pull request and never ships directly.
Needs full review: changes involving permissions, payments, data, migrations, deployment settings, and security-related code. You don’t have to be at a desktop; a tablet or laptop works, as long as you can see the full diff, test results, scope of impact, and how to roll back.
Let repository rules stop the third layer
GitHub’s branch protection rules can require a set number of approving reviews before merging, require specific automated checks to pass, and require approval from the owners of specific files (code owners) when those files change. Once the rules are set, a merge can’t go through unless the conditions are met, no matter which device presses the button.
So for third-layer files, such as permission settings, payment modules, migration scripts, and deployment settings, assign owners and require their review. Then even when a phone notification says “agent finished,” high-risk changes will just wait for review instead of going live because of a hasty tap. For preparing work before handing code to an agent, see Can a Coding Agent Take This Issue? Only If You Can Describe the First Diff.
Rules can’t stop a reviewer who taps approve
Repository rules can stop “conditions not met”; they can’t stop “conditions met, but the reviewer didn’t look carefully.” If reviewers also approve casually from their phones, the rules are empty. In the first week, consider not merging from phones at all until the team confirms that the diffs and evidence agents leave are readable on a phone, then list the low-risk change types that can be approved there.
Also, admins can usually bypass branch protection unless the “do not allow bypassing” setting is enabled. Review and maintenance after merging are most of the cost; see AI’s First Version of a Code Change Is a Price Check; the Real Bill Is Review and Maintenance.
AI handoff card
Our team has started launching and tracking AI coding agents from phones, and we want to decide which changes may be merged from a phone and which should be stopped by repository rules.
The method comes from this article: https://boosterminiclass.com/en/posts/cursor-mobile-agent-approval-boundary/
Its view: phones suit starting and tracking work, but which changes can't be merged on a small screen in fragmented time shouldn't rest on willpower in the moment; write it into the repository's protection rules in advance, such as required reviews, automated checks, and code owner approval.
Review, read-only, only the repository settings and directory structure I've authorized. Don't change any settings or files.
1. Based on directories and file purposes, identify what belongs to "needs full review": permissions, payments, data, migrations, deployment settings, and security-related code, and list the paths;
2. Check the current branch protection rules: whether reviews are required, which automated checks are required, whether code owners are set, and whether admins can bypass; mark anything you can't read as "needs admin confirmation";
3. Recommend rules to add and which paths should have assigned owners;
4. List low-risk change types and conditions that can be approved from a phone, such as docs-only or tests-only changes with all checks passing.
Leave changes to the rules to the repository admins; only make recommendations.
References
- Cursor official blog: Build from anywhere with Cursor for iOS — https://cursor.com/blog/ios-mobile-app (2026-06-29)
- TechCrunch: Cursor now has a mobile app for guiding your coding agent on the go — https://techcrunch.com/2026/06/29/cursor-now-has-a-mobile-app-for-guiding-your-coding-agent-on-the-go/ (2026-06-29)
- GitHub Docs (official): About protected branches — https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches [accessed: 2026-10-11]
