[BUG] Remote Control: messages typed locally while a turn is running are never synced to connected devices

[AkiyonKS]

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?

When a Remote Control session is connected, a message typed in the local prompt box while Claude is mid-turn never appears on the connected device. It is not delivered late either — after the turn completes, the message is still absent from the remote view, permanently.

The session itself stays healthy throughout: no disconnect, no error, and messages sent from the remote device continue to arrive locally during the same turn. Only this one path drops silently.

What Should Happen?

The locally typed message should appear on the connected device, the same way it does when typed while Claude is idle.

Error Messages/Logs

No error is surfaced anywhere. The banner keeps showing the session as connected, the local session
accepts the message normally, and nothing is logged. The message is simply absent on the remote side.

Steps to Reproduce

1. In the VS Code extension, run /remote-control and accept the consent prompt.
2. Open the resulting claude.ai/code/session_... URL on another device (I used Chrome on Android).
3. Send a prompt that makes Claude work for a while (a long tool-using turn).
4. While that turn is still running, type a message in the local VS Code prompt box.
5. Watch the remote view during the turn, and again after the turn finishes.

Control cases, all verified in the same session:

Origin	Timing	Synced to the other side?
Remote	Claude mid-turn	Yes
Local	Claude idle	Yes
Local	Claude mid-turn	No

Because remote-origin messages do reach the local session, the session is definitely attached to the window in question — this is not a case of the remote being connected to a different window.

Claude Model

Opus

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

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

The session is hosted by the VS Code extension (the prompt box in the Claude Code panel), not a terminal — the Terminal/Shell dropdown had no option for that, so I picked WSL for the environment.

Impact

Adding an instruction mid-turn is a routine way to work, so this is easy to hit. The result is that the remote conversation silently diverges from the real one: when you check in from your phone, you see the work happening but not the instruction that caused it. That undercuts the main use case of following a long-running turn from another device.

Workarounds

• Send mid-turn instructions from the remote device instead (that direction works).
• Wait until Claude is idle before typing locally.

Related issues (checked — none cover this case)

• Remote Control: messages sent from phone/web show as sent but never arrive in the CLI session #77369, [BUG] Remote Control: Messages from mobile app not reaching PC #65861, Remote Control: messages sent from phone do not arrive in CLI (one-way communication) #42671 — messages sent from phone/web never arrive in the CLI. Opposite direction; the remote-to-local path works fine here.
• Remote Control syncs only desktop->iPhone (iPhone->desktop messages not delivered) #62513 — syncs only desktop to iPhone, iPhone to desktop broken. Again the opposite direction.
• [BUG] Remote Control: Messages get permanently stuck in queue (not just delayed) #77258 — remote-origin messages stuck in a queue. Ours are local-origin and are not queued; they simply never appear.
• [BUG] /rc remote control sync issues — one-way sync + mobile display truncation #32464 (closed as duplicate of Remote control session fails to resync after connection drop #28571) — Claude's responses not syncing back to the app, on v2.1.71. Ours is about the user's own message, on 2.1.220, and only when sent mid-turn.
• Remote control session fails to resync after connection drop #28571 — resync failure after a connection drop. No connection drop occurs here; the session stays connected and keeps working in both directions.

Note on an earlier revision of this report

The regression dropdown initially said "Yes, this worked in a previous version". That was a mistake — I have not tested an earlier version, so it is set to "I don't know".