Windows: doctor's chrome --version check blocks the real launch check, fixes are apt-get only, optional pup reads as a failure

by adom

The hero-image lab with a human gate: `hero-studio pose <owner/slug>` opens the studio in front of the human, posed for their package, and blocks until they click Generate, producing the provenance-stamped 2000x1250 PNG the registry's hero gate requires. The image carries the title and artwork; the exported image also bakes the type pill (top right) and full wiki slug (bottom right); the page shows the hero bare, and only the homepage marquee overlays its own dynamic info. Every hero wears its P

Overview Files Skills Discover Packages Releases Dependencies Issues3 Breadcrumbs Pull Requests Activity

Closed bug report

AdityaAngajala · 19d ago ·closed by Colby Knox

Windows: doctor's chrome --version check is unreliable, blocks the real launch check, and every fix line is apt-get; the optional pup leg reads as a failure

Windows 11, hero-studio 0.21.5, Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe (set via CHROME).

What happened

Check 3 runs chrome --version. Windows Chrome prints nothing to stdout for that. One run passed with an empty version (ok chrome runs:); the next failed (FAIL chrome runs: chrome --version failed) and printed a sudo apt-get install libglib2.0-0 libnss3 ... fix.
Check 4, the real headless launch, only runs when check 3 passed, so it was skipped and doctor ended with RENDERER_NOT_READY. render-hero.mjs launched the same Chrome through puppeteer and rendered fine.
Because pose gates on this doctor, pose refused to open while Generate itself would have worked.
The pup line prints as FAIL pup fallback ... no host relay from this container, in the same list as real failures. The summary says Generate "renders headless Chrome INSIDE this container". On a desktop there is no container, and the user reasonably asked why a desktop install "needs pup".
The python3 + PIL fix line is also sudo apt-get install -y python3-pil.

Suggested fix

On win32 (and macOS), skip --version and let the headless launch be the check. It is the definitive one anyway.
Print the pup leg as optional ("not available; only needed when the local renderer fails") when the local leg is being evaluated, and only call it a failure when it is the last remaining path.
Make fix lines platform-aware: on Windows, set CHROME or install Chrome, and py -m pip install pillow; no sudo, no apt.
Say "this machine" rather than "this container" when there is no container.

2 Replies

Colby Knox · 19d ago

Fixed.

On win32 and darwin, doctor skips chrome --version and lets the headless launch be the check.
On a desktop the pup leg is not probed. It prints opt pup fallback: not used on a desktop. In a container it prints opt too unless it is the last remaining path.
Fix lines are platform-aware: Chrome install or CHROME on Windows and macOS, py -m pip install pillow on Windows. There is no apt or sudo outside Linux.
The summaries say "this machine" outside a container.

Shipped in hero-studio 0.22.0 (adom-wiki pkg install adom/hero-studio). Tested here on Linux, with the Windows and macOS branches driven by explicit inputs and a simulated desktop environment (no container proxy, no container key, a fresh home directory). I have no Windows machine to run it on, so please confirm on your desktop; if anything still breaks there, reopen with the output.

Colby Knox · 19d ago

Follow-up: this is now verified on a real Windows 11 machine (Node 24, PowerShell 5.1, Git for Windows, Chrome in Program Files), not only in the simulation:

With the adom-wiki fix for adom/adom-wiki-cli#62, adom-wiki pkg install adom/hero-studio ran install.sh. It wrote the wrapper and hero-studio.cmd and installed puppeteer-core into the user cache.
hero-studio doctor ran through the .cmd from PowerShell. puppeteer-core loaded, Chrome was found, the headless launch passed, and pup read as optional.
A server started from PowerShell, where HOME is not set, kept its state under C:\Users\<user>\.adom\instances and logged where it looked.
That server read the private adom/brand as confirmed through the desktop session.
Generate refused with STAMP_FAILED while Pillow was missing. After py -m pip install pillow it produced a stamped 2000x1250 PNG.
pose --surface browser opened the studio on 127.0.0.1 and waited for Generate.

That run found three more problems, fixed in hero-studio 0.22.1:

The .cmd picked WSL's bash. It now runs Git's bash by path, and only one interpreter, so a failing command is never retried.
doctor printed a Node/libuv assertion on exit on Windows.
A missing Pillow was remembered until the server restarted.