How to Review AI Agent Diffs from Your Phone

Reviewing AI agent diffs from your phone is not about pretending every code review belongs on a small screen. It is about making the right decision at the right time: continue, stop, ask for a fix, or wait until you are back at a full workstation.

That distinction matters. Claude Code and Codex can keep working while you step away, but useful remote control needs more than a live transcript. You need to know what changed, whether the change matches the task, and whether the next action is safe enough to approve from mobile.

Junction is built around that middle layer. The agent runs on your machine. The browser or phone becomes the control surface for output, approvals, Git state, and diff review. Your phone does not replace engineering judgment. It helps you keep the workflow from stalling while your local agents continue to work.

Mobile review is triage first

A full review asks, "Is this change correct enough to merge?"

Mobile review usually asks a smaller set of questions:

• Did the agent touch the expected files?
• Is the diff obviously too large for the prompt?
• Did it add or remove risky behavior?
• Are tests still running, failing, or passing?
• Is the agent waiting on permission?
• Should I let it continue, redirect it, or stop it?

Those questions are valuable because they catch drift early. You may not want to approve a full branch from a phone, but you can often spot when the agent has gone down the wrong path.

For example, if you ask Codex to add a focused validation test and it starts rewriting pricing state management, you do not need a 27-inch monitor to know something is wrong. Stop the run or redirect it before the diff gets larger.

What belongs on mobile

Mobile review works well for narrow decisions.

Use your phone for:

• checking changed file names,
• reading a short diff,
• confirming the agent stayed in scope,
• approving a read-only or low-risk next step,
• asking the agent to explain a failing test,
• stopping a task that is clearly drifting,
• confirming that a pull request exists and needs later review.

This is especially helpful when the agent is waiting for a quick decision. The worst version of an AI coding workflow is one where a good run sits blocked for an hour because the approval prompt is hidden in a terminal on your desk.

Junction makes that state visible in a browser interface. You can see the run, inspect enough context to decide, and keep the session moving when the decision is small.

What should wait for desktop

Some reviews should not happen from a phone.

Wait for a full workstation when:

• the diff spans many files,
• the change touches authentication, billing, permissions, or data deletion,
• the agent changed package manifests or lockfiles in a non-obvious way,
• migrations are involved,
• tests are missing or inconclusive,
• the pull request needs architectural review,
• or the prompt itself was ambiguous.

The correct mobile decision is often "pause here." That is still useful. A paused run is better than an agent continuing through a risky change because the control surface made approval too easy.

Mobile review should reduce delay, not lower the bar.

A practical mobile diff checklist

Use this checklist before approving the next step from your phone:

1. Scope: does the changed file list match the prompt?
2. Size: is the diff small enough to reason about on mobile?
3. Risk: does it touch shared state, secrets, migrations, billing, auth, or deployment?
4. Evidence: did the agent run or identify the right tests?
5. Direction: does the summary match the actual files changed?
6. Next step: is the requested action reversible and bounded?

If the answer is unclear, do not approve the next action. Ask the agent to summarize, narrow the task, or wait for desktop review.

This approach works for both Claude Code and Codex because the review problem is not provider-specific. Any useful coding agent can produce a change that needs human judgment. The control surface should help you make that judgment with the least necessary context.

Example: a good mobile review moment

Imagine you start a Claude Code task:

Add tests for the setup page copyable command and fix only the component behavior if needed.

Twenty minutes later, you are away from your desk and Junction shows that the run is waiting. The changed files are:

packages/site/src/components/shared/copyable-command.tsx
packages/site/src/components/shared/copyable-command.test.tsx

That is a good sign. The files match the task.

The diff is small. The test file adds cases for copy feedback and disabled clipboard behavior. The component change only adjusts state cleanup after a successful copy. The agent reports that the focused test passed.

This is a reasonable mobile decision. You might approve a final formatting or test command, then leave the full pull request review for later.

Example: a bad mobile review moment

Now imagine you start a Codex task:

Fix the blog validation error in the new post.

The phone shows changes in:

packages/site/scripts/blog-content.mjs
packages/site/src/pages/blog-post.tsx
packages/site/content/blog/posts/new-post.md

That should slow you down. A content validation error usually belongs in the Markdown file. If the agent changed the validator and rendering page, it may be solving the wrong problem.

From mobile, the best action is not to read every line. The best action is to stop or redirect:

Do not change validation logic. Revert your validator and page changes, then fix only the Markdown post.

That is the kind of intervention mobile review is good at. You caught scope drift before it became a larger cleanup problem.

How this connects to approvals

Diff review and approval review are related, but they are not the same.

An approval prompt asks whether the agent may take a specific action. A diff review asks whether the work so far is acceptable. You need both.

For safer approval habits, read How to Approve AI Agent Actions Safely Without Slowing Down. The short version is that approvals should be specific: one action, in one repository, under one set of permissions, for one reason.

Diff review adds a second layer. Even if each individual action was reasonable, the accumulated change still needs to match the task.

What a useful control surface should show

A mobile diff review workflow needs more than a raw terminal.

At minimum, it should show:

• the active agent session,
• recent output,
• changed files,
• diff context,
• permission state,
• test or command results,
• branch or pull request status,
• and a stop or redirect path.

That is why a purpose-built control surface is different from simply remoting into a terminal. A terminal can show everything, but it rarely prioritizes the decisions you need to make from a phone.

Junction's dashboard and review surfaces are designed around those decisions. If you want the broader rubric, read What an AI Coding Agent Dashboard Should Actually Do.

The local-first review advantage

Local-first execution helps review because the changed files come from the environment you already use. The agent is not editing a detached sandbox you need to reconcile later. It is working against the machine that has your normal checkout, tools, Git configuration, and project context.

That does not make every change safe. It does make the review path more direct.

You can inspect the run from a phone, then return to the same branch or worktree on desktop. You can continue the conversation, run tests locally, and review the final pull request without wondering where the real source of truth lives.

A good rule for mobile merge decisions

Avoid merging meaningful code from a phone unless the change is extremely small and the evidence is clear.

Use mobile to:

• keep an agent from blocking,
• catch obvious drift,
• request a narrower fix,
• approve low-risk commands,
• and decide whether a branch is ready for desktop review.

Use desktop to:

• review large diffs,
• reason through architecture,
• inspect generated tests,
• run broader validation,
• and merge changes that affect users or shared systems.

That division keeps the workflow fast without pretending the smallest screen is the best review environment.

Start with one review habit

The best first habit is simple: every time an agent claims it is done, check the changed file list before reading the summary.

Summaries can sound plausible. File lists are harder to hand-wave. If the file list matches the task, keep reading. If it does not, ask why before approving anything else.

Junction makes that habit easier because the run, output, approvals, and review context live in the same web control surface. Start with the Junction setup guide if you have not paired a daemon yet. If you need more open chats, more daemons, or Switchboard automation, compare pricing.