[BUG] Remote Control (mobile): session silently hangs mid-execution; only local Esc recovers it — no remote unstick mechanism

[GustavoVzla]

Preflight Checklist

• I have searched existing issues and this hasn't been reported as a bug yet (related: Feature request: Cancel/interrupt button for Remote Control (mobile) #47127 feature request for Cancel button, [BUG] Remote Control: AskUserQuestion selections made on mobile not received by CLI — causes infinite wait #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:

• Feature request: Cancel/interrupt button for Remote Control (mobile) #47127 (feature request for a Cancel button to interrupt a visibly running tool)
• [BUG] Remote Control: AskUserQuestion selections made on mobile not received by CLI — causes infinite wait #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 [BUG] Claude Code hangs indefinitely when API streaming connection stalls (no read timeout) #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: Feature request: Cancel/interrupt button for Remote Control (mobile) #47127 (feature request for Cancel button), [BUG] Remote Control: AskUserQuestion selections made on mobile not received by CLI — causes infinite wait #28508 (AskUserQuestion mobile sync), [BUG] Claude Code hangs indefinitely when API streaming connection stalls (no read timeout) #25979 (API streaming stall requiring kill -9)

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

[InsaneTrilobyte]

Am also having this exact issue with the mobile app on android I've tried writing skills to prevent hangs but even with timeout and --kill-after=5 on every single command it still hangs and its only when remote control is active

[alex-rosenberg35]

I keep running into this or a similar issue. Whenever a tool or subprocess gets stuck for any reason, the entire session becomes blocked with no way to rescue it remotely. This is a massive blocker for effective use of remote-control.

[ntabor82]

I am also experiencing this issue, with increasing frequency. This morning, after it happened, I restarted the machine and restarted code with remote, and it froze again after only 15 min. I have noticed that the app has a bug, where on screen rotate or screen on/off, it will clear pop-ups on the android side (usually waiting for input), and I wonder if this is the cause.

[davidwyly]

Experiencing this issue as well

[GustavoVzla]

Workaround validated today: Telegram plugin as an alternate input channel that bypasses the freeze

Reporting back with a concrete workaround that confirms the underlying hypothesis (Remote Control's input bridge is not equivalent to local TTY) and gives users an interim recovery mechanism without physical access to the laptop. This does not fix the bug — the freeze still happens — but it provides a "remote Esc" via a different code path.

Setup

Add the official Telegram plugin to the same Claude Code session you use for Remote Control:

claude --channels plugin:telegram@claude-plugins-official

(Setup details in the plugin docs; I documented zombie-process gotchas in #36964.)

Why it bypasses the freeze

The Telegram plugin delivers user messages into the session via a different ingress than Remote Control. From what I observed today:

• Remote Control's input goes through the cloud bridge → CLI's RC adapter → some internal queue. The freeze appears to be in this queue / RC adapter layer.
• The Telegram plugin spawns a Bun MCP server that polls Telegram and delivers messages as user-prompt-submit-hook events directly into the session's event loop — same code path local TTY input ultimately reaches.
• Sending any text from Telegram to the bot during a frozen state wakes the session in the same way that local Esc does: the queued Remote Control messages flush, the session resumes, and subsequent Remote Control input works again until the next freeze.

Test today (2026-04-29)

After 4 paired pings over a 36-min window (one of them after a 15-min idle gap), the Telegram channel stayed live and responsive while the same Claude process was also serving Remote Control. The freeze pattern I described in the issue did not manifest during the Telegram test — but more importantly, when freezes have happened in the past (without the plugin loaded), I had no way to recover remotely; with the plugin loaded, a single Telegram message from my phone would have given me the same recovery effect as local Esc.

Why this is a workaround, not a fix

The root cause described in this issue is unchanged:

1. The freeze still happens with the plugin loaded — Telegram only gives you a way to unstick it remotely.
2. Users without the plugin (or on plugin-incompatible setups) remain blocked.
3. Adding a Telegram plugin to every Remote Control session adds setup complexity, requires a Telegram bot per session (single-consumer getUpdates limitation), and introduces a token to manage.
4. The behavioral difference between RC input and TTY/plugin input is itself the bug — Remote Control should be input-equivalent to local TTY, full stop. Please don't close this issue as workaround-resolved.

What this tells us about the underlying bug

The fact that any alternate input channel (Telegram plugin → MCP user-prompt-hook) unsticks the session reinforces the hypothesis from the original report: Remote Control's input is being dropped or queued behind a state machine that local TTY input bypasses. The freeze is not a process hang — it's an input-routing bug specific to the RC adapter.

This narrows the fix target: the RC input path needs to be verified equivalent to process.stdin raw mode in all the states where the CLI's input handler may be waiting (permission prompts, post-tool spinners, AskUserQuestion, etc.). Whatever's blocking RC input but not TTY/plugin input is the bug.

Recommendation

Until a real fix lands, document this as an interim workaround in the Remote Control docs:

If your Remote Control session freezes and you cannot return to the laptop, having the Telegram plugin loaded with --channels provides an alternate input channel that can unstick frozen sessions. This is a workaround, not a fix — the underlying input-routing bug is tracked in #51267.

Happy to provide more reproduction data or test instrumented builds if useful.