Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [Bug] Windows WebView stuck on chrome-error after preview_stop/preview_start cycle with orphaned processes [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54554•Fetched 2026-04-30 06:42:28
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
0
Author
JamBalaya56562JamBalaya56562
Participants
0xbrainkid0xbrainkidJamBalaya56562JamBalaya56562
Timeline (top)
labeled ×4commented ×2cross-referenced ×1

Error Message

Windows: Preview tool WebView stuck on chrome-error after preview_stop/preview_start cycle

1. mcp__Claude_Preview WebView gets stuck on chrome-error://chromewebdata/

no effect — location.href keeps reporting chrome-error://chromewebdata/. 6. WebView stuck on chrome-error; orphaned node processes consuming ~1.5GB

Code Example

[]
RAW_BUFFERClick to expand / collapse

Bug Description

Windows: Preview tool WebView stuck on chrome-error after preview_stop/preview_start cycle

Environment

  • OS: Windows 11 (DESKTOP-U30T4EP)
  • Claude Desktop: 1.5354.0.0
  • claude-code CLI: 2.1.121
  • Project: Next.js 16.3.0-canary.5 + Turbopack
  • Runtime: bun 1.3.11 via mise (also tested with node_modules/.bin/next.exe directly)

Issues

1. mcp__Claude_Preview WebView gets stuck on chrome-error://chromewebdata/

After calling preview_stop then preview_start (even with a new serverId), the WebView refuses to reach localhost:3000 (and 127.0.0.1:3000). The dev server itself is verified reachable: Invoke-WebRequest http://localhost:3000/en returns 200 with full HTML (127KB). Only the embedded WebView is broken.

window.location.href = 'http://localhost:3000/en' from preview_eval has no effect — location.href keeps reporting chrome-error://chromewebdata/.

The first preview_start of a session works correctly. Only restarts fail.

2. preview_stop leaves orphaned descendant processes

On Windows, preview_stop only terminates the wrapper process (next.exe shim or bun.exe). The actual node-based dev server and its 5-7 worker subprocesses (~1.5 GB total) survive as orphans, holding port 3000 and file handles under .next/dev/cache/turbopack/. Subsequent preview_start then hits "port in use" or cache lock contention.

Mac doesn't exhibit either issue with identical Claude Code / Next.js versions.

Repro

  1. macOS works fine. Windows-only.
  2. bun dev (or next dev) for any Next.js 16 canary project
  3. mcp__Claude_Preview__preview_start → load page → works
  4. mcp__Claude_Preview__preview_stop
  5. mcp__Claude_Preview__preview_start again
  6. WebView stuck on chrome-error; orphaned node processes consuming ~1.5GB

Expected

  • preview_stop should terminate the entire process tree
  • WebView should recover and load the new server's URL

Environment Info

  • Platform: win32
  • Terminal: windows-terminal
  • Version: 2.1.121
  • Feedback ID: a5c90781-6004-442e-8b58-48af629ac42d

Errors

[]

extent analysis

TL;DR

The most likely fix involves ensuring that preview_stop properly terminates all descendant processes of the dev server to free up port 3000 and file handles.

Guidance

  • Verify that preview_stop is correctly implemented to terminate not just the wrapper process but all subprocesses of the dev server.
  • Check for any file handle locks or port usage by the orphaned processes after preview_stop is called.
  • Consider implementing a wait or retry mechanism in preview_start to ensure that all previous processes have been fully terminated before attempting to start a new server.
  • Investigate why the issue is Windows-specific, potentially looking into differences in process management or file system handling between Windows and macOS.

Example

No specific code example can be provided without more details on the implementation of preview_stop and preview_start, but ensuring that all processes are properly terminated could involve using a process tree killer or a more robust process management system.

Notes

The issue seems to stem from the improper termination of subprocesses by preview_stop, leading to resource conflicts when preview_start is called again. The fact that this issue does not occur on macOS suggests a platform-specific difference in how processes are handled.

Recommendation

Apply a workaround to ensure preview_stop properly terminates all descendant processes before calling preview_start again, as the root cause seems to be related to process management rather than a version-specific bug that could be fixed by an upgrade.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#conversation history#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] Windows WebView stuck on chrome-error after preview_stop/preview_start cycle with orphaned processes [2 comments, 2 participants]