Founder live-report, 2026-09-07, current main.
Repro
- Open the plugins / extensions page.
- Find an MCP server whose auth has gone stale (the ones showing a re-auth action).
- Activate re-auth.
- The entire UI freezes. While frozen, activating Diagnose does nothing.
Expected
- Re-auth should run in the background like the rest of the MCP login paths — the machinery already exists (
mcp_login_cell + mcp_login_cancel Esc handling), so the UI must stay responsive and show progress/receipt.
- Diagnose should run
/mcp validate for that server and surface a receipt, or at minimum stay clickable and report why it can't run.
Suspect area (anchors)
- Recovery-kind mapping in the extensions view:
crates/tui/src/tui/views/extensions.rs (~1144–1206; re-auth maps to /mcp login <server> per mcp_item_action_for_stale_oauth_is_login at ~1799).
McpRecoveryKind incl. Diagnose → /mcp validate: crates/tui/src/mcp.rs:4452–4538.- Background login cell + cancel token:
crates/tui/src/tui/app.rs:2268–2273, delivery in crates/tui/src/tui/ui/event_loop.rs:1527–1538, Esc path in crates/tui/src/tui/ui/handlers.rs:568.
The freeze smells like work running synchronously on the UI thread (or input starved while a refresh holds a lock) in exactly the area #5971 touched this cycle (need-login-first + refresh receipts) — that merge is a reasonable bisect point.
Environment
- macOS, TUI, current main (post d5beab0).
Claim — 2026-09-10, in-tree agent (local main @ 10aa19570): Root found and reproduced. On a synthetic 23-server config (11 live, 10 auth-required, 2 failing) the explicit /mcp reload starves the input loop for the whole reconnect batch — 42 s observed with 9 s server delays, resuming exactly when the engine reload finishes. Two layers: handle_mcp_ui_action awaits the entire Op::ReloadMcp round-trip inline on the event loop (tui/ui/apply.rs → tui/ui/handlers.rs), and the engine's reload_mcp_pool holds the pool lock across reload_and_connect_all's connect batch. Fix in flight: run the explicit reload on the same supervised background connect pass session boot already uses (force config re-read, live progress via Event::McpSessionBoot, op replies with the interim snapshot immediately). Claimed paths: crates/tui/src/mcp.rs, crates/tui/src/core/engine.rs, crates/tui/src/tui/ui/handlers.rs, crates/tui/src/tui/ui/event_loop.rs, crates/tui/src/tui/app.rs, crates/tui/src/tui/app/init.rs, plus the tests that encode the old blocking behavior. Note: the reload freeze is a separate defect from the 2 MiB libtest stack overflow (#5988); raising stack size does not remove it.
Founder live-report, 2026-09-07, current main.
Repro
Expected
mcp_login_cell+mcp_login_cancelEsc handling), so the UI must stay responsive and show progress/receipt./mcp validatefor that server and surface a receipt, or at minimum stay clickable and report why it can't run.Suspect area (anchors)
crates/tui/src/tui/views/extensions.rs(~1144–1206; re-auth maps to/mcp login <server>permcp_item_action_for_stale_oauth_is_loginat ~1799).McpRecoveryKindincl.Diagnose→/mcp validate:crates/tui/src/mcp.rs:4452–4538.crates/tui/src/tui/app.rs:2268–2273, delivery incrates/tui/src/tui/ui/event_loop.rs:1527–1538, Esc path incrates/tui/src/tui/ui/handlers.rs:568.The freeze smells like work running synchronously on the UI thread (or input starved while a refresh holds a lock) in exactly the area #5971 touched this cycle (need-login-first + refresh receipts) — that merge is a reasonable bisect point.
Environment
Claim — 2026-09-10, in-tree agent (local
main@10aa19570): Root found and reproduced. On a synthetic 23-server config (11 live, 10 auth-required, 2 failing) the explicit/mcp reloadstarves the input loop for the whole reconnect batch — 42 s observed with 9 s server delays, resuming exactly when the engine reload finishes. Two layers:handle_mcp_ui_actionawaits the entireOp::ReloadMcpround-trip inline on the event loop (tui/ui/apply.rs→tui/ui/handlers.rs), and the engine'sreload_mcp_poolholds the pool lock acrossreload_and_connect_all's connect batch. Fix in flight: run the explicit reload on the same supervised background connect pass session boot already uses (force config re-read, live progress viaEvent::McpSessionBoot, op replies with the interim snapshot immediately). Claimed paths:crates/tui/src/mcp.rs,crates/tui/src/core/engine.rs,crates/tui/src/tui/ui/handlers.rs,crates/tui/src/tui/ui/event_loop.rs,crates/tui/src/tui/app.rs,crates/tui/src/tui/app/init.rs, plus the tests that encode the old blocking behavior. Note: the reload freeze is a separate defect from the2 MiB libteststack overflow (#5988); raising stack size does not remove it.