fix(windows): Resolve spawn UNKNOWN error by manually checking PROGRAMFILES path for chrome.exe (#322)

[yasirusman85]

This change addresses the 'spawn UNKNOWN' error reported in #322 on Windows systems.

The issue occurs when the Chrome executable path is not reliably resolved, potentially due to how the environment variable PROGRAMFILES is handled or inherited by the launching process.

This implementation adds a manual path check using the standard \PROGRAMFILES environment variable and common installation directories before relying on Puppeteer's default channel detection.

Fixes #322

[OrKoN]

Thanks for the PR but I am not sure how different it is from the checks done in Puppeteer? it appears this is already what Puppeteer does. If there is indeed something missing in Puppeteer, please open a PR in the Puppeteer repo.

[yasirusman85]

Hi @OrKoN, thanks for the quick review and the question!

I understand the concern regarding duplicating logic that might already be in Puppeteer.

The need for this manual check arose because of the specific behavior reported in Issue #322 (and observed by others). The users experiencing the spawn UNKNOWN error were often launching the application through custom shells or environments (like Cursor), which can sometimes sanitize or interfere with standard environment variables like PROGRAMFILES, causing Puppeteer's internal channel resolution to fail, even when Chrome is installed in a standard location.

When the executablePath is explicitly set (either by the user or by resolving it manually first, as my patch does), it bypasses the channel-based auto-discovery logic that seems to be failing in these specific Windows environments.

In summary:

If a direct path works (as resolved by my function), we use it. This avoids the failure mode encountered by users in Issue #322.

If my function fails, we fall back to Puppeteer's built-in channel detection, as before.

This approach provides a reliable workaround for the documented bug on Windows without having to modify core Puppeteer logic for a problem that may only manifest under non-standard Windows shell configurations.

Given that this is a fix for a high-priority, reproducible issue on Windows, I believe this pre-check is justified to improve reliability for users of chrome-devtools-mcp.

Let me know if this explanation helps, or if you still prefer that the fix be upstreamed to Puppeteer first

[OrKoN]

This should be addressed by #370