claude-code - 💡(How to fix) Fix [BUG] Remote Control (mobile): session silently hangs mid-execution; only local Esc recovers it — no remote unstick mechanism

Preflight Checklist

• I have searched existing issues and this hasn't been reported as a bug yet (related: #47127 feature request for Cancel button, #28508 AskUserQuestion sync bug — both distinct from this)
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

When using Claude Code via Remote Control (claude.ai/code) from a mobile browser, the CLI session on my laptop silently enters a frozen state mid-execution and becomes permanently unresponsive to any input from the mobile client. The only recovery mechanism is pressing Esc (or any key) on the local terminal — no action from the mobile side can unstick it.

This is distinct from:

• #47127 (feature request for a Cancel button to interrupt a visibly running tool)
• #28508 (AskUserQuestion responses from mobile not propagating to CLI)

In my case there is no visible tool call in progress, no AskUserQuestion, no rate limit, no API error, no obvious trigger. The session just stops advancing after 2-4 normal message exchanges, and from the mobile client it looks like every new message is being sent but nothing ever comes back.

Reproduction pattern (consistent across multiple sessions/projects)

1. Start Claude Code on laptop (VSCode integrated terminal, Windows 11)
2. Leave the laptop at home, commute to a meeting / cafe / etc.
3. Open claude.ai/code on mobile browser, connect Remote Control to the running session
4. Send a message — works fine. Claude responds, runs tools (Bash, MCP, Write, Edit), completes
5. Send another message — works fine
6. After 2-4 successful exchanges, during what appears to be a routine turn, the session becomes unresponsive
7. The mobile client continues to accept text input and send messages, but none of them advance the CLI. No new responses, no tool calls, no errors. Messages appear to queue silently.
8. Attempting /clear, sending random text, reconnecting the Remote Control tab, refreshing the browser — none of these wake the session
9. Hours later, upon returning home, I press Esc once in the local terminal → the session immediately resumes, processes the queued messages, and works normally again

Evidence the session is not truly hung

• The CLI process stays alive and in a readable/writable state (proven by the fact that Esc locally revives it instantly)
• No API errors are logged in the .jsonl session file during the frozen period
• When I inspected the .jsonl after recovery, the last entry before the freeze was a successful tool_use completion — there was no sign of streaming stall or network failure
• This is not #25979 (API streaming stall) because that requires kill -9 to recover, while my case is fixed by a single local keystroke

Hypothesis

The CLI input-handling loop appears to enter a state where it is waiting for a local TTY keystroke (possibly as a confirmation, prompt, or UI state flag) that Remote Control's input channel does not deliver. This would explain why local Esc instantly unsticks it while remote input does not.

A possible cause: whatever UI prompt/permission/spinner state the CLI enters after certain tool calls may require a synchronous keypress from the terminal's process.stdin raw mode, which the Remote Control bridge isn't wired to send.

What Should Happen?

• Remote Control input should be fully equivalent to local TTY input — any state that local Esc/Enter can unstick should also be unstickable from mobile
• At minimum, a visible "session frozen — local intervention required" indicator in the mobile UI so users aren't silently blocked
• Ideally, automatic detection of "messages queued but not being processed" with a remote unstick mechanism

Business impact

I'm a solo founder (GT Dev Solutions, Madrid). Remote Control is a critical productivity feature for me — it's meant to let me keep working on client projects, reviewing deploys, and resolving urgent bugs while away from my laptop. In practice, with this bug, I can only rely on Remote Control for very short interactions (<5 messages) before needing to physically return home.

Yesterday (2026-04-19) I lost several hours of work while two separate sessions were frozen in this exact state. Both recovered instantly when I got home and pressed Esc. This has happened repeatedly over the past weeks — it's not an isolated incident.

Error Messages/Logs

No errors. The JSONL session file simply stops receiving new entries after the freeze point.

Steps to Reproduce

1. Windows 11, Claude Code 2.1.112+ in VSCode integrated terminal
2. Start a session with any project and MCP servers loaded (I have 18 MCPs configured globally, but the bug occurs even without any MCP calls)
3. Leave the laptop running, connect from mobile browser via claude.ai/code Remote Control
4. Interact normally — the freeze occurs non-deterministically after 2-4 exchanges, usually after (but not only after) a tool call completes
5. Any further mobile input has no effect until local keypress

Claude Model

Opus

Is this a regression?

Possibly — Remote Control is relatively new. I don't have a known-working Claude Code version for this specific feature since adoption was gradual.

Last Working Version

No response

Claude Code Version

2.1.112 (also occurred in 2.1.108 and earlier 2.1.x)

Platform

Anthropic API (Max plan)

Operating System

Windows 11 (laptop/CLI side) + Android browser (mobile side)

Terminal/Shell

VSCode integrated terminal (bash/git-bash on Windows)

Additional Information

• Happens consistently across projects (I have multiple parallel sessions for different clients)
• Does NOT correlate with any specific tool — happens after Bash, Write, Edit, MCP calls, or even plain text responses
• Does NOT correlate with rate limits (I'm on Max plan, and the freeze persists long after any rate window would reset)
• Browser refresh on mobile does not re-sync — the issue is on the CLI side, not the web client
• Related but distinct: #47127 (feature request for Cancel button), #28508 (AskUserQuestion mobile sync), #25979 (API streaming stall requiring kill -9)

Workaround: none remotely. Must physically access the laptop to press a key.