SSH password prompts become stale and appear stacked after sleep/wake

SSH password prompts become stale and appear stacked after sleep/wake

What happened

I left T3 Code Nightly connected to an SSH environment, closed my MacBook overnight, and woke it the next morning. T3 Code showed an expired SSH Password Required dialog with a disabled password field and Continue button. Clicking Dismiss repeatedly appeared to do nothing because another identical expired prompt immediately replaced it. Restarting the app cleared the prompts.

Diagnosis

The SSH password prompt and connection supervisor use conflicting lifetimes:

• The desktop main process creates password requests with a three-minute timeout.
• The connection supervisor currently applies its generic 15-second establishment timeout to the entire SSH flow, including interactive password preparation.
• When that outer timeout or a wake-triggered reconnect interrupts preparation, the main-process request is removed, but the renderer receives no corresponding settlement event.
• Retries create new requests, while the renderer appends every request to an unbounded FIFO. Dismiss removes only the visible head, so queued stale prompts appear to be an undismissable stack.

This also means a prompt can remain visibly valid after its main-process request has already been interrupted, causing a submitted password to be rejected as expired/no longer pending.

Steps to reproduce

1. Add an SSH environment whose server requires password authentication.
2. Begin connecting and leave the password prompt unanswered.
3. Trigger a connection replacement while the prompt is open, such as sleeping and waking the Mac or otherwise causing an application-active reconnect.
4. Allow reconnect attempts and prompts to expire.
5. Click Dismiss on the expired prompt.

The next queued expired prompt can immediately replace it, making Dismiss appear ineffective.

Version

Observed on the August 19/20 0.0.34 nightlies. The affected code is unchanged through v0.0.34-nightly.20260820.1142 (beab6886f4).

Environment

macOS 26.5.2 (25F84), Apple silicon; T3 Code Nightly desktop.

Evidence

2026-08-19 20:35:44 -0400: clamshell sleep
2026-08-20 10:42:57 -0400: full wake
2026-08-20 10:44:21 -0400: screenshot of expired prompt (~84 seconds after wake)

Source tracing shows the supervisor's 15-second establishment race wrapping SSH preparation, while DesktopSshPasswordPrompts advertises and waits for a three-minute lifetime. Interrupted requests are cleaned from the main-process pending map without a renderer notification; the renderer only receives new-request events and appends them to its queue.

Related issues

PR #7495 improves SSH dialog close/focus transitions, but it does not reconcile interrupted request lifecycles or the 15-second/three-minute timeout mismatch.

Fix applied or workaround

Restarting T3 Code clears the stale renderer queue. I have a focused local patch that adds keyed request-settlement notifications, removes settled IDs from anywhere in the renderer queue, and starts the generic transport timeout after interactive SSH preparation. Focused tests and an isolated Electron/SSH fixture pass.

Start with DesktopSshPasswordPrompts, the connection supervisor, and the renderer prompt queue described in the issue; trace how interrupted requests are removed and whether settlement reaches the renderer. Run the focused tests and isolated Electron/SSH fixture mentioned in the report, and consider the work done when interrupted or expired prompts leave no stale queued entries and the transport timeout no longer covers interactive preparation.