fix(desktop): surface install failures hidden by curl-pipe exit codes

[wpfleger96]

Ubuntu Doctor reports Install failed at verify: The installer finished, but Buzz still could not use claude-code (observed: CLI missing) while the cli step shows success. The cli step is lying.

The masking

Every CLI install command is a pipe — curl -fsSL https://claude.ai/install.sh | bash (managed_agents/discovery.rs:109), … | sh for Codex (:141), … | CONFIGURE=false bash for Goose (:75). install_shell_command ran them through bash -l -c with no pipefail, so the pipeline's exit status was the right-hand side's. A curl that fails — or that isn't on the child's PATH at all — feeds bash an empty stdin, and bash with nothing to run exits 0:

$ /bin/bash -l -c 'curl -fsSL https://nonexistent.invalid/x.sh | bash'; echo $?
curl: (6) Could not resolve host: nonexistent.invalid
0
$ PATH=/tmp/empty /bin/bash -l -c 'curl -fsSL https://claude.ai/install.sh | bash'; echo $?
bash: line 1: curl: command not found
0

run_install_command records exit 0 as success: true, the adapter step then installs fine (it uses Buzz's own bundled Node, no system PATH needed), and post_install_verification correctly reports the CLI is absent. The user is handed a verify riddle instead of curl's error, which is why diagnosing this required three rounds of guessing.

Install commands now run under set -o pipefail, so the left-hand side's failure is the step's failure and InstallStepResult.stderr carries the vendor's own message. SHELLOPTS is not exported by either shell, so the piped-to vendor script still runs with its default options. The Windows PowerShell install path (install_powershell_command) bypasses this shell and is untouched.

The PATH collapse it was hiding

install_shell_command composes the child's PATH and calls cmd.env("PATH", …), which replaces rather than extends. should_use_inherited was is_windows && !had_shell_path && has_local_context, so on Unix the inherited process PATH was never appended. When login_shell_path() returns None — a login shell that exits non-zero or prints nothing, which a GUI-launched process can easily hit via ~/.profile — the child's entire PATH becomes Buzz's two managed Node dirs. There is no curl, sh, sha256sum, or tar in either, so every curl-pipe install fails, and before this PR it failed invisibly.

The is_windows requirement is dropped: the inherited PATH is the floor whenever no login-shell PATH was obtained, on every OS. Both existing suppressions are kept — a login-shell PATH present still suppresses it (no doubling), and no home/exe context still suppresses it (never manufacture a PATH from ambient state alone). Inherited entries stay last, so managed dirs keep precedence.

The other caller, build_augmented_path (runtime/path.rs:148, feeding agent spawns and CLI probes), reads correctly under the new rule for the same reason: it only gains the inherited PATH in the case where it would otherwise hand a child a PATH with no native entries. When a login-shell PATH exists — the normal case on macOS and Linux — its output is unchanged, which unix_shell_path_suppresses_inherited_fallback pins.

Scope

This fixes the reporting defect and the PATH floor. The specific environment failure on the affected Ubuntu box is still being diagnosed and is deliberately not addressed here; the point of this change is that the next attempt produces the real error instead of a verify riddle.

One interaction worth noting: install_failure_is_retryable retries any failure that carries an exit code, so a pipefail-surfaced curl failure now gets 3 attempts with backoff — correct for transient network blips, and harmless for hard failures.

desktop/scripts/check-file-sizes.mjs ratchets the agent_discovery.rs ceiling 1836 → 1895 for the added tests.

[wesbillman]

Reviewed at 9a0a424. Applying pipefail at the shared Unix/Git-Bash command boundary correctly surfaces a failing left-hand fetch while leaving native PowerShell untouched. The inherited PATH fallback is lowest precedence and only activates when no login-shell PATH was obtained; the deterministic shell and policy tests cover activation, suppression, ordering, and healthy pipelines. Current CI is fully green, including Windows Rust. No blocking findings.

[wesbillman]

Correction after a late independent review finding, validated at 9a0a424d2b21fcc798bca0bf7bf3d3bc02b62649:

The Unix inherited-PATH fallback does not necessarily survive until the install command. install_shell_command() sets the composed fallback with cmd.env("PATH", ...) at desktop/src-tauri/src/commands/agent_discovery.rs:587-608, then starts the shell with -l -c at lines 563-573. Login startup files execute after the process environment is installed and can overwrite or empty PATH before set -o pipefail; <vendor command> runs.

This is reachable through the exact fallback branch: fetch_login_shell_path_inner() (managed_agents/discovery.rs:726-741) returns None when the login shell produces no non-empty PATH line. If the profile contains export PATH=, the probe returns None; the install command receives the inherited fallback through cmd.env, starts the same login shell, and that profile empties PATH again. I reproduced that shell behavior directly with an isolated .bash_profile: HOME=<temp> PATH=/usr/bin:/bin /bin/bash -l -c ... observed an empty PATH and could not resolve curl.

Please make the fallback effective after login initialization (safely set PATH inside the command body), or avoid login initialization for the install execution when the probe failed. Add an isolated-profile regression covering a login profile that clears PATH. The existing composition tests do not exercise startup-file overwrite.

The pipefail behavior itself remains correct and current CI is green, but the PATH half of the stated fix is incomplete. This review supersedes my earlier approval.

[wpfleger96]

Reopening to force GitHub to recompute the pull_request merge ref against current main (74b63e184, post-#2974). No code change; head stays at 49c9d440f.