Session idle ~8h after /rename with Remote Control on: queued task notifications and prompts not processed, and the rename never persisted (Linux, 2.1.278)

Environment

• Claude Code 2.1.278 (version on every transcript record in the window), CLI on Linux (entrypoint: "cli"), interactive terminal session; later attempts on 2.1.280
• permissionMode: "auto"
• Remote Control enabled in this session: /rc on entered at 2026-09-20T21:54:18Z (bridge-session records present)
• The session had run_in_background Bash tasks in flight

What happened

1. A turn starts two run_in_background Bash tasks and ends at 21:54:36.806Z (system / turn_duration; Stop hooks finished in 322 ms and 45 ms, no errors).
2. 20 s earlier, at 21:54:18.732Z, the user had entered /rc on.
3. At 21:54:39.155Z (2.3 s after the turn ended) the user entered /rename xollama. The input showed it as queued.
4. The session then sat idle for almost 8 hours.

Expected

• /rename applies (immediately, or at the end of the turn) and persists a custom-title.
• The background-task completion notifications that arrive afterwards wake the session and start a turn, as they do elsewhere in the same transcript (e.g. an enqueue followed by its dequeue 59 ms later).

Actual

The input queue stopped draining for 7h55m:

| time (UTC) | record | content |
|---|---|---|
| 2026-09-20T21:54:36.806Z | system turn_duration | last turn ends |
| 21:54:39.155Z | (history.jsonl only) | /rename xollama |
| 21:56:17.625Z | queue-operation enqueue | task-notification (bg task 1 completed) |
| 21:56:20.158Z | queue-operation enqueue | task-notification (bg task 2 completed) |
| 2026-09-21T04:31:25.850Z | queue-operation enqueue | a prompt (not in history.jsonl; inferred to be from Remote Control) |
| 05:51:41.653Z | queue-operation dequeue ×2 | both notifications finally taken |
| 05:51:41.715Z | user | turn starts on the notifications |
| 05:54:04.587Z | queue-operation popAll | the remote prompt folded into the running turn |

• No records of any kind between 21:56:20Z and 04:31:25Z, or between 04:31:25Z and 05:51:41Z. No error, system message or hook failure was recorded. Nothing in the transcript shows what released the queue at 05:51:41Z (inferred: the user interacting with the terminal).
• Gaps: /rename → first dequeue 7h57m; notifications enqueued → dequeued 7h55m; remote prompt → consumed 1h22m.

The rename was never applied — on any of three attempts. The transcript has no custom-title record at all, for this /rename xollama or the two others (2026-09-18T11:18:40Z typed mid-turn; 2026-09-23T03:54:00Z typed right after a restart on 2.1.280). The session keeps its generated title (ai-title / agent-name). /rename also leaves no local_command record, while e.g. /model does. In other sessions on the same host /rename does write custom-title, so this looks session-state dependent (Remote Control on?).

Inferred, not verified

• The stall starts right after /rc on followed by /rename. Possibly /rename (or the Remote Control status/QR panel) left a modal / blocking local-command state open in the TUI that kept the queue from draining. That would match #94846 (Remote Control messages stall while the /rc panel is open; dismissing it unblocks), and explain why the remote prompt was not processed either.
• Either way, a local metadata command should never block queued task notifications or remote input, and it should not silently fail to persist the title.

Related

#94846, #88742, #92563, #94252, #66018, #87037