Choosing a Surface for Four Scenarios
For each scenario below, name the Claude Code surface (or combination of surfaces) you'd recommend, and justify the choice using the concrete capabilities and limitations of that surface — not just a vibe.
- A developer is on a train with only their phone, and needs to check whether a bug fix they kicked off before leaving the office has finished, and possibly redirect it if it went down the wrong path.
- A teammate wants to review a large, multi-file refactor PR, leave comments on specific lines, and have Claude address them, all without leaving a GUI.
- A CSS bug report says "the pricing table overlaps the footer on narrow viewports" with a screenshot attached.
- An engineering lead wants to demo a newly finished feature live to non-technical stakeholders in a meeting, showing the working app, not code.
1. Checking/redirecting a bug fix from a train:
This depends on whether the original task was a cloud session or a
local one. If it was started with --cloud (or from the web), the
right move is the Claude mobile app's Code tab, cloud sessions
view — cloud sessions run on Anthropic-managed infrastructure and
keep going even with the developer's laptop closed, so checking
progress and sending a follow-up message works from anywhere with
network access. If the original task was a local session on the
developer's own machine (and that machine is still on), Remote
Control from the mobile app is the alternative — it drives the
actual local session, so redirection reaches the real running process.
Either way, the key fact is that the mobile app is a client, not
compute: it cannot run the task itself, only reach one of these two
backends. A phone with no paired machine and no cloud session simply
has nothing to reach.
2. Multi-file PR review with inline comments in a GUI:
Desktop's diff view (or a shared web session) is built exactly for this: the diff view lets you click any line to open a comment box, compose comments across multiple lines, and submit them all at once (Cmd/Ctrl+Enter), after which Claude reads the comments and produces a new diff to review. The VS Code extension also supports inline diff review with accept/reject per change and a permission-mode-aware review flow. A pure CLI review would mean reading a text diff and typing feedback as prose — functionally possible, but it loses the "click the exact line, leave a comment there" workflow the question is asking for, so Desktop, the web, or VS Code are the correct recommendations over the bare CLI.
3. A CSS bug with a screenshot attached:
This is the textbook case for Chrome-connected Claude Code (CLI
with --chrome, or the VS Code extension with the Chrome extension
installed), because it turns "read the CSS and guess" into "resize
the actual viewport, screenshot the actual clipped state, fix the
rule, screenshot again to verify." The attached screenshot is useful
context to start from, but a live, Chrome-connected reproduction is
strictly stronger evidence than a single static image, since Claude
can resize the window to reproduce the "narrow viewports" condition
precisely and confirm the fix visually rather than trusting that the
CSS change should fix what the screenshot showed. Desktop's built-in
preview pane (with autoVerify) is an equally valid answer if the
developer already works in Desktop, since it runs the same
screenshot/DOM-inspection tools on a clean browser profile.
4. A live demo to non-technical stakeholders:
Desktop's live preview pane (or VS Code's equivalent) is the right call: it shows the actual running app in a Browser pane rather than a terminal transcript full of tool calls and diffs that mean nothing to a non-technical audience. A CLI session would force the presenter to either narrate raw text output or separately open a browser and hope the two stay in sync; Desktop keeps "what Claude did" and "what the app now looks like" in the same window, which is what a demo actually needs.
Share this question