Remote-control bridge never reconnects after first pairing (bridge_state stuck from initial launch only)

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 desktop app's remote-control feature (used to control a local Claude Code terminal session from the mobile/web client) only establishes correctly on the very first app launch after login. On every subsequent app restart, and even after running claude /logout followed by claude /login, the remote client shows a persistent connection error and never reconnects:

원격 제어 연결 끊김 (Remote control connection lost) 터미널의 Claude Code 세션이 응답을 멈췄습니다. (The terminal's Claude Code session stopped responding.) "The bridged Claude Code process stopped responding mid-turn. Check your terminal for errors (you may need to run /login), then resend your message."

The local terminal session itself stays fully responsive the whole time — only the remote pairing is affected. Clicking the client's "다시 시도" (Retry) button has no effect.

What Should Happen?

Remote control should reconnect to the terminal session automatically after an app restart or re-login, the same way other internal bridges (buddy, sessions-bridge, cliPluginBridge) already do on every restart. At minimum, a clear and actionable error should be shown instead of an indefinite disconnected/retry loop.

Error Messages/Logs

From %APPDATA%\Claude\logs\main.log — these are the ONLY two [remote-control] lines in the entire log file, both from the very first successful pairing:

2026-07-25 16:39:03 [info] [remote-control] bridge_state: ready
2026-07-25 16:39:03 [info] [remote-control] bridge_state: connected

The app was subsequently restarted at least 3 more times (17:38:33, 19:07:09, and again after this report) and the user ran `claude /logout` + `claude /login` (login succeeded) — none of these produced a new bridge_state log line, while other bridges reinitialize every time:

[buddy] starting bridge
[buddy] bridge started
[sessions-bridge] account-change reevaluate: ...
[cliPluginBridge] registered

Also observed, right before the first user-visible failure, a local PTY restart loop for the same session id (local_426e4925-1b86-4fd1-84f8-50f147623528):

2026-07-25 18:39:54 [warn] [event-loop-stall] main process blocked for 735ms (task webrequest:before-send-headers=0ms, total 1, cumulative 735ms, rss 231MB)
2026-07-25 18:39:55 [info] LocalSessions.startShellPty: sessionId=local_426e4925..., cols=80, rows=24
2026-07-25 18:40:48 [info] LocalSessions.startShellPty: sessionId=local_426e4925..., cols=80, rows=24
2026-07-25 18:41:02 [info] LocalSessions.startShellPty: sessionId=local_426e4925..., cols=80, rows=24
2026-07-25 18:41:20 [info] LocalSessions.startShellPty: sessionId=local_426e4925..., cols=80, rows=24

(4 PTY restarts within ~2 minutes, immediately following the event-loop stall.)

Steps to Reproduce

1. Launch Claude Desktop and pair a terminal session with the remote-control (mobile/web) feature. Confirm the first connection succeeds (client shows the session live).
2. Fully quit and relaunch the Claude Desktop app (or run claude /logout then claude /login in the paired terminal, which also fully re-authenticates).
3. From the mobile/web client, open the same session and send a message.
4. Observe: the client shows "원격 제어 연결 끊김" ("The bridged Claude Code process stopped responding mid-turn") and the "다시 시도" (Retry) button does not recover it — even though the local terminal is idle and fully responsive.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Troubleshooting already tried (no effect on the remote-control issue):

• Clicking "다시 시도" (retry) in the client, multiple times
• Fully restarting the Claude Desktop app (3+ times)
• claude /logout + claude /login (re-authentication succeeded)
• Confirmed no stale/zombie app process from a previous generation (all Claude.exe children share one CreationDate/parent)
• Confirmed HTTPS connectivity to claude.ai and api.anthropic.com (port 443) is fine
• Confirmed the CLI is on the latest published npm version (2.1.220)
• Confirmed the system is not resource-constrained (23GB+ free RAM at time of testing)

A separate, likely-unrelated recurring error in the same log window:
[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile '...\chrome-native-host.exe' -> '...\ChromeNativeHost\chrome-native-host.exe'