Preview Browser Serves Stale Client-Side JavaScript Despite Full Cache Clear

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Claude Code Preview browser (preview_* MCP tools) persistently serves stale/cached client-side JavaScript bundles even after fully stopping the server, deleting the .next build cache, and restarting.

I edited a React client component (changed button text, CSS classes, and layout structure). The source file, TypeScript compilation, and SSR compiled output all confirmed the new code — but the preview browser kept rendering the OLD version.

Tried all of the following with no success:

• preview_stop → rm -rf .next → preview_start (multiple times)
• location.reload(true) (hard reload)
• Clearing Service Workers and Cache API via preview_eval
• Cache-busting query parameters (?nocache=timestamp)
• touch on the source file to trigger HMR

The embedded browser's internal cache appears to survive across server stop/start cycles and cannot be cleared by any available method.

What Should Happen?

After stopping the preview server and restarting it (especially after deleting the build cache), the preview browser should serve fresh content with no stale JavaScript bundles.

Ideally, one of the following should exist:

1. A preview_clear_cache tool to explicitly flush the browser cache
2. Automatic cache clearing when preview_stop is called
3. A clearCache: true option on preview_start
4. A fresh browser profile/context for each preview_start invocation

Error Messages/Logs

No error messages — the issue is silent. The browser renders without errors but with outdated content.

Evidence of mismatch:

Source file (correct):
  className: "rounded border px-2 py-1.5"
  button text: {gun}  (number only)

SSR compiled output (.next/) (correct):
  grep confirms "rounded border px-2 py-1.5" present
  grep confirms old class "rounded-lg border px-2 py-1" NOT present

Browser DOM via preview_eval (stale):
  className: "rounded-lg border px-2 py-1"  ← OLD
  button text: "1 gün", "3 gün" ...          ← OLD

Environment: macOS, Next.js 16.1.6 (Turbopack), Claude Code latest

Steps to Reproduce

1. Create a Next.js 16 project with a "use client" component
2. Start the dev server via preview_start
3. Navigate to a page that renders the component and verify via preview_screenshot
4. Edit the client component (e.g., change CSS class from rounded-lg to rounded, change button text)
5. Stop the server via preview_stop
6. Delete the build cache: rm -rf .next
7. Restart the server via preview_start
8. Navigate to the same page and verify via preview_eval / preview_screenshot

Result: The browser still renders the OLD component code. The SSR compiled output in .next/ contains the correct new code, but the browser DOM shows stale classes and text.

Tried additionally: location.reload(true), clearing Service Workers, clearing Cache API, cache-busting query params, touch source file — none resolved it.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.63 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Suggested Fix

At minimum, one of the following would resolve this:

1. A preview_clear_cache tool to explicitly flush the embedded browser's disk/code cache
2. Automatic cache clearing when preview_stop is called
3. A clearCache: true option on preview_start
4. Use a fresh browser profile/context for each preview_start invocation

Key Observation

The issue specifically affects client-side hydration bundles. Server-side rendered output
(verified via grep on .next/dev/server/chunks/ssr/*.js) is always correct and up-to-date.
The stale code only appears in the browser's client-side JavaScript execution, suggesting
the embedded Chromium's V8 code cache or disk cache is not being invalidated.

Impact

This makes iterative UI development with preview_screenshot unreliable. Once a component
is first rendered in the preview browser, subsequent code changes may never be visually
verifiable — forcing developers to rely solely on source code inspection and TypeScript
compilation for verification.