claude-code - 💡(How to fix) Fix Remote Control sessions show "Remote Control disconnected" banner on first turn despite session succeeding (control_response error="Already initialized") [2 comments, 3 participants]

Preflight Checklist

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

What's Wrong?

On every fresh Remote Control session, the desktop app and web client briefly show a red "Remote Control disconnected — Your terminal's Claude Code session stopped responding" banner immediately after sending the first message. The assistant response arrives ~2 seconds later and renders normally. The banner persists; the session continues to work.

Root cause (from bridge logs): The desktop app sends a control_request {subtype: "initialize"} immediately after spawn, but the SDK child has already auto-initialized because it was launched with --print --input-format=stream-json --output-format=stream-json. The SDK responds with control_response {subtype: "error", error: "Already initialized"}. The app treats that error as a fatal disconnect and surfaces the banner, even though the session is fully functional.

What Should Happen?

At least one of the following:

(a) The app should not send initialize to a stream-json session that auto-initializes on launch, or (b) The SDK should treat a duplicate initialize as a no-op success (idempotent), or (c) The app should not interpret control_response {error: "Already initialized"} as a fatal disconnect — it should recognize the session is alive and suppress the banner.

Error Messages/Logs

[bridge:ws] sessionId=cse_… <<< {"client_platform":"desktop_app","message":{"content":"hello hello",…},"type":"user",…}
[bridge:ws] sessionId=cse_… <<< {"request":{"subtype":"initialize"},"request_id":"…","type":"control_request",…}
[bridge:ws] sessionId=cse_… <<< {"type":"control_response","response":{"subtype":"error","error":"Already initialized","request_id":"…",…}}
[bridge:ws] sessionId=cse_… <<< {"type":"system","subtype":"init",…}
[bridge:ws] sessionId=cse_… <<< {"type":"assistant","message":{…}}
[bridge:ws] sessionId=cse_… <<< {"type":"result","subtype":"success","is_error":false,"terminal_reason":"completed",…}

Steps to Reproduce

1. Run claude remote-control (any spawn mode — systemd user service or interactive)
2. Connect from the desktop app or claude.ai/code web client
3. Send any message on the first turn
4. Observe the red "Remote Control disconnected" banner appears immediately, while the assistant response also arrives ~2 seconds later and renders normally

The banner appears on every session, not intermittently.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.123 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Environment: Debian 12 on Proxmox, headless SSH-only server. claude remote-control runs as a systemd --user service. Terminal: bash over SSH (no GUI).

Diagnosis: The sequence in every bridge log is:

1. App sends user message
2. App immediately sends control_request {subtype: "initialize"}
3. SDK returns control_response {subtype: "error", error: "Already initialized"} — because stream-json mode auto-initializes
4. App interprets this as a disconnect and shows the banner
5. Session proceeds normally anyway

Logs available (can attach if helpful):

• ~/.claude/remote-control.log (bridge)
• ~/.claude/remote-control-cse_<id>.log (per-session SDK debug)

Screenshot: Banner is visible alongside the rendered assistant response (session is alive while banner claims disconnect).