mirror of
https://github.com/Comfy-Org/desktop.git
synced 2026-11-04 23:47:43 +00:00
[GH-ISSUE #1702] [Bug]: Windows Desktop falsely reports “Git is missing” when launched with stale Explorer PATH #513
Labels
No labels
area: desktop-app
Bounty
bug
bug-cop:answered
bug-cop:response-received
component: installer
component: preload
custom node
dependencies
Design
documentation
duplicate
enhancement
expected
frontend
good first issue
installation
Low-Priority
performance
Planned
platform: cross-platform
platform: windows
Potential Bug
Potential Bug
pull-request
question
refactor
Release
stale
User Support
V1
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Comfy-Org/desktop#513
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @paulreginaphoto on GitHub (Apr 28, 2026).
Original GitHub issue: https://github.com/Comfy-Org/desktop/issues/1702
App Version
v0.8.36
Expected Behavior
ComfyUI Desktop should detect an installed Git for Windows, or at least validate against the current Machine/User PATH on Windows before showing the maintenance page.
Actual Behavior
After a Desktop update/restart, launching from the normal Desktop/Start Menu shortcut showed:
Git was already installed and available from a fresh PowerShell:
The Desktop log showed validation failing only for Git:
Launching the same
ComfyUI.exefrom PowerShell, wheregitresolves, passed validation immediately:Steps to Reproduce
C:\Program Files\Git\cmd\git.exeexists.ComfyUI.exefrom a fresh PowerShell wheregit --versionworks.Workaround Used
A wrapper that prepends Git's standard install path before starting ComfyUI fixes the launch immediately:
After that, validation reports
"git":"OK".Suggested Fix
On Windows, Git validation should not rely solely on the inherited process PATH from Explorer. Possible approaches:
Pathfrom the registry before probinggit; orC:\Program Files\Git\cmd\git.exeandC:\Program Files\Git\bin\git.exe; orwhere.exe gitcheck with a reconstructed PATH.This would prevent a false maintenance failure when Git is installed but the Electron process inherited a stale PATH.
Debug Logs
Other
A separate Desktop loading-screen issue occurred later and was resolved locally by closing stale processes and clearing Desktop renderer cache/storage. This issue is specifically about the false Git validation failure.
┆Issue is synchronized with this Notion page by Unito
@dosubot[bot] commented on GitHub (Apr 28, 2026):
Hi @paulreginaphoto! I'm Dosu and I’m helping the desktop team.
This is a confirmed pattern — the app validates Git by running
git --helpvia shell execution [1] usingcanExecuteShellCommand(), which relies entirely on the inheritedPATH. There's no fallback to check common install paths or refreshPATHfrom the Windows registry.The same root cause is documented in issue #1196 for environment variables on Windows: apps launched from shortcuts/Start Menu inherit Explorer's cached
PATH, which can be stale after installing or updating tools like Git. The identical GUI-vs-terminal behavior was also reported on macOS, and issue #1573 tracks improving Git detection reliability more broadly.The codebase comment explicitly notes it avoids reimplementing PATH search logic, deferring to the system shell instead. The suggestions in this issue (checking common paths, refreshing PATH from registry) would be reasonable enhancements — and the team already has a precedent for explicit environment configuration as a workaround pattern from the Hugging Face endpoint fix in #1196.
To reply, just mention @dosu.
Docs are dead. Just use Dosu.