Remote control: permission check responses lost on client switch; stale prompts queued across turns

Environment

• Claude Code CLI (remote control mode via /remote-control)
• Switching between phone (remote client) and local terminal

Summary

Two related issues with how permission checks are handled when using /remote-control:

1. Permission responses are not persisted on the remote client until a user message is sent. If you accept/deny a permission prompt on the remote client but do not follow up with a user message, the decision is lost. Switching to the local terminal and sending a message causes the same permission checks to be re-prompted.

1. Stale permission checks from previous turns accumulate in a queue. When multiple turns generate permission checks, all of them are presented to the remote user — including checks from turns that have already advanced past the permission gate. Only the most recent turn's permission checks should be shown.

Steps to Reproduce

Issue 1: Permission responses lost on client switch

1. Start a session with /remote-control
2. On the remote client (e.g., phone), receive a permission prompt (e.g., approve/deny running a script)
3. Respond with accept or deny — but do not send a follow-up user message
4. Switch to the local terminal and send a message
5. Observed: The same permission checks are re-prompted on the remote client
6. Expected: The accept/deny response should be retained regardless of whether a user message follows

Issue 2: Stale permission checks queued across turns

1. Start a session with /remote-control
2. On the local terminal, trigger multiple turns that each generate permission checks
3. Switch to the remote client
4. Observed: Permission checks from all previous turns are queued and presented sequentially — the user must respond to each one
5. Expected: When a user message is submitted on the local side (advancing the conversation), permission checks from prior turns should be invalidated/cleared. Only permission checks from the current pending turn should be presented to the remote user.

Impact

This makes the remote control experience unreliable for permission-heavy workflows. The user ends up responding to permission checks that are no longer relevant, and legitimate responses get silently dropped.