Thanks — all confirmed against the code and fixed in dda4a64 (CI green). Summary:
Reviewed autonomously by GPT-5. I reviewed this stacked PR against feat/sftp, focusing on the package split, generic authentication boundary, channel-open/global-request ordering, direct and remote forwarding lifecycle, transport adaptation, and SFTP integration changes. CI is passing, and I found no blocking correctness issues in this change.
Reviewed autonomously by GPT-5. I inspected SSH packet framing/KEX/authentication and channel flow control, SFTP request dispatch and handle lifecycle, streaming reads/writes, server error containment, and interoperability-oriented edge cases. CI is passing, and I found no blocking correctness issues in this change.
Reviewed autonomously by GPT-5. I inspected the RawTransport API contract, Node socket-to-TLS handoff (including buffered ClientHello handling), tsconnect handle replacement, worker protocol propagation, concurrency guards, and failure/close semantics. CI is passing, and I found no blocking correctness issues in this change.
Reviewed autonomously by GPT-5. I inspected FTP control serialization, passive data-channel lifecycle, transfer stream cancellation/cleanup, reply mapping, path handling, and server session state transitions. CI is passing, and I found no blocking correctness issues in this change.
Reviewed autonomously by GPT-5. I inspected SMB negotiation/authentication, signing and response verification, credit/framing behavior, VFS operation mapping, stream cleanup, and the mock/integration coverage. CI is passing, and I found no blocking correctness issues in this change.
Reviewed autonomously by GPT-5. I inspected the SharedWorker/main-thread lifecycle, configuration persistence and restart semantics, store switching, autostart behavior, and UI capability guards. CI is passing, and I found no blocking correctness issues in this change.
If the accept loop has already exited (#failSessions ran), a waiter pushed here never settles — unlike ConnectionMux.acceptOpen, there's no error-state check. The in-repo sftp caller happens to call this immediately after accept(), but any public-API user calling acceptSession() on a dead connection hangs forever. Storing the loop-exit error and rejecting here would match the mux behaviour.
A second tcpip-forward for the same bindHost:port overwrites the map entry, orphaning the previous listener and its #forwardAccept loop (never closed, even by close()). Rejecting the duplicate (return null) or closing the old listener first would avoid the leak. Related nit: RemoteForward.close()/_shutdown drop #queue without closing the queued transports, leaving those accepted channels dangling.
The comment says "unique port match" but this returns the first forward with a matching port. With two forwards on the same port on different hosts (the exact scenario the "two forwards sharing a port" test exercises via exact-match), a server that reports the bound host differently than requested (the OpenSSH behaviour this fallback exists for) can get its connections routed to the wrong forward. Making the fallback apply only when exactly one forward has that port would fail closed (reject) instead of misrouting.