Cursor for iPad: review cloud-agent PRs without merging blind
Quick answer
Cursor for iPad is now available on all paid plans. The July 29 release adds an inbox, full pull-request reviews, pinned agent chats, split-screen review, screenshot annotation with Apple Pencil, multi-PR session access, and Bitbucket and Azure DevOps support.
That makes the iPad a useful control and review surface, not proof that a change is safe to merge. A reliable mobile workflow is:
- Confirm the task, repository, base branch, and agent authority.
- Require a compact evidence packet: changed files, tests, screenshots or logs, and known gaps.
- Review the diff by risk, not only by file order.
- Use comments and visual annotations to request bounded fixes.
- Merge only after independent checks pass outside the agent conversation.
The key boundary is simple: being able to read a full PR on iPad does not replace reproduction, CI, security review, or production approval.
Who this is for
This guide is for solo developers and small teams that launch Cursor cloud agents away from their desks and want to triage, review, or merge work from an iPad. It is especially useful when several agents are running at once and the new Inbox becomes the place where attention is allocated.
If an agent worked in an unfamiliar repository, start with the untrusted-repository sandbox checklist. If it claims a task is complete, use the Goal evidence verification workflow before treating its own summary as acceptance evidence.
What changed on July 29
Cursor says the iPad app is available on all paid plans. Its larger-screen layout keeps agent chats visible in a sidebar, supports split screen with a review next to a chat, and renders full file diffs. The review surface covers PR comments, checks, approvals, and reviewer changes; you can ask an agent to resolve feedback from the same workflow.
The release also adds an Inbox for work in progress, items needing attention, and PRs under review. Multi-PR sessions expose every PR created by one chat instead of only the latest one. Screenshot comments and Apple Pencil markup can carry visual feedback back to the agent.
These are meaningful coordination improvements. They do not mean code executes on the iPad. Cursor describes its agents as running in separate cloud environments, while the mobile app launches, steers, and reviews that work. Keep the execution boundary visible when deciding what evidence is still missing.
Decide what belongs on iPad
| Action | Mobile decision |
|---|---|
| Triage the Inbox and assign attention | Safe when project and PR identity are clear |
| Read plans, comments, checks, and ordinary diffs | Appropriate for first-pass review |
| Compare screenshots, videos, and logs | Useful evidence, but verify provenance |
| Annotate a visual defect and request a fix | Good mobile feedback loop |
| Approve a low-risk documentation or isolated UI change | Reasonable only after required checks pass |
| Validate migrations, secrets, billing, auth, or infrastructure | Defer to a controlled environment |
| Reproduce hardware-, browser-, or device-specific behavior | Defer until the target environment is available |
| Merge when checks are missing, stale, or unrelated | Stop |
The screen size is not the risk model. A one-line permission change can be more dangerous than a 500-line generated test fixture.
A five-stage mobile review workflow
1. Freeze the task contract
Before reading the diff, record the repository, base branch, PR, intended behavior, excluded scope, and who may merge. If one chat created multiple PRs, inspect each target independently. Do not assume the latest PR contains the complete change.
2. Require an evidence packet
Ask the agent for:
- files changed and why;
- exact test, lint, or build commands and outcomes;
- screenshots, videos, logs, or API responses tied to this revision;
- untested paths and residual risk;
- rollback or revert instructions.
Treat an agent-written summary as an index to evidence, not evidence by itself. The Cursor Router eval gate uses the same principle: model choice and model confidence cannot replace task-specific evaluation.
3. Review by risk lane
Start with authentication, authorization, secrets, payments, data deletion, schema changes, deployment configuration, and dependency updates. Then review business logic, error handling, tests, and presentation changes. Use the full-PR view to follow call sites and test coverage rather than accepting a visually tidy patch.
For generated files, lockfiles, minified assets, or large snapshots, check the generating command and source change. Do not try to establish correctness by scrolling through opaque output on a mobile screen.
4. Run a bounded feedback loop
Write comments against specific lines or annotate the exact visual region. Ask for one correction with one acceptance condition. After the agent updates the PR, confirm the reviewed commit changed and rerun the relevant checks. A resolved comment does not prove the fix landed in the current head.
Cap the loop. Repeated broad rewrites on iPad are a signal to move the task back to desktop investigation, not to keep approving increasingly opaque agent output.
5. Separate review from merge authority
Require branch protection, current CI, required reviewers, and environment-specific acceptance where applicable. High-risk changes should still need desktop reproduction or another human review. If the app shows a Merge button but the evidence packet is incomplete, the correct action is to leave the PR open.
Eight mobile merge gates
| Gate | Passing evidence |
|---|---|
| Identity | Correct repository, base, PR, and current head commit |
| Scope | Diff matches the task and excludes unrelated changes |
| Provenance | Artifacts and logs belong to the reviewed revision |
| Verification | Required tests ran with commands and outcomes recorded |
| Risk | Auth, data, billing, infra, and dependency changes are identified |
| Feedback | Requested fixes are present in the current head |
| Authority | Required checks and reviewers, not device convenience, permit merge |
| Recovery | Revert, rollback, or feature-disable path is known |
Copyable review record
mobile_pr_review:
repository: "owner/repo"
base_branch: "main"
pr: 123
reviewed_head: "commit SHA"
task: "one bounded outcome"
risk_lane: "low | medium | high"
agent_evidence:
commands: ["test command and result"]
artifacts: ["screenshot, video, log, or API response"]
gaps: ["untested path"]
independent_checks: ["required CI", "target-environment check"]
decision: "comment | approve | defer | merge"
merge_authority: "named person or protected rule"
recovery: "revert or rollback path"
This is a review record, not a Cursor configuration format.
Common mistakes
Treating the Inbox as a completion queue. It is an attention queue. “Needs review” and “safe to merge” are different states.
Reviewing the summary instead of the revision. Always bind evidence and comments to the current head commit.
Using screenshots as the only acceptance test. Screenshots can support visual review, but they do not prove accessibility, interactions, data integrity, or backend behavior.
Merging because the full diff fits on iPad. Readability is useful; it is not authorization.
FAQ
Can Cursor for iPad run coding agents without my laptop?
Cursor describes the mobile app as launching and managing cloud agents that run in their own development environments. Remote Control can also steer an existing local agent. Confirm which execution mode the session uses before assuming your laptop is unnecessary.
Is iPad review enough for a small PR?
It can be enough for a low-risk, well-bounded change when the current diff, required checks, evidence, and rollback are all clear. Move to desktop or another reviewer when reproduction or sensitive controls are involved.
Should I merge several PRs created by one agent chat together?
No automatic rule follows from one chat creating them. Review each PR's base, dependencies, head commit, checks, and rollback separately, then merge in an intentional order.
Top comments (0)