[BUG] Remote Control: sending from mobile silently fails (message disappears), reading works fine

Same bug here, and I can add a few things that may narrow it.

Windows 11, Claude Code in the VS Code extension, Max plan, phone app rather than mobile web. Started around 12 September, the same date as this report. It worked reliably before that and nothing changed on my side.

One difference worth noting. You see the message disappear with no queued state. I see what looks like the same failure presented the opposite way. My phone shows a stuck turn:

• a timer reading 1m 22s · almost done thinking…
• a stop square where the send button should be
• the composer showing Queue for after this turn…

against a desktop session that is completely idle. Three parts of the UI agree a turn is running. None of it is true. The same inbound failure rendering differently in the app and in mobile web points at the server side rather than either client.

The phone appears to believe the session is permanently mid-turn, so it queues rather than sends, and never flushes, because the turn it is waiting on does not exist.

Eliminated by test on my side, beyond what you covered:

• Two different handsets, same account, identical behaviour
• App deleted and reinstalled from cloud, logged out and back in
• Authentication: /login with claude.ai, no ANTHROPIC_API_KEY, no ANTHROPIC_AUTH_TOKEN, CLAUDE_CODE_USE_BEDROCK and CLAUDE_CODE_USE_VERTEX unset, default base URL
• Desktop left completely idle for five minutes
• A single idle session with the phone confirmed attached to it
• A brand new session
• /remote-control disconnect and re-enable, repeatedly
• A cold connect producing an entirely new pairing
• A full desktop sign-out and sign-in, replacing the stored credential outright

Outbound mirroring works perfectly throughout every one of those, on the same pairing, in the same second.

Anthropic support has been through this with me and ruled out the known changelog fix about messages sent while Claude is mid-turn, correctly, since my tests ran on fully idle sessions. Their own read was server-side routing.

Separately, and I think it matters more than the cause: a queued message that cannot be delivered should say so. Right now it renders as sent. I spent several days composing and sending instructions believing they had landed. A silent drop that looks like a success is worse than an outage.

If there is a client-side log or debug flag that captures what happens to an outbound message, name it and I will run it and post the output the same day.

One elimination that may save someone time.

v2.1.269, published 11 September — the day before this started — changed how remote sessions report turn state:

Fixed remote and headless sessions reporting "waiting for your input" while background agents were still running (set CLAUDE_CODE_BG_TASKS_REPORT_RUNNING=0 to restore the old behavior)

Given my symptom is the phone believing a turn is permanently in flight, and the dates line up exactly, that looked like the regression. It shipped its own reversal switch, so I tested it.

Set CLAUDE_CODE_BG_TASKS_REPORT_RUNNING=0, full restart, confirmed it was live in the running process rather than assuming it, reconnected, sent one message from the phone.

Still fails. So reverting that change is not the fix, and it can be crossed off.

I also read every release from 2.1.261 to 2.1.274. Several touch Remote Control — forked sessions, a context-window-usage refusal, a stale permission mode, a session-title bug, a 30-day credential expiry — and none of them describes an inbound message path. Nothing shipped so far addresses this.

Still reproducing today, day six, on the latest build. Outbound mirroring remains perfect in the same second that an inbound send is swallowed.

If anyone lands here with the same symptom, the useful detail to add is which client you are on — mobile web or the phone app — because the two present differently (silent disappearance vs a stuck turn with a timer) and that difference is the strongest argument so far that the fault is on neither client.

Resolved for me on v2.1.281.

Updating the VS Code extension from 2.1.278 to 2.1.281 fixed it. Messages from the phone arrive again, including with the desktop session fully idle, which is the exact condition that failed every time for the previous fifteen days.

I cannot tell you which change did it. 2.1.281 carries five Remote Control fixes and none of them names the inbound-message path, so this is a correlation and not a cause. Recording it anyway, because the version number is the actionable part.

For anyone landing here with the same symptom, two things worth knowing.

Check your actual installed version before anything else. Mine was on 2.1.252 while the current release was 2.1.278 — twenty-six behind, with auto-update enabled and no update ever offered in the UI. I only found it by looking at the extensions folder on disk. Going to 2.1.278 did not fix it; 2.1.281 did.

If the in-app update fails, use the command line. VS Code gave me a bare "Error while installing 'Claude Code for VS Code' extension" with no detail — almost certainly file locks, since Claude sessions were running in the extension at the time. This went through:

code --install-extension anthropic.claude-code@2.1.281 --force

then a full restart of VS Code, not just a window reload.

One diagnostic that may still be useful to whoever picks this up, since the underlying cause was never identified: while it was broken, the failed messages never reached the desktop machine in any form. I checked the session transcripts — no user event, and no queue-operation event carrying the prompt text either. That distinguishes it from #95992, where the prompt does arrive and is stored as a queue-operation but never becomes a user turn. Theirs is a message that arrives and is not rendered; this one never arrived at all.

Leaving this open rather than closing it, since the original reporter has not confirmed and no cause was ever established.