[BUG] Claude crashes consistently after Claude Browser MCP preview_start completes on Windows

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?

Claude repeatedly crashes/terminates immediately after using the Claude Browser MCP.

I reviewed the MCP Browser logs rather than relying only on the visible Claude error.

Today, multiple independent Claude Code sessions in the same project ended immediately after a Claude Browser MCP operation.

Seven sessions ended with:

"Tool 'preview_start' completed successfully"

Nothing was logged after that event before the session terminated.

An additional session ended on a javascript_tool browser operation.

Two failures in this conversation reproduced the same pattern:

preview_start
→ app.omivoai.com/login
→ browser tool reports successful completion
→ no further MCP log entry
→ Claude session/process terminates

This is important because the browser tool itself reports success. There is no browser-tool error explaining the subsequent termination.

The failures are not limited to one specific task or command. They occurred across unrelated work in the same project.

I also investigated the CoworkVMService because the Claude Desktop/Cowork environment becomes unavailable after these failures.

The CoworkVMService repeatedly initializes successfully:

• vmcompute.dll loads successfully
• computecore.dll loads successfully
• HCS becomes ready
• HCN initializes successfully
• named pipe server starts successfully
• Claude Desktop connects successfully
• Claude's executable signature is verified
• a VM session is created
• persistent RPC enters its loop

The Cowork service then records:

"Persistent RPC: connection ended: failed to read length: EOF"

After the EOF, the session has no active connections and the service later receives a stop request.

This sequence repeats multiple times.

For example:

16:34:10 - CoworkVMService starts
16:34:10 - HCS/HCN initialize successfully
16:34:10 - named pipe server starts
16:34:12 - Claude client connects
16:34:13 - Claude signature verified
16:34:13 - VM session created
16:34:13 - Persistent RPC starts
16:35:31 - Persistent RPC connection ends with EOF

The Cowork log therefore suggests that the RPC EOF may be a consequence of the Claude/browser host terminating or disconnecting rather than Cowork failing during initialization.

The browser MCP logs are especially interesting because the final recorded event is frequently a successful preview_start operation immediately before the session terminates.

Memory pressure also does not appear to explain the behavior. At the time of investigation the machine had approximately 12.2 GB free RAM out of 23.4 GB usable, with approximately 31% commit.

I have not yet identified the exact native component responsible for the termination.

The likely area to investigate is the Claude Browser MCP/browser pane and its interaction with the Claude host process, Chromium/browser process, native modules, or GPU/renderer components on Windows.

The exact root cause is not yet proven; the strong reproducible correlation is:

Claude Browser MCP preview_start/javascript_tool
→ tool reports success
→ no subsequent MCP log entry
→ Claude session terminates
→ Cowork RPC eventually reports EOF
→ Cowork environment becomes unavailable.

What Should Happen?

Claude should remain running after a Claude Browser MCP operation successfully completes.

A successful preview_start or javascript_tool browser operation should not terminate the Claude session or cause the Cowork environment to become unavailable.

The browser pane/MCP host should either:

1. complete the operation and return control normally, or
2. report a clear browser/MCP error if the browser operation fails.

It should not successfully report completion and then terminate the host process/session without a diagnostic error.

If the Cowork connection is lost as a consequence of a host failure, the user should receive a meaningful diagnostic error rather than only:

"Remote environment unavailable"

or:

"Session initialization failed (environment_deleted)"

The CoworkVMService should also remain connected while the Claude session is active.

Error Messages/Logs

The most relevant browser MCP evidence is that multiple sessions end immediately after:

"Tool 'preview_start' completed successfully"

There is no subsequent MCP log entry before the session terminates.

An additional session ended on a browser javascript_tool operation.

The corresponding CoworkVMService log repeatedly reports:

"Persistent RPC: connection ended: failed to read length: EOF"

followed by:

"Session User:C:\Users\User\AppData\Roaming\Claude has no active connections, idle timeout starts"

The Cowork service then later receives:

"Service stop requested"

and shuts down.

Example:

2026/08/09 16:34:10.214285 Starting CoworkVMService as Windows service
2026/08/09 16:34:10.297411 Service ready. Listening on \\.\pipe\cowork-vm-service
2026/08/09 16:34:12.858299 [Server] Client connected
2026/08/09 16:34:13.097361 [Server] Client signature verified:
C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\claude.exe
2026/08/09 16:34:13.098395 [Server] Client connected: user=User exe=claude.exe isDev=false
2026/08/09 16:34:13.098925 [Server] Created new VM session for User:C:\Users\User\AppData\Roaming\Claude
2026/08/09 16:34:13.098925 [Server] Persistent RPC: entering loop

2026/08/09 16:35:31.728031 [Server] Persistent RPC:
connection ended: failed to read length: EOF

2026/08/09 16:35:31.728031 [Server] Session User:C:\Users\User\AppData\Roaming\Claude:
has no active connections, idle timeout starts

Steps to Reproduce

1. Use Claude Desktop/Cowork on Windows 11.

1. Open or use the Claude Browser MCP.

1. Start a browser preview using preview_start.

1. Use the browser against a web application. In my reproductions this included:

app.omivoai.com/login

1. The browser tool reports:

"Tool 'preview_start' completed successfully"

1. The MCP log stops immediately after this successful event.

1. The Claude session then terminates/crashes without another MCP error being logged.

1. CoworkVMService subsequently records an RPC EOF:

"Persistent RPC: connection ended: failed to read length: EOF"

1. The Cowork session becomes unavailable and Claude can display:

"Remote environment unavailable"

"The remote environment this session was connected to is no longer available.
Start a new session to continue."

"Session initialization failed (environment_deleted)"

1. Repeat the process in another Claude session.

The same pattern occurred across multiple sessions on the same day.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.226

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Environment:

Claude Desktop:
1.26832.0.0

Claude Code CLI:
2.1.226

Claude Desktop package:
Claude_1.26832.0.0_x64__pzs8sxrjxfjjc

Installation type:
MSIX

Operating System:
Windows 11 Home
64-bit
Build 10.0.26200

CPU:
AMD Ryzen 7 5700G with Radeon Graphics
3.80 GHz

RAM:
24 GB installed
23.4 GB usable

GPU:
AMD Radeon(TM) Graphics
Integrated Radeon Graphics
496 MB displayed graphics memory

Motherboard:
B550M K

Storage:
477 GB total
Approximately 460 GB used
Approximately 17 GB free

Claude Desktop user data:
C:\Users\User\AppData\Roaming\Claude

Claude logs:
C:\Users\User\AppData\Roaming\Claude\logs\

Cowork service log:
C:\ProgramData\Claude\Logs\cowork-service.log

Claude Browser MCP logs:
C:\Users\User\AppData\Local\claude-cli-nodejs\Cache\C--Users-User-Downloads-Nurekhanew-main\mcp-logs-Claude-Browser\

The Claude Desktop package is installed through MSIX on a non-system volume.

The Claude Browser MCP logs remain writable and contain multiple sessions from
2026-08-09. Multiple sessions end immediately after a successful browser
preview_start operation.

At the time of investigation, approximately 12.2 GB RAM was free and system
commit was approximately 31%, so there was no obvious system-wide memory
pressure.