Review Claude Code's Diffs on Your Phone, File by File

Claude Code finished the task while you were out. The notification says it's done, and you have ten minutes on a train. You could wait until you're back at your desk, or you could actually look at what it changed, leave a few notes and have the fixes ready when you sit down. This post shows how to review an agent's work on a small screen without missing what matters, and when to stop and save it for the big one.

Why "the agent finished" isn't enough

A finished session tells you Claude stopped. It doesn't tell you whether the change is right. Agents are good at producing code that compiles and looks plausible, and that's exactly why it needs a human read:

• Scope creep. You asked for a bug fix, and it also renamed a helper and touched three other files.
• Quiet assumptions. It picked a default, skipped an edge case or changed an error message users see.
• Tests that test the wrong thing. A new test passes because it asserts what the code does, not what it should do.
• Leftovers. Debug logging, commented-out code, a TODO it meant to come back to.

Catching these early is cheap. Catching them after you've stacked three more tasks on top is not. Reviewing from your phone means the loop doesn't wait for you to get back to a computer.

There are several ways to look at an agent's changes away from your desk. If Claude opened a pull request, GitHub's mobile app works. A number of dedicated mobile apps for Claude Code now exist too; Nimbalyst keeps a roundup. The rest of this post shows the workflow in Coder IDE, where the review happens next to the real editor on your own computer.

Reading diffs on a small screen, file by file

A full unified diff of a 12-file change is unreadable on a phone. The trick is to go one file at a time, in the order that matters.

In Coder IDE, open Sessions. Every Claude Code session on your computers shows up there, whether it started in a terminal, in VS Code or in the background, grouped by what needs you. Tap the session that finished, then open its changes. You get a list of the files it touched and can step through them one by one.

A reading order that works:

1. Skim the file list first. Does the set of files match what you asked for? A surprise file is the first thing to look at.
2. Read the core change. The one or two files where the actual logic changed. Read every line here.
3. Read the tests. Check that they assert the behaviour you wanted, not just the behaviour Claude wrote.
4. Skim the rest. Imports, types and wiring. Look for deletions you didn't expect.

On a phone, turn the screen sideways for long lines. On a tablet, the session list and the open session sit side by side, which makes jumping between files faster.

Treat the phone review as a filter, not a sign-off. Its job is to catch what's wrong early and send it back, not to approve a merge.

Comment on lines, send everything back in one message

The slowest way to give feedback from a phone is to type a long chat message describing which line in which file you mean. Line comments fix that.

While you review, tap any line and leave a comment, the way you would on a pull request:

• "This should handle an empty list."
• "Keep the old function name, other packages import it."
• "Remove this log line."
• "Why is this timeout 30 seconds?"

You can leave as many as you like across all the files. When you're done, send them all back to Claude in a single message. Each comment arrives with its file and line, so Claude knows exactly what you're referring to and can work through them in one pass.

This is also where Coder IDE's session tools help. You can reply to a session or start a new one in any project from your phone, and your computer picks it up even while you're away. If Claude needs permission for something while it works through your comments, you get a push notification and can approve or deny it after seeing the full request. Approve Claude Code permission prompts from your phone covers that part in detail.

Jump into the real editor when a fix is faster by hand

Sometimes a comment is slower than the fix. Changing one constant or deleting a stray line takes three seconds in an editor.

From the review, Open in VS Code takes you straight to the file and line you were reading, in the full editor running on your computer. It's Microsoft's VS Code with your extensions, settings and terminal, so you can make the edit, save, and go back to the session. In the Android app, a key bar above the keyboard gives you Esc, Tab, Ctrl, Alt, arrows and Save, which makes small edits on a touchscreen workable.

The Agent view is the other half of this. It's a focused layout for working with Claude, one tap from the full IDE, so moving between talking to Claude and editing code doesn't feel like switching apps.

Check the result, not just the code

A diff can look perfect and the page can still be broken. If the change touched a web app, look at it.

If your dev server is running on your computer, it shows up in the Ports panel. Turn on Allow preview for its port to get a private link that only opens for you, then open it on your phone and click through the change. The Preview button in the editor opens the running app beside your code or in its own tab. Ports lists servers started in any terminal on your computer, including the one Claude started.

If something looks off, you can annotate the preview: tap, pin or sketch on the page, then add the screenshot and your notes to Claude's chat box and press send. That's often clearer than describing a layout bug in words. For more on previews from a phone, see open your localhost dev server on your phone.

What to defer to a big screen

Phone review is good for catching problems and steering. Some things deserve a desk:

• Large refactors. If a change touches dozens of files, you'll miss things scrolling on a phone. Read the file list, leave a note, and do the real review later.
• Security-sensitive code. Auth, permissions, payments, anything handling secrets. Review it where you can see the whole context.
• Database migrations. Read them carefully, ideally next to the schema.
• Dependency changes. New packages and version bumps deserve a proper look at what's being pulled in.
• The final merge. Run the full test suite and look at the complete diff before it goes to main.

A good rule: if you'd ask a teammate to walk you through it, it's a big-screen review.

Wrap-up

Reviewing an agent's work on your phone isn't about replacing code review. It's about keeping the loop moving: see what changed file by file, comment on the lines that matter, send it all back in one message, fix the trivial bits by hand in the real editor and check the running app. When you get back to your desk, the second round is already done.

If you run several agents at once, run Claude Code on several computers, manage it from one phone shows how to keep track of them all.

Start free. The free plan covers one computer.