fix(install): persist install dir to user PATH on Windows

[PierrunoYT]

Summary

The PowerShell installer only printed a suggestion to add the install directory to PATH but never actually did it, so zero was unusable from a fresh terminal after install. This change persists the install directory to the user's PATH via [Environment]::SetEnvironmentVariable and also updates the current session's $env:PATH so zero works immediately after install without a terminal restart.

Linked issue

Fixes #406

Checklist

• The linked issue already has the issue-approved label.
• go build ./..., go vet ./..., and go test ./... pass locally.
• gofmt clean.
• Tests added/updated for the change (and run under -race where relevant).
• UI changes include screenshots or a short recording where possible.

Verification notes

• go build ./... and go vet ./... pass clean.
• go test ./... has 4 pre-existing failures unrelated to this change (env has no provider/API key configured, a Windows file-lock permission error in internal/oauth, and a TUI string-match assertion in internal/tui) — none touch install/PATH logic, and this PR does not modify any .go files.
• gofmt -l flags nearly the whole repo pre-existing due to core.autocrlf=true on Windows (CRLF vs LF); not introduced by this change and no .go files are touched here.
• No automated tests exist for scripts/install.ps1; verified manually by reproducing the bug (fresh install, PATH unchanged, zero not found) and confirming the fix persists the entry via [Environment]::SetEnvironmentVariable("PATH", ..., "User") and that zero resolves afterward.
• Not a UI change.

Summary by CodeRabbit

• Bug Fixes
  • Installer now more reliably adds the install location to PATH only when it’s missing.
  • Current terminal sessions are updated without duplicating the path entry.
  • If automatic PATH updates fail, clearer warnings guide you to update it manually.
  • You’ll now be prompted to restart your terminal after a successful user PATH update.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: b8983d9c-b945-4ca7-8653-51fbd92ec2fe

📥 Commits

Reviewing files that changed from the base of the PR and between 8d1193a and 3ad973d.

📒 Files selected for processing (1)

• scripts/install.ps1

🚧 Files skipped from review as they are similar to previous changes (1)

• scripts/install.ps1

---

Walkthrough

The install script now persists the install directory to the user PATH and also appends it to the current session PATH when missing.

Changes

PATH Persistence Fix

Layer / File(s)	Summary
Persist and update PATH in both scopes scripts/install.ps1	Adds a PATH membership helper, writes the install directory to the user PATH when absent, and separately updates the current session PATH when needed.

Estimated code review effort: 1 (Trivial) | ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes persisting the install directory to the Windows user PATH.
Linked Issues check	✅ Passed	The installer now persists the install directory to user PATH and updates the current session, matching issue #406.
Out of Scope Changes check	✅ Passed	The changes are tightly scoped to PATH persistence, helper refactoring, and related installer messaging.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

scripts/install.ps1 (1)

152-166: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Minor duplication between user-PATH and session-PATH checks.

The split/-notcontains pattern is repeated almost verbatim for the user scope and the session scope. Could be factored into a small helper (e.g. Test-PathContainsDir) for readability, though given the script's size this is optional.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@scripts/install.ps1` around lines 152 - 166, The PATH update logic in the
install script repeats the same split and -notcontains check for both the user
PATH and the session PATH. Factor that repeated pattern into a small helper such
as Test-PathContainsDir, then use it from the user-scope and session-scope
checks in the install flow to keep the behavior unchanged but improve
readability.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@scripts/install.ps1`:
- Around line 152-161: The PATH persistence step in the install flow can throw
and abort an otherwise successful install because $ErrorActionPreference is
Stop. Update the install logic around the user PATH update in install.ps1, using
the SetEnvironmentVariable call and the existing $InstallDir/$userPathEntries
check, to catch failures from [Environment]::SetEnvironmentVariable and continue
so the binary install and the later $env:PATH fallback still complete. Keep the
user-facing success message for the copy/install step separate from any PATH
persistence warning.

---

Nitpick comments:
In `@scripts/install.ps1`:
- Around line 152-166: The PATH update logic in the install script repeats the
same split and -notcontains check for both the user PATH and the session PATH.
Factor that repeated pattern into a small helper such as Test-PathContainsDir,
then use it from the user-scope and session-scope checks in the install flow to
keep the behavior unchanged but improve readability.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 01c65a1b-7f2f-43f3-b6e1-c64fc0efd734

📥 Commits

Reviewing files that changed from the base of the PR and between cdf9d83 and 8d1193a.

📒 Files selected for processing (1)

• scripts/install.ps1

[gnanam1990]

Approving.

The high-consequence axes are all handled correctly: it appends to the User PATH (doesn't clobber), is idempotent (guarded by Test-ZeroPathContainsDir), writes User scope so it needs no elevation, and won't abort the install if the PATH write fails (try/catch + the current-session fallback still runs). The non-Windows installer is untouched, and CodeRabbit's earlier change-request (guard SetEnvironmentVariable) is addressed.

One non-blocking note: [Environment]::GetEnvironmentVariable(..., 'User') returns %VAR% entries already expanded, so writing back via SetEnvironmentVariable freezes any dynamic %VAR% PATH entries to literals (REG_EXPAND_SZ → REG_SZ). It's inherent to the .NET API and standard across install scripts, so fine to ship — a registry-level write with ExpandString would preserve them if you want to harden it later.

[Vasanthdev2004]

Approve — fixes a genuinely broken Windows install path, done carefully

Worth it: yes, high value. The Windows installer copies zero.exe into %LOCALAPPDATA%\zero\bin but never puts that directory on PATH, so after the advertised irm … | iex install, zero isn't found from a fresh terminal (#406). That makes the primary Windows install path effectively broken for new users. Thanks @PierrunoYT.

The PATH manipulation is done safely:

• Idempotent — Test-ZeroPathContainsDir splits the User PATH and uses -contains, which is case-insensitive in PowerShell (C:\ZERO\BIN matches C:\zero\bin), so re-running the installer won't duplicate the entry.
• No clobber — reads the existing User PATH and appends ;$InstallDir, handling the empty case.
• Correct scope — reads and writes the "User" hive (HKCU), and reads the User PATH (not the process PATH), so it won't fold system entries into the user PATH — a common mistake this avoids.
• Resilient — try/catch with actionable warnings, updates the current session's $env:PATH so zero works immediately, and prints a restart hint.

I parse-checked the PR's script on Windows (PowerShell 5.1) — clean — and validated the helper's idempotency/case behavior locally.

Non-blocking notes for a future pass (don't hold merge): [Environment]::GetEnvironmentVariable("PATH","User") expands %VAR% tokens and writes back REG_SZ, so a User PATH containing e.g. %USERPROFILE%\bin gets flattened to a literal path (the standard .NET-installer pitfall; the path still works). And no WM_SETTINGCHANGE broadcast, so already-open shells need a restart — which the message already says.

CI note: the Go CI checks haven't run here because this is a cross-repo fork PR whose workflows are gated on maintainer approval — not because the change is script-only. A maintainer should trigger the workflows before merge. That said, the change touches only scripts/install.ps1 (no Go, and install.ps1 isn't exercised by the smoke job), so the risk of CI catching anything is low. Approving on the script review.