Module bridge 

P5-4: the data shapes carried across the thread boundary between an interactive-handler call (blocked on a background/agent thread) and the render/event-loop’s main thread — deliberately just data + a reply channel, no trait impls, so crate::tui::state (the pure view-model) and crate::tui::handlers (the actual PermissionsApprovalHandler/ McpElicitationHandler implementations) can both depend on this module without a circular dependency between them.

Structs

PendingApprovalRequest

One Ask-tier request from the TOP-LEVEL agent’s own permissions gate (P5-1’s crate::permissions::PermissionsApprovalHandler::ask), waiting on Self::reply_tx for the TUI’s decision. ask blocks the calling thread on the paired Receiver until a reply arrives (or the sending end is dropped — see crate::tui::handlers::TuiApprovalHandler’s doc comment for why that’s still fail-closed).

PendingChildApproval

The child-spawn analog of PendingApprovalRequest (P5-3 §2.2 C6, closed by crate::tui::handlers::TuiChildApprovalHandler): additionally carries which BACKGROUND CHILD raised the request, since a parent may have several background children in flight at once.

PendingElicitation

One server→client elicitation/create request (crate::mcp::ElicitationRequest), waiting on Self::reply_tx for the user’s answer. Uses a tokio::sync::oneshot (not std::sync::mpsc like the two structs above) because crate::mcp::McpElicitationHandler::handle is an ASYNC trait method — it .awaits the reply rather than blocking a thread.

PendingOAuthDisplay

The OAuth device-code flow’s ONE-TIME display push (P5-2’s run_device_flow’s on_prompt callback) — informational only, no reply: the device flow polls the token endpoint regardless of whether the user has acknowledged seeing this, so there is nothing to block on.