[BUG] Remote Control: AskUserQuestion selections made on mobile not received by CLI — causes infinite wait

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28488
2. https://github.com/anthropics/claude-code/issues/28427
3. https://github.com/anthropics/claude-code/issues/28330

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of the suggested issues. Here's why:

| Suggested duplicate | What it reports | How this issue differs |
|---|---|---|
| #28488 | Permission mode toggles (plan/ask) not syncing from Desktop to CLI | Our issue is about AskUserQuestion tool responses not reaching CLI |
| #28427 | Permission prompts not rendering on iOS | Our issue: prompts render correctly on mobile, selections are submitted, but CLI never receives the response |
| #28330 | Plan mode acceptance not showing on mobile | About plan approval UI, not AskUserQuestion tool |

This issue is specifically about:

1. AskUserQuestion tool renders correctly on mobile Remote Control
2. User selects options and submits successfully (mobile UI confirms submission)
3. CLI session never receives the selection → infinite wait state
4. No error, no timeout — just permanent deadlock

The root cause appears to be a response delivery failure for interactive tool prompts (not a rendering issue), which is distinct from all three suggested duplicates.

Environment: WSL2 + tmux on Windows 11, connected via Remote Control from mobile.

Related Issues — Interactive Prompt Sync Failures

After investigating remote-control issues, I found several reports that share the same root cause pattern: mobile ↔ CLI state synchronization failure for interactive prompts.

Directly related (same symptom family)

| Issue | Symptom | Overlap with this issue |
|-------|---------|------------------------|
| #28427 | Tool permission prompts intermittently missing on iOS | Interactive prompt delivery failure (theirs is rendering; ours is response delivery) |
| #28330 | Plan mode acceptance not shown on mobile | Mobile → CLI interactive response not propagated |
| #28926 | Mobile stuck in infinite loading loop while CLI is idle | State desync — mobile believes session is active, CLI disagrees |
| #28571 | Messages silently lost after connection drop, no resync | Mobile UI shows success, CLI never receives — identical pattern to this issue |

Common pattern

All five issues (including this one) share:

1. Mobile Remote Control UI appears to work (renders prompts, accepts input, shows submission)
2. CLI session never receives the interactive response
3. No error on either side — silent failure
4. Only interactive prompts affected (text chat works fine in most cases)

This suggests a systematic issue in the bidirectional channel for tool-level interactions (AskUserQuestion, permission approvals, plan acceptance), distinct from the text message channel which works reliably.

I experienced a similar issue on v2.1.63, but with a slightly different behavior — instead of an infinite wait, the questions were silently skipped without being displayed.

The CLI output showed:

⏺ User answered Claude's questions:
  ⎿

...with no actual question content shown, and the flow just continued as if the question had been answered.

This was on the CLI side (not the mobile Remote Control interface). Disabling Remote Control resolved the issue and questions appeared correctly again.

Seems like the same underlying state synchronization problem manifesting differently.

Same issue here, latest claude code 2.1.78.
When using my mobile as remote i just see the claude symbol turning and nothing happens.
When i check my session instance on my debian pc i see claude code is waiting for the user to answer some questions.
These questions are not shown on my mobile.
When i answer the questions on the server, it continues on the remote too.

In 2.1.81 (macOS)...

It says like Using AskUserQuestion... This time, options were displayed on the CLI side, so I was able to select them, but on the remote side, it's completely frozen.

I am seeing this issue with Android 1.260330.27 and claude code 2.1.81 on macOS.

No tmux, no WSL, no docker containers, just running the regular version installed by Homebrew.

I'm getting same error with android app version 26040910 and latest claude code version 2.1.113 (latest) running on Windows 10 and Windows 11. I've always had this issue

Adding data points from a separate repro (filed as #50463, closing as duplicate of this):

• Same root cause on native Ubuntu Linux — not WSL2 and no tmux. Rules out tmux/WSL2 as the trigger that was suspected in the original report.
• Permission-approval prompts specifically confirmed — the AskUserQuestion case you confirmed is one instance of a broader pattern. When the mobile "Code" controller is used to approve a Bash tool permission prompt, the local CLI TUI wedges: the in-flight tool call renders an indefinite spinner (blinking dot), Esc / Ctrl-C / input are no-ops, and the assistant-side context receives Tool result missing due to internal error. The mobile controller continues to function — new prompts/responses flow through it — proving the backend session is alive, only the local view is desynced.
• Still reproducing on 2.1.114 (8 versions after the original report on 2.1.56).
• Recovery: kill the local claude process and relaunch with claude --resume.

Environment:

• OS: Ubuntu Linux 6.17.0-20-generic (native, no WSL/tmux)
• Claude Code CLI: 2.1.114
• Mobile: Claude Code mobile app, "Code" controller

Suggests the event routing for interactive tool prompts (permission approvals, AskUserQuestion, probably anything that blocks the CLI waiting on user input) isn't propagating the "resolved from remote" ACK back to the local TUI's render loop.

Another data point from Windows 11 Pro (10.0.26200). Same behaviour — approving a permission prompt from the mobile app dismisses the dialog in the terminal but the session hangs. The approved command never runs. No error, no retry. Have to manually intervene on the PC.

Happens consistently with Bash tool permission prompts. Filed #55833 before finding this thread.

This has been open since February with 5+ duplicates across Windows, Linux, and WSL. The bug makes remote approval completely unusable — any permission prompt approved from mobile hangs the terminal session. That's a pretty core workflow for anyone using Claude Code away from their desk.

Is there any timeline on this, or a known workaround beyond pre-approving everything?

This looks like a different failure mode from a missing mobile UI. The prompt can render, but the interactive response ACK does not make it back to the local CLI/TUI state, so the session gets stuck even though normal text messages may still work.

For an official fix, I would treat AskUserQuestion / permission approval / plan acceptance as one class of remote interactive prompt resolution, and make the local TUI observe an explicit "resolved remotely" state transition. Without that ACK path, mobile can appear successful while the live CLI process is still waiting.

For workarounds, I would not rely only on pre-approving everything. The more robust pattern is to keep an independent control path to the same live process, usually tmux/SSH, so you can still answer, interrupt, or recover the session when Remote Control's prompt channel desyncs.

I built a small open-source tool around that narrower workaround: https://github.com/Snailflyer/faryo

It keeps Claude Code/Codex/shell inside tmux as the live session layer, and uses a phone/desktop browser workbench to review output, send short input, approve/interrupt, and hand off context into the same session. It is not a fix for this Claude Remote Control bug and not a replacement for the official mobile client; it is a self-hosted escape hatch for people who want a separate control surface over the same tmux-backed process.

The fix probably wants one resolved-remotely ACK path for all interactive halts: AskUserQuestion, permission approvals, plan acceptance, etc.

Right now mobile can claim success while the CLI still thinks the gate is open. A typed receipt like prompt_resolved_remotely { prompt_id, responder, selected_option_ids, resolved_at } would make the unblock auditable and give the local TUI one state transition to observe instead of bespoke flows per prompt type.

Agree. A typed receipt is the shape I would expect too.

The important part is that the local TUI transitions from "waiting for local user input" to "resolved remotely" through an explicit prompt id, not by inferring success from the mobile controller path. That also gives maintainers something auditable: if the ACK is missing or rejected, the UI can expose a recoverable desync state instead of leaving the user with an indefinite spinner.

Happening on win 11. Android app. Claude cli and desktop version appear to both experience it. Latest versions as of today's date

1. Environment:

• Client: Claude Code VS Code extension v2.1.145 (not the CLI, not WSL, native Windows)
• OS: Windows 10 Home
• Phone: Android, Samsung A56, latest Claude mobile app, signed into the same account as the desktop
• Single isolated Remote Control session (all other Claude Code sessions closed, /remote-control restarted for a fresh bridge)

1. Reproduction:

• In the VS Code extension chat, ask Claude to run any tool that triggers a permission prompt (e.g. a Bash command not in the allowlist).
• Permission request appears in the desktop chat and correctly shows up in the Code tab of the Android app.
• Tap Approve on the phone.
• Phone UI indicates the approval was submitted successfully.
• Desktop session stays frozen waiting for input indefinitely, the approval never arrives.

1. Direction:

• Desktop → phone: works (requests reliably arrive on the phone).
• Phone → desktop: broken (approvals / responses never get back).

1. Already ruled out (none helped):

• Multiple sessions / stale session conflict (isolated to a single session, restarted /remote-control)
• Phone-side notification settings (all OS notification channels allowed at Urgent importance, background data on, Claude app set to Unrestricted battery)
• Reboot of the phone, full kill/relaunch of the Claude app

Got the same issue since month.

I do not get why they do not fix it.

For me that is a curial part to have not to sit in front of my PC or using a Cloud session

Reproduced:

• Wsl2 (Ubuntu 24.04) (win10)
• CLI 2.1.107
• remote control activated
• accepted commands from Android app 26060430

Suggested Fable5 Prompt for dev team:
"Pls fix remote control, thx"

If Claude asks you something mid-session (mobile, desktop, or web) and you're not there to answer immediately, it just keeps re-asking. So you end up with the same question stacked three times, with no indication of which one is live. Only the last one registers, so unless it's a simple multiple-choice tap, you get to retype your answer over and over. I've also watched Claude shrug and go "since you're not answering, I'll just pick one" entirely unprompted.

This reproduces in basically every session I run, and has for months. How does this keep happening?
Does nobody at Anthropic actually use their own product?

If Claude asks you something mid-session (mobile, desktop, or web) and you're not there to answer immediately, it just keeps re-asking. So you end up with the same question stacked three times, with no indication of which one is live. Only the last one registers, so unless it's a simple multiple-choice tap, you get to retype your answer over and over. I've also watched Claude shrug and go "since you're not answering, I'll just pick one" entirely unprompted. This reproduces in basically every session I run, and has for months. How does this keep happening? Does nobody at Anthropic actually use their own product?

That is something I asked myself too. At least not these features or only in auto mode