Windows: Doctor binary resolver ignores %PATH%, reports installed git, gh, git-lfs, goose, cursor-agent as missing
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 64/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
Hướng nghiên cứu
Bắt đầu từ phần triển khai resolve_binary của bộ phân giải binary và tái hiện Berd Doctor trên Windows bằng resolver trace trong issue. Bản sửa được hoàn tất khi việc phân giải PATH/PATHEXT tìm thấy git, gh, git-lfs, Goose và Cursor Agent, các strategy chỉ dành cho POSIX được bỏ qua trên Windows và npm được gọi thông qua npm.cmd ở đó.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Launch Berd on Windows 11.
- Install Git for Windows and GitHub CLI so they land on the machine PATH. In my case
C:\Program Files\Git\cmdandC:\Program Files\GitHub CLI\. - Confirm they resolve:
git --versionandgh --versionboth succeed in PowerShell and in Git Bash. - Run Berd Doctor.
- 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:
| Reported | Actual |
|---|---|
| Git not found | git 2.55.0.windows.5, C:\Program Files\Git\cmd |
| GitHub CLI not found | gh 2.98.0, C:\Program Files\GitHub CLI\ |
| Git LFS not installed | git-lfs 3.7.1 |
| Goose not installed | C:\Users\<user>\goose\goose.exe |
| Cursor Agent not installed | C:\Users\<user>\AppData\Local\cursor-agent\cursor-agent.cmd |
| GitHub Auth: gh not found | gh auth status shows a valid logged in account |
The resolver trace shows three strategies, and all three are Unix assumptions:
- Login shell lookup spawns
/bin/zsh -land/bin/bash -l. Neither path exists on Windows, so both fail with os error 3. - 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. - The npm strategy spawns bare
npm, which isnpm.cmdon 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.
- Ngôn ngữ chính
- TypeScript
- Star
- 1k
- Fork
- 134
- Merge trung bình
- 1 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 32
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của block/berd
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
block/berd#166 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Saving a custom provider does not set Goose's default provider/model, leaving Goose unavailableĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
block/berd#140 · 1 bình luận · 3 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
gnosis/gnosis_vpn#661 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
content-freshness: staleOwnedContent doc comments still say 'complete receipt' (follow-up to #7912)Đang mởtriage:bug-verified
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
Maintainer thường phản hồi trong vòng 1 ngày
-
fix: reject sourceStorage/packagedStorage bucket that differs from the stack default (fail loud)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Eyevinn/open-videocore#1300 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
nextjs-tracking
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
cloudflare/vinext#4390 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
kind/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
kubernetes-sigs/headlamp#8175 ·
Maintainer thường phản hồi trong vòng 2 ngày