Summary

After a successful install on Windows via

iwr -useb https://releases.netclaw.dev/install.ps1 | iex

the script prints the following instruction to add NetClaw to PATH:

[Environment]::SetEnvironmentVariable('PATH', "C:\Users\<user>\AppData\Local\Programs\netclaw;$env:PATH", 'User')

This command corrupts the User-scope PATH because $env:PATH in PowerShell is the runtime-merged value of Machine + User PATH. Writing it back to the User scope copies every Machine entry (C:\Windows\system32, C:\Program Files\Git\cmd, C:\Program Files\dotnet\, …) into the User scope. Repeating the pattern across installs pushes PATH toward the 8191-char limit, after which cmd.exe and PowerShell 5 begin truncating it and commands stop resolving.

Severity: High — the suggested command silently mutates a persistent system setting.

Steps to reproduce

1. Fresh Windows account with a normal Machine PATH (Windows, Git, dotnet, etc.) and a normal User PATH.
2. Run the installer: iwr -useb https://releases.netclaw.dev/install.ps1 | iex
3. Run the command the installer prints verbatim.
4. Inspect scopes separately:

   [Environment]::GetEnvironmentVariable('Path','Machine')   # unchanged
   [Environment]::GetEnvironmentVariable('Path','User')      # now contains all Machine entries too

Observed impact on my machine

• User PATH grew from ~1.1 KB to 2.0 KB; 22 of 46 User entries were exact duplicates of Machine PATH entries (C:\Windows\system32, C:\Windows\System32\Wbem, C:\Program Files\dotnet\, C:\Program Files\Git\cmd, …).
• Combined effective PATH reached ~3.0 KB / 74 entries; further installs that use the same anti-pattern would push it toward the 8191-char limit.
• A related fragment in my User PATH had a double backslash where a ; should have been: C:\Users\<user>\AppData\Local\Programs\Python\Python312\\systemprofile\AppData\Local\Microsoft\WindowsApps — consistent with this same anti-pattern misfiring when the merged $env:PATH contained an unusual entry. I cannot prove NetClaw produced this specific fragment, but it is the kind of artifact this pattern produces over time.

Root cause

$env:PATH is not the User PATH. It is the process environment block, which Windows builds by concatenating Machine PATH and User PATH (plus any in-process modifications). Splicing it back into the User scope is a scope leak: User scope now contains Machine values, and on every subsequent install that uses the same pattern the User PATH grows.

Proposed fix

Replace the printed instruction (and any code path that does the same thing) with a User-scope read-modify-write:

$dir = "$env:LOCALAPPDATA\Programs\netclaw"
$userPath = [Environment]::GetEnvironmentVariable('PATH','User')
if (-not (($userPath -split ';' | ForEach-Object { $_.TrimEnd('\') }) -contains $dir.TrimEnd('\'))) {
    [Environment]::SetEnvironmentVariable(
        'PATH',
        ($dir + ';' + $userPath).TrimEnd(';'),
        'User'
    )
}

Key properties:

• Reads User scope only, never $env:PATH.
• Idempotent (skip if already present).
• Avoids trailing empty entries.

Ideally the installer should perform this step itself (behind a --add-to-path flag or interactive prompt) instead of asking the user to paste a one-liner; that also makes it easy to print a correct uninstall counterpart.

Suggested doc / UX changes

• Update README and the installer's printed output to use the User-only form above.
• Add a short note in docs: "Do not use $env:PATH when writing to the User scope — it merges Machine entries into User."
• Optional: have netclaw doctor detect User PATH entries that duplicate Machine PATH and warn the user (would also help users who have already run the buggy command).

Environment

• OS: Windows 11 Home (10.0.26200)
• Shells affected: PowerShell 5 (powershell.exe), PowerShell 7 (pwsh.exe), cmd.exe
• NetClaw install path: C:\Users\<user>\AppData\Local\Programs\netclaw\netclawd.exe
• Installer URL: https://releases.netclaw.dev/install.ps1

Happy to PR the installer change if useful.