Windows: Doctor binary resolver ignores %PATH%, reports installed git, gh, git-lfs, goose, cursor-agent as missing

Start at the binary resolver's resolve_binary implementation and reproduce Berd Doctor on Windows using the resolver trace in the issue. The fix is done when PATH/PATHEXT resolution finds git, gh, git-lfs, Goose, and Cursor Agent, POSIX-only strategies are skipped on Windows, and npm is invoked through npm.cmd there.

Before filing

• I searched open and closed issues for duplicates.
• I reproduced this on the latest release.
• This is one bug, not several bundled together.

Closest existing issue

#108 (Windows extended-length path prefix in the terminal panel). Same platform, different code path. Not a duplicate.

What's broken

On Windows, the Berd Doctor binary resolver never consults %PATH% or PATHEXT. It reports git, GitHub CLI, git-lfs, Goose, and Cursor Agent as missing while all five are installed and resolvable on the system PATH.

Steps to reproduce

1. Launch Berd on Windows 11.
2. Install Git for Windows and GitHub CLI so they land on the machine PATH. In my case C:\Program Files\Git\cmd and C:\Program Files\GitHub CLI\.
3. Confirm they resolve: git --version and gh --version both succeed in PowerShell and in Git Bash.
4. Run Berd Doctor.
5. Read the Tools and Agents sections.

No chat session or agent turn is involved.

What you expected to happen

Berd Doctor finds any binary that Windows itself can resolve. Git, GitHub CLI, and git-lfs pass.

What actually happened

Git and GitHub CLI report FAIL. Git LFS, Goose, and Cursor Agent report WARN as not installed. GitHub Auth reports FAIL because it depends on the failed gh lookup.

All of them are present:

The resolver trace shows three strategies, and all three are Unix assumptions:

1. Login shell lookup spawns /bin/zsh -l and /bin/bash -l. Neither path exists on Windows, so both fail with os error 3.
2. Common install paths are Unix prefixes only, and they are joined with a mixed separator, for example /usr/local/bin\git. These can never match on Windows.
3. The npm strategy spawns bare npm, which is npm.cmd on Windows, so it fails with "program not found".

No strategy performs a plain %PATH% lookup with PATHEXT extension probing, which is where every one of these binaries actually lives.

Note that the Claude Code check passes. It resolves through Berd's own managed packages\bin directory rather than through resolve_binary, which is consistent with the resolver being the faulty component.

How often does it happen?

Every time. Reliably reproducible.

Berd version

0.6.2

Operating system

Windows

Model and provider

n/a

Relevant log output

berd.log records nothing for the doctor run. The doctor's own resolver trace is the relevant output. Paths left intact because they are the subject of the bug.

# Check: Git - verify git is installed and reachable
not found via resolve_binary
resolve 'git':
  strategy 1 - login shell path lookup:
    /bin/zsh -l -c 'whence -p -- 'git'' => error: failed to spawn `/bin/zsh -l -c 'whence -p -- 'git''`: The system cannot find the path specified. (os error 3)
    /bin/bash -l -c 'type -P -- 'git'' => error: failed to spawn `/bin/bash -l -c 'type -P -- 'git''`: The system cannot find the path specified. (os error 3)
  strategy 2 - common install paths:
    /opt/homebrew/bin\git => not found
    /usr/local/bin\git => not found
    /usr/bin\git => not found
    /home/linuxbrew/.linuxbrew/bin\git => not found
  strategy 3 - npm global install dirs:
    C:\Users\<user>\.npm-global/bin\git => not found
    C:\Users\<user>\.npm/bin\git => not found
    npm prefix -g => error: failed to spawn `npm prefix -g`: program not found
  not found in any location

The gh, git-lfs, goose, and cursor-agent traces are identical in shape.

Suggested fix

Add a Windows strategy that resolves through %PATH% with PATHEXT, and skip the POSIX shell and Unix prefix strategies on Windows. Spawning npm should also use npm.cmd on Windows.