[BUG] Remote Control incorrectly queues msgs with no way to send/clear from the remote side (only local Esc recovers)

Preflight Checklist

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

What's Wrong?

Version: 2.1.152
Messages are "queued" indefinitely when using Remote Control from my phone (host is my Mac, terminal running claude code, nothing queued in the terminal, no processes in progress). On phone, the message posts as a greyed-out, italicized chat bubble (appears to be the default style for pending/queued posts) and sits there indefinitely, effectively locking me out from remote access until I am able to get back to my host device. It does not resolve on its own.

Observations/Exploration:
This only began happening within the past 2-3 days (around the 5/23). I have previously remotely accessed claude code in my terminal for entire trips where bringing a laptop was not feasible and have used remote-control daily since it released. I have not once seen this italicized, greyed-out version of a chat bubble in the past 2 months of using remote control.

Does not occur upon initial remote control access. Seems to occur only after a certain amount of idle time, but more research/fails need to occur to pin down a correlation.

I can clear the pending message on my phone using the X in top corner, but this provides no solution. The remote input field will still constantly show the placeholder text "Queue feedback..." – which is incorrectly being triggered by something and will repeat the same behavior for all other attempted messages once this has happened.

The only thing that clears the supposed phantom queue is physically going to the host Mac and pressing esc or sending a message in the terminal – after which the impending message from my phone finally goes through. It's as if the CLI is waiting on a local keystroke that the remote bridge never delivers.

I haven't identified the exact trigger. It's not the host mac going into sleep mode (sleep is not set up, there is only a screen power-off, as mentioned i've remote accessed for days on end while away), there are no tools running, there was nothing "mid-turn," and no permissions awaiting at the terminal (ie allow this? yes/no). It may relate to the previous turn ending in a state that needs a local keystroke, but what would trigger that, I'm unsure.

Impact:
This is new behavior in roughly the last 2-3 days. I rely on Remote Control heavily while traveling without a laptop and with this new behavior, once a message queues, I'm completely locked out until I can reach the physical machine, which defeats remote access entirely while away.

• Host: macOS, Claude Code CLI (version: 2.1.152)
• Remote: Claude Code Remote Control from phone
• Broken as of 2.1.152. Regression started ~2026-05-23 (about 3 days ago); was working fine before that, exact prior version unknown due to auto-update.

What Should Happen?

A message sent from Remote Control should process normally, or there should be some way (new feature) to clear/cancel/send from the remote side without needing physical access to the host machine in order to resolve a phantom queue.

Error Messages/Logs

Steps to Reproduce

1. Have a Claude Code session running on the host (Mac)
2. Have Remote Control already active and previously accessed via phone with no issues
3. With the session idle (no tool or response running, fair amount of time passed), send a message via remote
4. Message renders as a greyed/italic bubble and never processes; input field shows "Queue feedback..."
5. No remote action (dismiss with X, resend, refresh) gets a message through
6. Only pressing Esc in the terminal on the host clears the block, after which the message sends

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.152

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_