Buzz Term hangs the entire app on Windows (0.5.5) - banner flashes, then Application Hang; blank panel after relaunch

[BoydVC]

Environment

• Buzz Desktop 0.5.5.0 (arrived via auto-update from 0.5.4 today)
• Windows 11 Pro, build 26200
• Self-hosted relay (deploy/compose bundle), Let's Encrypt TLS

What happened

Opened Buzz Term from the channel workspace for the first time:

1. The Term banner/wordmark flashed briefly, with what looked like a local shell prompt.
2. The entire app immediately stopped responding (not just the Term panel).
3. Windows Event Log recorded an Application Hang for buzz-desktop.exe 0.5.5.0 at that moment: "The program buzz-desktop.exe version 0.5.5.0 stopped interacting with Windows and was closed."
4. After relaunching, the Term panel renders permanently blank. The rest of the app works normally.

Expected

Either a working shell on Windows (ConPTY + PowerShell/cmd), or a graceful "not supported on this platform yet" state. A failed shell spawn should never hang the UI thread or take down the whole app.

Possibly relevant

PR #4347's shell resolution chain ($SHELL env var → passwd database → /bin/sh) appears to have no valid candidate on a stock Windows install — none of those exist here. The Application Hang (rather than a crash/panic) suggests the failure path blocks the main thread while the frontend waits on a PTY that never materializes.

Happy to provide more diagnostics — though note the desktop currently writes no log files on Windows, so Event Log was the only artifact available.

[Glucksberg]

Reproduced this and traced it. Opened #5425 with a fix.

Your read was right on both counts, and each one is a layer deeper than it looks.

The shell resolution chain really does have no valid candidate — but not because $SHELL is missing. resolve_shell was #[cfg(unix)]-only, so on Windows there was no resolution step at all. What actually spawns the child is ComSpec, and env_fence::fence_env had already deleted it: the fence calls env_clear() and rebuilds from an allowlist that only listed Unix variables. portable-pty reads ComSpec out of the builder's own env map and passes the result to CreateProcessW as lpApplicationName, which does no path search — so with ComSpec gone it gets the bare string "cmd.exe" and returns os error 2. USERPROFILE was cleared the same way, which is the cwd None in the error.

The hang is a real main-thread block — and it's a second, independent bug that only becomes reachable once the spawn works. ConPTY inverts the EOF contract that the teardown code assumes: on Unix the pty EOFs when the child dies, but the conout pipe stays open until ClosePseudoConsole runs, which portable-pty only does when the master is dropped. Session::shutdown joined the output reader while still holding the master, so the reader sat in read() forever and join() never returned. terminal_close is a synchronous Tauri command, so that lands on the main thread — which is why you got an Application Hang with no crash, no panic, and no stack. That matches the two AppHangB1 events exactly.

There was a third one behind those two, which only shows up once the terminal actually opens: PATH was constructed from a System32;Windows;Wbem stub rather than inherited, so ssh, git, node, and python were all missing inside Term. That's Unix-shaped reasoning too — on Unix a minimal PATH is a starting point because the login shell's rc files rebuild it, and cmd.exe has no rc file.

All three are in #5425. Field-verified on Windows 11 build 26200 across six canary builds — one defect surfaced per cycle, in the order above.

Two things your report flagged that the PR does not fix:

• The permanently blank Term panel. A failed attach renders nothing instead of an error, so the failure was invisible in the UI even when the backend had a concrete error to show. With fix(desktop): make the Windows terminal spawn, close, and inherit PATH (#4930) #5425 the attach succeeds and you shouldn't reach that state by this path, but the missing empty/error state is its own defect and deserves its own change.
• No log files on Windows. Separate gap, not touched here.

Thanks for the report — the Event Log detail and the "hang rather than crash" observation are what pointed at the teardown path rather than the spawn path.