Remote Control: messages from the mobile app are silently lost, and /remote-control opens a modal that blocks the input box

Environment

• Claude Code 2.1.226 (newest at time of report)
• Ubuntu on WSL2 (Windows 11), sessions run under tmux
• 9 concurrent sessions launched as claude --remote-control <NAME>
• Driven from the Claude mobile app

Issue 1 (main) — a message sent from the phone is displayed in the session's input box but never delivered

A message typed in the mobile app appears in the target session's terminal input box, but it is
not in the editable buffer and no turn ever starts. Pressing Enter does nothing to it. The only
recovery is to retype the message from scratch.

Why this is bad: it fails silently and looks successful. The mobile app shows the message
against the session, so there is no indication anything went wrong. On 2026-08-08 I lost roughly
10 hours across 7 sessions this way — each session was idle, waiting on an answer I had already
given.

Examples captured from the terminal, each unchanged for ~120 consecutive 5-minute checks:

session-1   ❯ are the 25/35 thresholds still right
session-2   ❯ go with your recommendations on all three
session-3   ❯ commit the two rc-watchdog files
session-4   ❯ go with your recommendations
session-5   ❯ /compact
session-6   ❯ go with your recommendation on both
session-7   ❯ run /b round 1 on the built pipeline

(Session names genericized; they carry no diagnostic value. Message text is verbatim.)

Detection that works: a correctly submitted message starts a turn, so *session idle + text
sitting in the input box, unchanged over time* reliably identifies the failure.

Diagnostic detail: the text is not in the editable buffer. Typing a character replaces the
displayed text rather than appending to it. That is what makes retyping a viable workaround, and
it is also what makes the bug invisible — the box looks exactly like a normal pending message.

Occurs while connected. This is not merely a symptom of a dropped link; it happened on
sessions the mobile app reported as Connected, and on sessions with a healthy process.

What would fix it

Either deliver the message, or fail loudly. Any of these would remove the silent-loss property:

• acknowledge delivery end-to-end and surface an undelivered state in the mobile app
• re-deliver queued messages on reconnect
• render undelivered text distinctly in the TUI rather than identically to a pending message

Issue 2 — /remote-control opens a modal that blocks the input box, and there is no local reconnect

When a session shows as Disconnected in the app, the intuitive local fix is to type
/remote-control at the session. That does not reconnect anything. It opens:

   Remote Control

   This session is available in the Claude mobile app and at
   https://claude.ai/code/session_XXXXXXXX.

     Disconnect this session
     Show QR code  Scan with your phone to open this session
   ❯ Continue

   Enter to select · Esc to continue

The modal replaces the input box, so while it is open the session cannot receive anything from
the phone. A session of mine sat in this state for ~20 hours, silently swallowing every message
sent to it, because an automation typed /remote-control at it and nothing dismissed the modal.

Two requests:

1. The modal should not block inbound messages — or at minimum should auto-dismiss when a

message arrives, so an open panel cannot strand a session.

1. Provide a real local reconnect — a command or flag that actually re-establishes the link.

Today there is nothing: no keepalive or reconnect setting exists in settings.json, env vars,
or CLI flags, so a wedged session can only be recovered from the phone. That is a problem when
the phone is the thing that cannot reach it.

Documentation issue alongside this: /remote-control reads like a reconnect command, and several
community write-ups (and my own tooling) treated it as one. It is a status panel. Naming it or
documenting it accordingly would prevent this.

Impact summary

Issue 1 loses work silently and is the more serious of the two. Issue 2 turns a recoverable
disconnect into a multi-hour outage, and gives operators a footgun that looks like the fix.

Workaround I am running

rc-watchdog.sh on a 5-minute cron: detects idle-session-with-unchanged-box, retypes the message,
verifies by reading the pane back before pressing Enter, and alerts if it cannot verify. It never
types /remote-control. This is a mitigation, not a fix — the message is only recovered because
the text happens to still be visible on screen.

---

Reported from a real 2026-08-08 incident; happy to supply more detail.