TUI: pending permission/question prompts lost after detach + reattach, wedging the session

[Mykhol]

Description

If you detach the TUI while a permission prompt or interactive question is pending — or one is raised while you're detached — re-attaching leaves the session stuck. The agent is still blocked server-side waiting for a reply, but no prompt is shown and the input looks idle, so there's no way to answer. The only escape is forking the session, which discards the in-flight run.

The cause is that pending permission/question state is transient server memory (a Deferred the tool awaits), announced with a single permission.asked/question.asked event at ask time. The event stream doesn't replay pending state to a client that connects afterwards, and the TUI's bootstrap() hydrates everything on connect except these two stores — so a client that missed the live event never learns about the prompt.

Steps to reproduce

1. Start a run that will trigger a permission prompt (e.g. an edit/bash on ask), or one that uses the question tool.
2. Detach the TUI before answering (or detach, then let a subagent raise a prompt).
3. Re-attach to the session.
4. The session sits idle with no prompt; the agent is blocked and only forking recovers it.

Operating System

macOS

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• V2: preserve permission and question waits across server restart #36347: Covers the same root cause — permission/question waits are transient server memory and not replayed to clients that reconnect or reattach. That issue frames it as a server-restart problem, but the missing hydration on reattach is the same gap.
• TUI permission dialog can become stale: Enter confirm does nothing while /permission returns #28312: Very similar symptom — TUI shows a stale/orphaned permission dialog after an attach flow, because the client missed the lifecycle events that would have updated its state.

[Mykhol]

I've raised a PR with a focussed change to resolve this