Preview Your App While Claude Codes It

1. The problem with invisible development environments

When you use Claude Code to build a UI or a web application, you describe what you want, Claude writes code, you run the app to see if it looks right, and then you go back to Claude with corrections. This loop works, but it has a significant limitation: Claude is coding blind. It cannot see the running app. It writes code based on its understanding of your description and the codebase, makes changes, and hopes they produce the result you described. When they do not — when the layout is off, an error surfaces in the console, or a component renders incorrectly — the only way Claude finds out is when you describe the problem in the next message.

This invisible feedback loop degrades the quality of Claude’s iterative coding in two ways. First, Claude has to make more conservative assumptions about what is working rather than observing it directly. Second, the cycle of “describe problem → Claude makes change → you check in browser → describe new problem” is slower and more error-prone than direct observation. You have to translate visual and runtime information into natural language, Claude has to interpret that translation, and the round-trip adds latency and potential miscommunication at every step.

The app preview feature eliminates this gap. Claude Code on desktop can now start a development server for your project, open a live preview of the running application within the interface, and observe the rendered UI and console output directly. The feedback loop from code change to visual result is now closed within Claude Code itself — no more switching to a browser, no more manually copying error messages, no more describing layout issues in words when a screenshot would communicate them instantly.

2. What Claude can see in the preview

The preview capability gives Claude access to four distinct streams of information about the running application.

Rendered UI is the most impactful. Claude can take a screenshot of the current state of the application and reason about what it sees visually. This is qualitatively different from reading source code and imagining what it will look like — Claude sees the actual rendered output, including CSS layout behavior, font rendering, responsive breakpoints, component positioning, and visual hierarchy. When something looks wrong, Claude can identify it from the rendered output rather than requiring you to describe it.

Console logs give Claude access to the runtime information that JavaScript applications produce during execution: debug messages, network request details, state changes, third-party library output, and any console.log statements in the application code. Console logs are often the first indicator that something is behaving incorrectly even when the UI looks right — an incorrect API response, a state management issue, or a failed data fetch may not visually manifest immediately but will appear in the console.

Runtime errors are perhaps the most immediately useful input. When JavaScript throws an unhandled exception, a React render fails, a network request returns an error status, or a CSS rule causes a layout engine error, these surface as errors in the browser console. Claude can read these errors directly, identify the root cause in the source code, and fix them without you having to copy-paste error messages into the conversation.

Network requests round out the observability picture. Seeing which API requests are being made, what payloads they carry, and what responses they receive helps Claude debug integration issues between the frontend and backend without requiring you to manually inspect network traffic in browser devtools.

3. The iterative development loop

With app preview, the development loop shifts from a cycle that requires your participation at every step to one where Claude can drive many iterations autonomously. A typical session without app preview looks like: you describe a UI change → Claude implements it → you run the app → you describe what looks wrong → Claude implements a fix → you run the app again. Each iteration requires your active participation.

With app preview, a session can look like: you describe a UI goal → Claude implements an approach → Claude looks at the preview, sees a layout issue → Claude adjusts the CSS → Claude checks the preview again, sees an improvement → Claude checks the console, sees a type error → Claude fixes the type error → Claude confirms visually that the result matches your goal → Claude reports back that the work is done. You participate at the beginning and the end; the middle iterations are driven by Claude’s own observation and judgment.

This autonomous iteration loop is more efficient and often produces better results. Claude can try approaches that might not work, observe that they do not work, and try something different — without you needing to catch every failed attempt. This is how good developers actually work: you try something, look at the result, adjust, look again. App preview lets Claude work the same way.

4. Setup requirements and supported project types

App preview works with any project that can run a local development server. The requirement is that your project has a dev server command — npm run dev, yarn dev, python manage.py runserver, or equivalent — that starts a local server accessible at a localhost URL. Claude Code handles starting the server, watching for the port to become available, and connecting the preview panel to that URL.

Frontend frameworks with hot reloading work best: React projects using Vite or Create React App, Next.js applications, SvelteKit projects, Vue applications using Vite, and similar setups. The combination of fast reload times and rich browser console output gives Claude the tightest possible feedback loop. Full-stack applications where the backend and frontend both need to be running are supported — Claude can start multiple processes if needed.

Static site generators like Astro, Hugo, or Jekyll with a local dev server also work well, particularly for content and layout work. The feedback loop for seeing whether markdown content renders correctly, whether a CSS change affects the right pages, or whether a new component integrates cleanly into the existing design is greatly improved when Claude can see the rendered output directly.

Pure backend applications that produce API responses rather than visual UI have less to gain from the preview feature for normal development work, but still benefit from console log and error monitoring during debugging sessions.

🧠 Check your understanding

4 questions · your answers are saved in this browser only

1. 1. Why does the lack of app preview create a 'coding blind' problem for Claude Code?

   Claude cannot read CSS files without visual rendering Claude can only make one code change per session without visual feedback Claude cannot observe the running app, so it makes changes based on descriptions and hopes rather than direct observation — requiring you to relay all visual and runtime feedback App preview is required for Claude to start a dev server at all

   Without app preview, Claude codes blind — it cannot see the rendered UI, console logs, or runtime errors. All feedback must be relayed through your descriptions, creating a slower loop with more translation overhead and potential for miscommunication.

2. 2. Which of the following is NOT listed as something Claude can observe in the app preview?

   The rendered visual UI of the application Console logs produced during runtime Runtime errors and unhandled exceptions The full git history of all changed files

   Claude can observe rendered UI, console logs, runtime errors, and network requests through app preview. Git history is accessible through other Claude Code tools (reading files, running git commands) but is not part of what the preview feature specifically provides.

3. 3. What type of development framework gets the most benefit from the app preview feature?

   Pure backend API frameworks with no visual output Command-line tools that produce text output Frontend frameworks with hot module reloading, like Vite or Next.js, where code changes instantly appear in the preview Embedded systems that cannot run a local dev server

   Frontend frameworks with HMR get the most benefit because code changes instantly appear in the preview, giving Claude the tightest possible feedback loop. Slow rebuilds reduce the value of preview significantly; instant HMR maximizes it.

4. 4. How does app preview change the structure of a typical Claude Code development session?

   Claude writes all the code upfront and only checks the preview once at the end You must manually trigger each preview refresh after each Claude change Claude can autonomously iterate — implement, observe, adjust, observe — without requiring your participation at every step, reserving your input for the start and end of a task App preview only works when you are watching the session actively

   With app preview, Claude can drive many iterations autonomously: implement an approach, observe the result, notice issues, fix them, verify visually — without requiring you to relay feedback at each step. Your participation is needed at the goal-setting stage and for final review.

Reset quiz

🛠️ Build it yourself

Follow these exact steps to reproduce it yourself

1. Install Claude Code desktop — App preview is a desktop feature. Download the latest version of the Claude Code desktop app from claude.ai/download. CLI-only setups do not include the preview panel.
2. Verify your project has a dev server — Run your project’s dev server command manually first (npm run dev or equivalent) and confirm it starts successfully and is accessible in a browser at localhost. If it does not work manually, it will not work through Claude Code.
3. Enable hot reloading if not already active — Check whether your framework has hot module reloading configured. Vite, Next.js, SvelteKit, and most modern frameworks enable HMR by default. If your dev server requires a full restart for every change, the preview loop will be slower but still functional.
4. Open your project in Claude Code desktop — Use “Open Project” to navigate to your project directory. Claude Code will detect common project types and their dev server commands automatically.
5. Ask Claude to start the dev server and show a preview — Say “Start the dev server and show me a preview of the app.” Claude will run the server command, wait for it to become available, and open the preview panel.
6. Give a visual goal rather than a code instruction — Instead of “change the button background color to blue,” try “make the primary action button match the brand blue (#1D4ED8) and ensure it has enough contrast for accessibility.” Visual goals let Claude use the preview to iterate to the right result rather than making one change and waiting for your feedback.
7. Let Claude iterate — Resist the urge to check the preview yourself after every change. Let Claude observe and iterate autonomously. Intervene only when Claude asks for clarification or reports that it is done.