[BUG] claude-in-chrome set_permission_mode storm wedges entire CLI session at startup when browser is not running (Windows) - un-typeable, no transcript, recovers only when Chrome is opened

Summary

On Windows, when a session starts in a project directory with claudeInChromeDefaultEnabled: true and Chrome is not running, the in-process "Claude in Chrome" MCP server fires a burst of set_permission_mode calls that each block ~10s (the browser-not-connected timeout). These stack up and wedge the entire CLI session: the prompt never becomes interactive, no conversation transcript is ever written, and CPU drops to ~0 (blocked, not spinning). The session stays frozen indefinitely. Opening Chrome immediately unblocks it.

This appears to be the severe escalation of the same startup race in #51569 (there it only clobbered the welcome header; here it freezes the whole session), combined with the "exactly 10s" browser-not-connected timeout seen in #67778 / #47167.

Environment

• Claude Code v2.1.195
• Windows 11 Pro 10.0.26200
• Native install (%USERPROFILE%\.local\bin\claude.exe), launched in a terminal
• claudeInChromeDefaultEnabled: true; Chrome not running at launch

What happens

1. Start claude in a project directory; Chrome is closed.
2. The in-process Chrome MCP server connects, then issues ~9 set_permission_mode calls within ~2 seconds.
3. Each call blocks ~8-10s (browser-not-connected timeout) and they drain in a batch.
4. After they drain, the session never reaches an interactive prompt. The cursor blinks (OS terminal cursor) but no input is accepted, and no transcript file is created for the session.
5. Process sits at ~0% CPU (blocked on I/O, not spinning).
6. Launching Chrome unfreezes the session instantly.

Evidence (sanitized)

From ...\claude-cli-nodejs\Cache\<project>\mcp-logs-claude-in-chrome\...jsonl:

"In-process Chrome MCP server started"  ... cwd: C:\Users\<user>\<project>
"Successfully connected (transport: stdio) in 27ms"
"Calling MCP tool: set_permission_mode"   (x9, within ~2s)
"Tool 'set_permission_mode' completed successfully in 10s"  (x3)
"... completed successfully in 9s"  (x4)
"... completed successfully in 8s"  (x1)

All MCP logging stops immediately after this batch. No further activity; no transcript written; the process remains alive but un-interactive until Chrome is opened.

Impact

A closed browser at launch silently freezes the whole CLI, not just the browser tools. Because it happens before the REPL is ready, there is no error shown and no transcript, so it is hard to diagnose (it looks like a generic "stuck terminal").

Suggested fixes

• Make set_permission_mode (and other startup browser calls) non-blocking / fire-and-forget, or move them off the startup critical path, so a missing browser cannot gate the REPL.
• Fail fast instead of a 10s timeout per call when no native-messaging bridge exists, and do not issue the call N times during startup.
• Surface a non-fatal warning ("browser not connected; browser tools disabled until Chrome is running") instead of silently blocking.

Related

#51569 (same set_permission_mode startup race, cosmetic symptom), #67778, #47167 (browser-not-connected / "exactly 10s" timeout on Windows).