Remote Control: permission dialogs render only on the host terminal, hanging the session with no way to answer remotely

Summary

When driving a session over Remote Control, a permission dialog renders only in the host's terminal and never on the remote client. The session blocks indefinitely, and if you are not physically at the host there is no supported way to answer it — or even to find out that it is waiting.

This is not a dropped connection. The Remote Control channel kept working the whole time: the same client rendered a cross-session message from another session and showed the live working state. Session content reaches the remote client; permission dialogs do not.

Environment

• Claude Code 2.1.251
• Linux 5.14.0 x86_64
• Interactive session (claude -r) running inside tmux on a remote host, driven from the mobile Remote Control client
• Auto mode on
• ~/.claude/settings.json: inputNeededNotifEnabled: true, agentPushNotifEnabled: true, remoteControlAtStartup: false, and no permissions block — so every escalation depends on auto mode, and therefore on a dialog the remote user cannot see

Repro

1. On a remote host, start an interactive session inside tmux with auto mode on and Remote Control enabled.
2. Drive it from the mobile/web Remote Control client.
3. Have it trigger a prompt that auto mode always escalates. A reliable one: ask it to work in a new git worktree at a path outside .claude/worktrees/, so EnterWorktree requests a permission-root relocation.
4. The host terminal shows:

 Tool use
   Entering worktree(/…/.worktrees/<slug>)
   │ Creates an isolated worktree (via git or configured hooks) and switches the session into it
 │ permission-root relocation to "/…/.worktrees/<slug>" — a
 │ model-supplied worktree outside .claude/worktrees/
 Do you want to proceed?
 ❯ 1. Yes
   2. No
 Esc to cancel · Tab to amend

1. The Remote Control client shows nothing about this dialog and keeps rendering other session content. The session is blocked.

Expected

A prompt that blocks the session should be answerable from whatever client is driving it. At minimum it should be discoverable remotely.

Actual

• Dialog rendered on the host terminal only.
• No push notification arrived, despite inputNeededNotifEnabled and agentPushNotifEnabled both being true.
• The session stayed hung until someone with shell access to the host intervened.

Why the workaround does not generalise

The only way it got unblocked was a second Claude Code session on the same host reading the pane and answering it:

tmux capture-pane -p -t <session>:0.0     # discover what it is asking
tmux send-keys   -t <session>:0.0 1       # answer "Yes"

That requires shell access to the host — exactly what a Remote Control user does not have. With nobody at the machine, the session stays hung indefinitely. The session itself was healthy: it resumed and completed the worktree switch the instant the keystroke was delivered locally.

There also seems to be no supported way to detect a blocked interactive session from outside — claude agents / claude logs <id> cover background sessions, not an interactive one.

Related gap

/feedback is not available over Remote Control ("/feedback isn't available over Remote Control."), so a Remote Control user cannot report this from the client where it happens. That is why this is filed on GitHub instead.

Suggestions

1. Forward permission dialogs to the Remote Control client and accept the answer from there.
2. Failing that, fire the "input needed" push notification for permission dialogs — the settings for it are already enabled and nothing arrived.
3. Expose blocked-on-prompt state to something queryable from outside so a stuck session is at least detectable.