Windows: native installer won't add ~\.local\bin to PATH, and two `claude doctor` checks read process env instead of actual state

Environment: Windows 11 Pro 26200, desktop app Claude 1.30096.5.0 (MSIX), native CLI 2.1.233, desktop-bundled CLI 2.1.229.

Four things hit in one sitting getting the CLI usable on Windows. (1) and (4) look like straightforward fixes; (2) and (3) are context for why (1) matters.

1. The native installer knows the directory but won't add it to PATH

irm https://claude.ai/install.ps1 | iex reports:

✔ Claude Code successfully installed!
  Location: C:\Users\<user>\.local\bin\claude.exe

⚠ Setup notes:
  ● Native installation exists but C:\Users\<user>\.local\bin is not in your PATH. Add it by
    opening: System Properties → Environment Variables → Edit User PATH → New → Add the path
    above. Then restart your terminal.

This is a per-user registry write requiring no admin rights, and the installer has just written the binary to that exact directory. It should add it — or offer to — rather than hand the user a five-step GUI walkthrough after declaring success.

2. The manual PATH edit has a data-loss trap

My existing user PATH is REG_EXPAND_SZ and contains %USERPROFILE%\AppData\Local\Microsoft\WindowsApps. The obvious programmatic route:

[Environment]::SetEnvironmentVariable('Path', $old + ';' + $new, 'User')

writes REG_SZ and bakes in the expansion, silently converting a portable PATH to literal paths. The correct write is:

$k = Get-Item 'HKCU:\Environment'
$raw = $k.GetValue('Path','',[Microsoft.Win32.RegistryValueOptions]::DoNotExpandEnvironmentNames)
Set-ItemProperty -Path 'HKCU:\Environment' -Name 'Path' -Value ($raw.TrimEnd(';') + ';%USERPROFILE%\.local\bin') -Type ExpandString

Anyone scripting the fix in (1) — or asking an assistant to — can corrupt their PATH. The installer doing the write removes the hazard.

3. The desktop app's bundled CLI has no stable path on Windows

It lives at C:\Users\<user>\AppData\Roaming\Claude\claude-code\<version>\claude.exe — version number in the directory, nothing on PATH, no documented stable alias. The reason is clear enough (the app is MSIX-packaged, so its WindowsApps install directory is read-only and a self-updating binary cannot live inside it), but the setup docs describe the stable-launcher arrangement — ~/.local/bin/claude as a symlink into ~/.local/share/claude/versions/ — only for macOS and Linux. Windows users are left to discover that the desktop app and the CLI are separate installations with separate update paths.

4. Two claude doctor checks read the process environment instead of actual state

Both report problems that do not exist.

Auto-updates. Run from inside a Claude Code session, doctor prints:

Auto-updates: disabled (set by env: DISABLE_AUTOUPDATER)

DISABLE_AUTOUPDATER is injected into the session process. It is unset in both HKCU:\Environment and HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. Auto-updates are working normally. The message reads as a misconfigured install and sends users looking for a setting they never set.

PATH. The PATH warning persists after PATH has been correctly set, because the check reads the current process's environment rather than the registry. A user who has just fixed the problem, in the same session, is told they still have it. Reading HKCU:\Environment would make the check accurate.

Repro for both: set PATH correctly via the registry, then run claude doctor from an existing session — same warnings.