Remote control: permission prompts not rendering on mobile app

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/33625
2. https://github.com/anthropics/claude-code/issues/28427
3. https://github.com/anthropics/claude-code/issues/33967

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

Additional finding: bug is specific to /config RC toggle

Tested both RC activation methods:

1. Dedicated RC session (claude remote-control --name <session>) — permission prompts render correctly on mobile
2. Interactive session with RC enabled via /config toggle — permission prompts do NOT render on mobile

This suggests the bug is in the /config RC code path specifically, not the mobile RC client in general. The dedicated claude remote-control command handles permission widget rendering correctly on mobile; the interactive-session-with-RC-enabled path does not.

Workaround: use dedicated claude remote-control --name <session> sessions instead of the /config RC toggle.

Seeing this too

Still reproducible on v2.1.86

Retested today (2026-03-28) using the /config "Enable Remote Control for all sessions" toggle set to true. Connected from mobile app.

• EnterPlanMode — not a permission prompt, so no rendering expected (transitions automatically)
• ExitPlanMode approval prompt — did not render on mobile; had to approve from desktop terminal

The dedicated claude remote-control --name <session> workaround from my earlier comment still works. Bug remains specific to the /config RC code path.

Still happening in 2.1.90 with permission prompts.

Additional repro — file write permission prompts also not shown on mobile (Windows 11, v2.1.113)

Hitting this with file write permission prompts (not just plan mode), on Windows 11 with Claude Code v2.1.113.

Scenario:

• Multiple named --agent sessions running on desktop (e.g. [W2 5min agent], [ram-safety-auditor])
• Monitoring sessions from Claude Code iOS app
• Agent requests permission to write to a sensitive file (.claude/plans/BEACH_LEDGER.md)
• Desktop terminal shows: "Claude requested permissions to edit ... which is a sensitive file. Do you want to proceed? 1. Yes 2. Yes, and always allow access to plans/ from this project 3. No"
• iOS app shows nothing — only the running asterisk indicator

What this means in practice:
Both agents were simultaneously hung waiting for permission approval. Only way to unblock them was opening Google Remote Desktop on the same iOS device and manually clicking through each terminal tab to find the pending prompts.

This confirms the issue affects all interactive permission widget types, not just EnterPlanMode/ExitPlanMode. Specifically confirmed affected:

• Sensitive file write confirmations (plans/, settings.json, etc.)
• Plan mode entry/exit (original report)

Request: Please add area:permissions label and note that this affects any interactive blocking permission widget, not just plan mode. The mobile app appears to render agent text output fine but has no mechanism to surface terminal-blocking prompts to the mobile UI.

Environment: Windows 11 Pro, Claude Code v2.1.113, Claude iOS app (latest), named --agent sessions via Remote Control.

Same issue here. When using Agent Teams (TeamCreate + tmux teammate mode), if a teammate hits a permission prompt (e.g. editing files under .claude/), the approval dialog renders only in the terminal UI — it never appears in the mobile remote app.

Reproduction:

1. Create a team with TeamCreate, spawn teammates via Agent with mode: "dontAsk"
2. Teammate attempts to Edit a file under .claude/ (which requires approval even in bypassPermissions mode)
3. On the PC terminal (tmux), the "Do you want to make this edit?" dialog appears in the leader's pane
4. On the mobile remote app, only the last conversation message is shown — no permission dialog

Root cause: The permission dialog is a terminal-only UI element that is not recorded in the JSONL conversation data. The mobile remote app renders from conversation data, so it has nothing to display.

Impact: Any workflow using Agent Teams is unusable from mobile. Teammates get stuck waiting for approval indefinitely, with no way for the user to respond from the phone.

Related: #41999, #43187

Follow-up to my v2.1.113 comment — still reproducible on v2.1.120 with Bash compound commands

Same setup (Windows 11, mobile Remote Control via iOS app), now on Claude Code v2.1.120. The bug is unchanged.

New trigger pattern: compound Bash command — sleep 3 && wmic process where "name='python.exe'" get processid,commandline

Bash(wmic:*) and Bash(wmic process:*) were both in ~/.claude/settings.local.json allow list. The compound starting with sleep (which I had not pre-allowed) didn't match either, so the prompt fired on the desktop CLI.

Mobile UI: "Running shell command" with the spinner active. No prompt. No actionable widget. Looked exactly like the agent was working.

Reality: agent had been blocked for ~30s waiting for input. Only discovered it by switching to Chrome Remote Desktop, opening the corresponding desktop window, and seeing the prompt sitting there.

This extends the affected-prompt list from my prior comment:

• Sensitive file writes (plans/, settings.json) — my v2.1.113 comment
• Plan mode — original report
• Edit under .claude/ from Agent Team teammates — @hirokimry
• General permission prompts — @SHxKM v2.1.90, @swarajban
• Bash command permission prompts (compound commands or unallowed wildcards) — this comment, v2.1.120

@hirokimry's root cause analysis (mobile renders from JSONL, permission widgets are terminal-only UI elements) explains why every prompt type is affected.

Asks (re-upping from prior comments):

1. Add area:permissions label
2. Mark priority:high — mobile Remote Control is non-functional for any workflow that produces unallowed prompts, which is almost every non-trivial workflow
3. Cross-reference: #41999, #43187, #28758 (mobile pairing entirely broken, 11+ versions), #37442, #52926

The pattern across this thread: 6+ users, 8+ months, 9+ Claude Code versions, multiple prompt types, root cause known. The mobile Remote Control surface as currently shipped only supports view-only / status-checking. Until permission widgets render on mobile, anything that pitches mobile RC as "interact with your agent from anywhere" is misleading.

Happening with me too. Hope this gets fixed soon.

The important distinction here is transcript rendering vs blocking prompt rendering.

If the mobile surface is mostly rendering conversation/JSONL state, but the permission widget only exists as terminal-local UI, the remote client has no way to know that the host is waiting on a decision. That turns a recoverable prompt into a silent spinner.

The remote-control protocol probably needs typed prompt events, not just transcript sync: prompt id, source session/pane, tool/action, available choices, current state, and whether the prompt has been resolved locally or remotely. If the prompt cannot be rendered on mobile, the app should at least show blocked_on_terminal_prompt instead of looking like the agent is still running.

Mobile "Approve plan" button sends an unqualified approval that defaults to permission-prompt mode, ignoring defaultMode: "auto" in settings.json.

Repro steps:

1. Start a Remote Control session via Claude Code mobile app (iOS)
2. Enter plan mode, review plan on mobile — only "Approve plan" and "Suggest edits" buttons shown
3. Tap "Approve plan"
4. Session returns to permission-prompt mode (each tool call requires manual confirmation), ignoring defaultMode: "auto" in settings.json

Expected: Mobile "Approve plan" should respect defaultMode setting, or offer mode selection equivalent to the desktop's option 1 ("Yes, and use auto mode") / option 2 ("Yes, manually approve edits").

Settings already configured (not working):

{
  "permissions": { "defaultMode": "auto" },
  "skipAutoPermissionPrompt": true,
  "skipDangerousModePermissionPrompt": true,
  "remoteControlAtStartup": true
}

Additional finding: Tested with --dangerously-skip-permissions + skipDangerousModePermissionPrompt: true — the bypass permission prompt still appears and still requires manual desktop confirmation. Skip flags in settings.json appear to not be applied by the Remote Control daemon at all.

Platform: Windows 11, Claude Code mobile app (iOS), Remote Control feature

Seeing the same issue on Ubuntu 24 and Claude App on Android. So this is not platform specific.

Possibly related, but I think a distinct failure mode — flagging for triage clustering rather than as a "+1".
In my case (#64983) the permission prompts do render and work normally; they only become unresponsive around usage-limit-reached, and it happens on both the mobile app and Claude Desktop (Linux, v2.1.159) — not just mobile rendering. There's also a Ctrl+C-in-terminal recovery that sometimes unblocks the session, which points more at a blocked/waiting state than a pure render gap.
Sharing in case the usage-limit trigger and the Ctrl+C recovery help separate "prompt never renders" from "prompt renders but goes unresponsive at the limit."

Adding a Linux-host data point with a precise trigger and the resulting deadlock.

Setup: a claude session on a remote Linux host, driven from the iOS app with the laptop fully closed (0 SSH connections — verified). Claude Code 2.1.173.

Trigger: the assistant called the Edit tool on a file outside the workspace (its own ~/.claude/projects/<project>/memory/<file>.md, while cwd was the project). acceptEdits did not cover that path, so a permission request was generated — and the mobile app never rendered any approval UI. The turn hung silently.

Timeline (session transcript, UTC):

13:42:57  assistant issues Edit tool call (file outside workspace)
   ...    7m17s of nothing -- tool call pending approval, no UI on mobile
13:50:14  user presses STOP -> tool call rejected -> turn unblocks

The relay itself was healthy the whole time: the STOP and a follow-up message both reached the host with the laptop offline. So the only failure was the un-surfaced permission prompt → indefinite hang.

Workaround: pre-authorising the out-of-workspace paths in settings.json (e.g. "Edit(//home/<user>/.claude/**)") avoids the prompt entirely and removes the deadlock.

Suggestion: a pending approval that the driving client cannot render should at least time out with a clear error instead of hanging the turn silently.

The useful boundary here is not just mobile rendering. It is prompt-state ownership.

A remote client can render transcript text while still missing a blocking prompt if the prompt only exists as terminal-local UI. For approval prompts, the remote-control path probably needs a first-class prompt lifecycle event rather than relying on transcript sync.

The event I would want has:

• prompt id and source session or pane;
• action or tool class and risk class;
• choices available to the current client;
• current owner surface;
• delivery state: delivered, visible, armed, resolved, superseded, expired, unavailable;
• decision source, if it was resolved somewhere else.

Then the behavior can be explicit:

1. If the current client can render the prompt, show it and bind the decision to that prompt id.
2. If another surface owns it, show blocked_on_other_surface rather than a spinner.
3. If no connected surface can render it, fail closed with prompt_unavailable.
4. If STOP or cancel rejects the pending tool, record that as the terminal outcome for the same prompt id.
5. If the prompt is resolved locally or remotely, every client sees the same terminal outcome.

The regression matrix should cover plan prompts, file edit prompts, shell/tool prompts, MCP tool prompts, and delegated child or teammate sessions. Those may look like different bugs, but the failure invariant is the same: a consequential call is waiting on a user decision that the active control surface cannot see.

That would turn "the agent is still running" into an auditable prompt lifecycle: pending, visible where, resolved by whom, or failed closed because no approval surface was available.

Confirming this still reproduces as of v2.1.17x (macOS, iOS app) — and it extends beyond plan-mode widgets to Agent Teams teammate edit-permission prompts, which is worth adding to the "Affected prompts" list.

Repro (Agent Teams):

1. Launch an interactive Agent Teams session (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude), monitoring from the iOS app.
2. Have the lead spawn teammates that make file edits (each edit triggers an edit-permission prompt).
3. From the iOS app: the session looks hung — teammates sit with no output or progress for many minutes; pings get no response.
4. On the desktop terminal: each teammate's edit-permission prompt is queued and waiting for input.
5. Approve the prompts at the terminal → every teammate immediately resumes and lands its commit.

Same root symptom as the original report — the interactive permission widget doesn't render on mobile, so the session is indistinguishable from a true hang, while regular text output renders fine. It's especially painful for Agent Teams: a multi-teammate run queues several permission prompts at once, all invisible from mobile, so there's no way to tell a "waiting for approval" state from a real teammate hang without checking the terminal.

Confirming this on Windows 11 — and it affects all interactive widgets, not just permission prompts.

Same root behaviour as reported here: when driving a CLI session from the mobile app via Remote Control, interactive widgets originating from the CLI fail to render on the mobile client. Plain text output streams fine; only the interactive widgets break. The CLI sits waiting for input that the phone can never provide, so the session is effectively dead-locked until I walk back to the PC and answer it locally. This happens on almost every session, which makes Remote Control unusable from mobile for any real work.

It is not limited to permission prompts — the same failure hits every interactive widget I've encountered:

• Permission / tool-approval prompts (this issue)
• AskUserQuestion — shows only "awaiting input" with no question text or answer UI (see #33625)
• EnterPlanMode / ExitPlanMode confirmations (already noted here)

So this looks like a single underlying gap — the mobile client has no rendering path for CLI-originated interactive widgets in general — rather than a per-widget bug. The related reports are currently split across several issues:

• #33625 — AskUserQuestion UI completely missing on mobile
• #34581 — prompts stop appearing mid-session (closed as duplicate)
• #35125 — AskUserQuestion rendered as raw tool text
• #52084 / #50463 — even when a prompt is answered remotely, the ACK doesn't propagate back and the host TUI stays stuck

Environment

• Claude Code: v2.1.177
• OS (CLI host): Windows 11 Pro
• Model: Opus 4.8
• Permission mode: bypassPermissions
• Mobile client: Honor 400, Magic OS (Android-based), latest Claude app, Remote Control
• Frequency: nearly every session

Impact: there is no remote unstick — the only recovery is local Esc at the PC, which defeats the entire purpose of Remote Control on mobile.

This problem is present for multiple months now and it doesn't seem to be that hard to fix. It makes remote control a useless functionality and it's a critical bug as it practically emerges all the time.

The newer Agent Teams and Windows reports make this look broader than mobile permission-prompt rendering.

I would separate two success conditions:

• transcript text reaches the remote client;
• blocking prompt state reaches a surface that can show or resolve it.

Right now those can diverge. Text can stream correctly while the actual prompt only exists as CLI-local UI, so the user sees activity or a spinner while the host is waiting for input.

The durable object I would want is a blocking prompt record created before renderer-specific display:

• prompt id;
• source session or pane;
• actor id, including teammate or child-agent id when delegated;
• prompt kind, such as edit approval, shell approval, plan confirmation, or user question;
• target action or tool summary;
• choices available;
• blocking scope;
• current owner surface;
• renderer support and acknowledgement per client;
• created_at and age;
• terminal state: answered, rejected, cancelled, timed out, superseded, or unavailable.

Then mobile, desktop, terminal, and teammate panes are renderers of the same prompt state. If a client cannot render a specific widget yet, it can still show that the run is blocked on an unsupported prompt instead of looking idle.

The regression cases I would pin from the newer reports:

1. teammate edit prompt appears while the lead session is controlled from mobile;
2. multiple teammate prompts are pending at once and remain distinguishable;
3. AskUserQuestion has question text and an answer path on the remote client, or a clear unsupported terminal state;
4. Windows-hosted CLI prompts do not leave the mobile client in a spinner-only state;
5. STOP or cancel writes a terminal outcome to the same prompt record;
6. reconnect rehydrates pending prompt state before showing the session as running.

That keeps this from becoming a per-widget patch list. The contract is: if a prompt can block progress, every active control surface must know whether it is pending, visible, unsupported, resolved, or failed closed.