fix(desktop): make the Windows terminal spawn, close, and inherit PATH (#4930)

[Glucksberg]

Summary

Buzz Term never worked on Windows, and the failure mode was an app-wide hang rather than an error. Investigating #4930 turned up three separate defects, each one hiding the next, and all three with the same origin: this subsystem was written against Unix and the Windows arms were written as mirrors of it. Two of the three mirrors are invalid, because the platform contract they mirror is inverted on Windows.

Fixing only the first gets you a terminal that hangs the app. Fixing the first two gets you a shell with no ssh, git, or node. So they are here together.

1. The spawn never happened — CreateProcessW "cmd.exe" in cwd None failed (os error 2)

env_fence::fence_env calls env_clear() and rebuilds from an allowlist. That allowlist was Unix-only (HOME, USER, LANG, …), so on Windows it cleared ComSpec and USERPROFILE and put back neither.

Those two are not cosmetic on Windows. portable-pty 0.9.0 reads ComSpec out of the builder's own env map (cmdbuilder.rs, cmdline()) and hands the result to CreateProcessW as lpApplicationName — which performs no path search. With ComSpec gone the builder falls back to the bare string "cmd.exe", CreateProcessW refuses to search for it, and you get os error 2. current_directory() reads USERPROFILE from that same map and filters it through is_dir(), which is where cwd None comes from.

shell::resolve_shell was also #[cfg(unix)] only, so there was no Windows shell resolution at all. This PR adds one, and it validates: a ComSpec candidate must be rooted (drive-qualified or UNC) and an existing file, otherwise it falls back to %SystemRoot%\System32\cmd.exe. The rootedness check is not decoration — a relative ComSpec would let a cmd.exe dropped in the working directory be launched instead.

@BoydVC's hypothesis in the issue was close: the resolution chain really does have no valid candidate on a stock Windows install. The reason is one layer deeper than $SHELL — the fence had already deleted the variable Windows uses in its place.

2. The hang itself — ConPTY inverts the EOF contract

This is the AppHangB1, and it is not the spawn failure. It only becomes reachable after #1 is fixed, which is why the issue reports a hang rather than the error above.

On Unix, the pty slave closing when the child dies is what EOFs the master, so a reader blocked in read() ends on its own. ConPTY does not do this. The conout pipe stays open after the child exits and EOFs only when ClosePseudoConsole runs — which portable-pty performs in the master's Drop (win/psuedocon.rs:73-75).

Session::shutdown's non-unix arm joined the reader while still holding the master. The reader was parked in read(), so it could never observe the stop flag, and join() blocked forever. terminal_close is a synchronous Tauri command, so that block landed on the app's main thread: the whole window stopped responding, with no panic and no stack — exactly the "Application Hang rather than a crash/panic … blocks the main thread" in the report.

The fix drops the master before the join. That is also the order ConPTY itself requires: ClosePseudoConsole blocks until pending output is consumed, so the reader has to still be draining when it runs.

This now lives in buzz-terminal::lifecycle::shutdown_closing_console, beside the Unix shutdown_draining whose ordering law it is an exception to — a reader comparing the two orders shouldn't have to look in two crates. It takes the master by value for the same reason shutdown_draining takes the reader by value: the ordering becomes a property of the signature instead of a comment. A caller cannot close the console early, because passing it in is the only way to close it at all.

3. PATH was constructed instead of inherited, which deletes the user's toolchain

path::user_shell_path builds a minimal PATH rather than inheriting Buzz's, deliberately: Buzz runs under Hermit activation, and inheriting it would hand the user Buzz's pinned cargo/node instead of their own. The Windows arm mirrored that with a constructed System32;Windows;Wbem stub.

That mirror is invalid. On Unix a minimal PATH is a starting point, because the login shell reads rc files that rebuild it — that is precisely what lets Hermit be fenced out without collateral. cmd.exe reads no rc file. The user's PATH lives in the registry (HKCU\Environment plus the machine Session Manager\Environment) and is composed into the process environment at launch, so anything omitted at spawn is omitted for the entire session with no mechanism to restore it. In practice that deleted ssh, git, node, and python from the Term.

Windows now inherits PATH and appends the guaranteed system directories, preserving inherited order (so user overrides stay ahead) and de-duplicating case-insensitively. The Hermit rationale simply does not apply: bin/activate-hermit is a POSIX shell script and is never active on Windows. The Unix arm is untouched.

The security invariant is unchanged

env_fence exists to keep BUZZ_PRIVATE_KEY, BUZZ_AUTH_TAG, and relay credentials out of spawned children, and it is an allowlist, never a denylist. That is preserved exactly. The Windows list is longer than the Unix one for a structural reason rather than a permissive one — no rc file means no second chance — and every entry on it is machine or user layout: paths, counts, architecture, things any process on the box can already read. No key, token, or credential is listed, and windows_allowlist_admits_no_secrets asserts that case-insensitively, since Windows environment names are case-insensitive and a case-only bypass would otherwise be invisible.

Related issue

Fixes #4930.

Overlap with #4829 — please read before merging either

@weiox's #4829 (open since Aug 5) touches the same two files, and the two changes interact. I found it while checking for duplicates and I'd rather flag it than have it discovered at merge time.

• Same intent, same lines: fix(desktop): make desktop terminal and sidecars Windows-clean #4829 already gates POLL_INTERVAL, Instant, and Path behind #[cfg(unix)]. My two smallest commits do exactly that. If fix(desktop): make desktop terminal and sidecars Windows-clean #4829 lands first, I'll drop them and rebase — they exist here only so this branch compiles for x86_64-pc-windows-msvc on its own.
• One genuine conflict: fix(desktop): make desktop terminal and sidecars Windows-clean #4829 also gates use std::io; and use portable_pty::Child; to unix. This PR's shutdown_closing_console is #[cfg(not(unix))] and uses both, so those two imports must stay ungated. Merging fix(desktop): make desktop terminal and sidecars Windows-clean #4829 as-is on top of this PR breaks the Windows build with unresolved io and Child.

Nothing in #4829's Justfile half overlaps with this PR. Happy to rebase onto it, fold this into it, or split the gating out entirely — whichever the maintainers prefer; I don't want to step on an older PR.

Otherwise: no other open PR touches env_fence.rs, path.rs, terminal_runtime.rs, or desktop/src/features/term, and #4930 has no linked PR.

The report's fourth symptom — "the Term panel renders permanently blank" after relaunch — is a separate surface (a failed attach renders nothing rather than an error) and is not addressed here. With this PR the attach succeeds, so the blank panel should not be reachable by this path, but the missing empty/error state is its own defect and deserves its own change.

Testing

Field-verified on the reported platform. Reproduced and fixed on Windows 11 build 26200 across six unsigned canary builds, one defect per cycle:

Build	Result
fork.1 / fork.3	CreateProcessW "cmd.exe" in cwd None failed … (os error 2)
fork.3 + spawn fix	Terminal opens — then AppHangB1, twice, no panic and no stack in WER
fork.4 + teardown fix	No more hang; 'ssh' is not recognized as an internal or external command
fork.5 / fork.6 + PATH fix	ssh, git, node resolve; open / close / switch channels / quit all healthy

Automated. 36 unit tests in buzz-terminal, of which the Windows-specific logic is 9. Those tests run on the Unix CI: the Windows behaviour is factored into pure functions with injected effects (pick_windows_shell, windows_shell_path), compiled on all platforms and driven directly, with thin #[cfg(windows)] wrappers supplying std::env::var / std::fs::metadata in production. Windows logic that only compiles on Windows is Windows logic nobody runs until a user finds it.

They cover: the no-secrets property; the full spawn contract (ComSpec, USERPROFILE, SystemRoot, PATHEXT); a valid ComSpec honoured; a missing one falling back; a relative ComSpec rejected even when the file exists; inherited PATH keeping its order and precedence; system directories not duplicated across case and trailing-separator differences; and an entirely empty environment still yielding a usable shell and PATH.

Cross-target. cargo clippy -p buzz-terminal --target x86_64-pc-windows-msvc -- -D warnings is clean. Reaching that also required cfg-gating three pre-existing unix-only items (POLL_INTERVAL, and the Instant and Path imports) that were dead code on every non-unix build — harmless under a plain build, an error the moment the crate is linted with -D warnings. Those are the two smallest commits here, and the ones #4829 already covers (see above).

Full CI. Verified green on a branch simulating this merged into main: Windows Rust (x86_64-pc-windows-msvc), Rust Lint, Desktop Core, all smoke and integration E2E shards, macOS build, Unit Tests, Web, Mobile, and both cross-compile targets. The only red was Security, which fails identically on main itself (nostr-relay-pool unmaintained advisory) and is unrelated to this change.

No screenshots: the change is a shell that spawns instead of an app that hangs, and the terminal contents are the user's own machine.