How to Let Claude Code See Your App While Coding

If you've ever watched an agent confidently "fix" a layout bug it has never actually looked at, this one's for you. Here are the four ways to give Claude Code eyes on your running app — and which one fits which stack.

To let Claude Code see your app while coding, connect a tool it can call to capture what's actually rendered: a browser MCP server for web apps, a live-view MCP server for the iOS Simulator and browser tabs, or Claude Code's built-in computer use for everything else. Once one of these is connected, Claude checks its own work after every change instead of relying on your descriptions of what's on screen.

We build AppContext, one of the options below, so we're not a neutral party — but the honest answer to this question depends on what kind of app you're building, and for some stacks the right tool isn't ours. Here's the current landscape, followed by what the automated see-edit-verify loop actually looks like once it's running.

Why Claude Code needs a way to see your app

Claude Code reads your files, runs your build, and edits your components, but it has no idea what any of that renders to. It can write plausible CSS and still ship a button clipped off the right edge of the screen, because “compiles cleanly” and “looks right” are different facts.

Anthropic's own best-practices guide for Claude Code is blunt about the fix: “Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from.” For logic, the check is a test suite. For UI, the check is visual — and if the agent can't capture it on its own, you become the verification loop. Every regression waits for you to notice it, screenshot it, and paste it into the terminal.

Everything below is a way to hand that job to the agent.

The four ways to let Claude Code see your app

Approach	What it can see	Requirements	Best for
Manual screenshots	Anything you capture yourself	None	One-off questions
Browser MCP server	Web apps in a browser it controls	Node.js; free	Web frontends
Computer use	Your whole screen	macOS; Claude Pro/Max plan	Native apps, GUI-only tools
Live-view MCP server	iOS Simulator + Chrome tabs, plus logs	macOS; live view is a Pro feature	React Native / Expo + web

1. Paste screenshots by hand

The baseline. Claude Code accepts pasted images, so you can screenshot the simulator or browser and drop the image into your prompt. It works for anything, costs nothing, and is fine for occasional questions. The problem is who does the capturing: you, on every iteration. The agent can't re-check its own fix, so the loop never closes without you standing in the middle of it.

2. A browser MCP server (web apps)

For web frontends there are two free, officially maintained options. Chrome DevTools MCP, maintained by the Chrome DevTools team, gives the agent a Chrome instance it can navigate, screenshot, and inspect — console messages, network requests, and performance traces included. Playwright MCP, from Microsoft, leans on accessibility-tree snapshots — structured text the model reads directly — with screenshots as a secondary tool.

Both are excellent at what they cover, and what they cover is a browser they launched: your web app, yes; your iOS Simulator, your Metro terminal, or a native window, no.

3. Claude Code computer use (anything on screen)

Claude Code now ships computer use as a built-in MCP server you enable from the /mcp menu. It's the broadest option: Claude can launch apps, click, type, and screenshot anything on your display, including the iOS Simulator or a native macOS app. It's also the heaviest. It's a research preview, macOS-only in the CLI, requires a Pro or Max plan, hides your other apps while it works, and takes a machine-wide lock so only one session can use it at a time.

Anthropic's docs are upfront about where it sits in the tool hierarchy: Claude tries the most precise tool first, and “if you have an MCP server for the service, Claude uses that.” Screen control is the fallback for things nothing else can reach — not what you want firing on every iteration of a CSS tweak.

4. A live-view MCP server (iOS Simulator and web, with logs)

This is the gap AppContext fills. It's a macOS menu bar app that gives AI coding agents live visual context over MCP: fetch_liveview returns a fresh capture of the iOS Simulator or a Chrome tab you pick, fetch_recent_logs streams Metro bundler output for React Native and Expo apps, and fetch_web_console returns browser console logs. No browser takeover, no screen lock — the agent grabs exactly the surface it needs in one tool call and keeps working. The trade-offs, stated plainly: it's macOS-only, and live view is a Pro feature (the MCP Hub side of the app is free).

If you're all-in on Expo specifically, the official Expo MCP is also worth a look: it adds screenshots, tap automation, and element inspection for Expo SDK 54+ projects with a running dev server.

What the automated loop actually looks like

Here's the workflow shift, using a bug class we hit constantly in React Native work: a bottom sheet renders behind the tab bar on one screen. Without visual access, you describe it in words, Claude picks one of three plausible z-index theories, and you paste a fresh screenshot between every attempt.

With a live-view tool connected, the prompt changes shape:

The bottom sheet on the settings screen renders behind the tab bar.
Fix it, then fetch the live view and confirm the sheet is on top.
Check the Metro logs if anything throws.

And the session runs like this:

1. Claude calls fetch_liveview and sees the broken state directly — no description tax, no guessing which theory matches reality.
2. It pulls fetch_recent_logs, checks for warnings from the sheet library, and edits the component.
3. Metro hot-reloads. Claude calls fetch_liveview again and compares against what it saw before.
4. Still wrong? It iterates without waiting for you. Fixed? It shows you the final capture as evidence instead of asserting success.

The load-bearing phrase in that prompt is “then fetch the live view and confirm.” You're giving the agent the check, not just the task — exactly the pattern the best-practices doc pushes. Once the tool exists, one sentence turns any UI request into a self-verifying one. Agents often reach for the tool unprompted after the first use; early in a session, a nudge helps.

The same loop covers web work. Switch AppContext's platform to a Chrome tab and the identical prompt pattern handles a layout regression in a Next.js app, with fetch_web_console standing in for Metro logs when something throws at runtime.

Which one should you pick?

• Pure web app, Claude Code only: start with Chrome DevTools MCP or Playwright MCP. Free, official, and purpose-built for the browser.
• React Native or Expo on the iOS Simulator: a live-view MCP server. Browser MCP servers can't see the Simulator, and computer use is too heavyweight to fire on every iteration. This is AppContext's home turf — simulator captures and Metro logs in the same session. Expo MCP is a solid alternative if your project is Expo SDK 54+.
• Native macOS apps or GUI-only tools: computer use is the only option on this list that can see them at all.
• More than one agent (Claude Code plus Cursor, Windsurf, or Claude Desktop): favor plain MCP servers over client-specific features. Computer use and the Claude Desktop preview pane are Claude-only; an MCP server works in every client that speaks the protocol.

Connecting it to Claude Code

The AppContext setup is two steps — the full walkthrough lives in our Claude Code visual context guide. Install the app from appcontext.dev, then register the local endpoint:

claude mcp add --transport sse appcontext http://localhost:7777/sse

Restart Claude Code and the tools appear in /mcp. With your simulator or dev server running, ask for any UI change plus a “verify it” clause and watch the loop close on its own.

One connection, every agent

The quiet advantage of the MCP route is that nothing about it is Claude Code-specific. Cursor, Windsurf, and Claude Desktop speak the same protocol, so the same local endpoint gives every agent you use the same eyes. AppContext also works as a personal MCP hub, so your visual-context tools and the rest of your MCP servers ride one connection per client instead of a config file per tool — with per-tool authorization policies deciding what each agent is allowed to call.

The difference between an agent you supervise and one you can walk away from on UI work is a check it can run itself. Give Claude Code a way to see your app — whichever of the four fits your stack — and the screenshot-paste treadmill goes away.

FAQ

Can Claude Code see my screen without any setup?

No. Out of the box, Claude Code only sees what you paste into the prompt. To let it capture your app on its own you need to enable its built-in computer use (macOS, Pro or Max plan) or connect an MCP server that exposes screenshot tools, such as Chrome DevTools MCP for web apps or AppContext for the iOS Simulator and browser tabs.

Can Claude Code take screenshots of the iOS Simulator?

Yes, three ways: run xcrun simctl io booted screenshot yourself and paste the image; enable Claude Code's computer use and let it drive the Simulator window; or connect a live-view MCP server like AppContext so the agent fetches a fresh simulator capture in a single tool call, alongside Metro bundler logs.

What's the difference between computer use and an MCP screenshot server?

Computer use is general screen control: it can see and click anything, but it's a research preview, hides your other apps while working, holds a machine-wide lock, and requires a Pro or Max Claude plan. An MCP screenshot server exposes one purpose-built tool call that returns a capture of a specific surface without taking over your screen. Claude Code's own docs recommend using an MCP server when one exists and reserving screen control for what nothing else can reach.

Does the same setup work with Cursor and Windsurf?

If you go the MCP route, yes. MCP is an open standard, so a server like AppContext configured once works in Claude Code, Cursor, Windsurf, and Claude Desktop alike. Client-specific features such as Claude Code's computer use or the Claude Desktop preview pane don't transfer to other agents.

Is any of this free?

Chrome DevTools MCP and Playwright MCP are free and open source. Claude Code's computer use requires a Claude Pro or Max plan. AppContext's MCP Hub is free; its live view for the iOS Simulator and web is a Pro feature, and the app is macOS-only.