Remote Control sessions show "Remote Control disconnected" banner on first turn despite session succeeding (control_response error="Already initialized")

[mifraburneo]

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).

[github-actions]

Found 1 possible duplicate issue:

1. [BUG] Desktop app v2.1.108: /remote-control fails with "Remote Control initialization failed" and CLI sessions not shown in sidebar #48238

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

This is state-reporting mismatch at the remote-control session boundary.

If Remote Control shows a disconnected banner on the first turn even though the session succeeds and the underlying control response says Already initialized, then the UI is reporting session state from the wrong branch of the truth model.

Why it matters:

• users trust the first-turn banner as the top-level health signal for the remote session
• Already initialized sounds like the control plane believes the session is live, while the banner tells the user the opposite
• contradictory state at connection time makes every later action feel less trustworthy, even if the session still works

I would want clarity on:

1. whether the banner is driven by a stale initialization error path, race condition, or fallback state before the success path settles
2. whether Already initialized is being treated as an error when it should be idempotent success
3. whether the UI can delay or suppress the disconnect banner until it knows the final remote-control state for that turn

Connection surfaces need one coherent truth. If the control layer says the session is already live while the UI announces disconnection, the operator loses confidence in which state to trust.

[djones007]

Confirming this reproduces on a completely different platform — so it's not Linux/systemd specific.

Environment:

• Claude Desktop 1.5354.0
• macOS 26.4.1 (Apple Silicon)
• Claude Max subscription

Symptom: identical. Every fresh Remote Control session shows the red "Remote Control disconnected — bridged Claude Code process stopped responding mid-turn" banner on the very first message. The assistant reply arrives a couple of seconds later and the session is fully usable from that point on.

Workaround I'm using: send a throwaway . as the first message, wait for the false-disconnect banner, then send the real prompt. Annoying but reliable.

The "Already initialized" diagnosis in the OP lines up with what I see — the session is alive the whole time, the banner is just the app misreading a benign error as fatal. Option (c) — don't treat "Already initialized" as a disconnect — would fix the symptom with the smallest blast radius.

+1 for triage please.

[cyber-ayi]

+1, deterministic repro on Claude Code v2.1.126 / macOS, with the daemon running under a launchd LaunchAgent (so this is independent of how claude remote-control is started — interactive terminal, tmux, or launchd all reproduce identically).

Captured 4 (initialize request → "Already initialized" error response) pairs across 4 separate fresh sessions over ~2 minutes — every new Remote Control session reproduces it. Each error response is a direct reply to a control_request with "subtype":"initialize" from the desktop/web client to an SDK that already auto-initialized.

Sample pair:

{"request":{"subtype":"initialize"},"request_id":"ouic2q9sg2","type":"control_request","uuid":"4d7f5bf0-cf7d-443f-a657-f26e58f91119"}
{"type":"control_response","response":{"subtype":"error","error":"Already initialized","request_id":"ouic2q9sg2","pending_permission_requests":[]}}

All four pairs plus a bridge-process cold-start timeline (showing the Already initialized arrives during the same ~2s MCP-connection window when the UI shows the disconnect banner): https://gist.github.com/cyber-ayi/36bd20435add02e051aa257de5fe2045

Echoing @0xbrainkid's option — treating Already initialized as idempotent success on the UI side would be the smallest fix.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.