Skip to content

fix(windows): suppress console flashes in env probes, lazy installs, and platform.win32_ver() (salvage #67690) - #70264

Merged
teknium1 merged 2 commits into
mainfrom
salvage/67690-win32ver-lazydeps
Jul 24, 2026
Merged

fix(windows): suppress console flashes in env probes, lazy installs, and platform.win32_ver() (salvage #67690)#70264
teknium1 merged 2 commits into
mainfrom
salvage/67690-win32ver-lazydeps

Conversation

@teknium1

Copy link
Copy Markdown
Contributor

Summary

Salvages PR #67690 by @m4r13y: suppresses the remaining Windows console flashes that fire regardless of launch topology — CPython 3.11/3.12's platform.win32_ver() internally shells out to cmd /c ver with no window suppression (verified in the 3.11 stdlib; removed upstream in 3.13), plus four unflagged spawns in tools/lazy_deps.py and the env-probe runner.

Changes

  • hermes_cli/_subprocess_compat.py: new suppress_platform_ver_console() — forces the documented ValueError fallback so win32_ver() reads sys.getwindowsversion() instead of spawning; try/except-wrapped, POSIX no-op
  • hermes_cli/main.py: early startup call
  • tools/lazy_deps.py: creationflags=windows_hide_flags() on all 4 spawn sites
  • tools/env_probe.py: one-line re-fit onto the rewritten temp-file _run ([Bug]: Windows env probe can deadlock all new sessions when an orphaned pip child keeps capture pipes open #67964 contract preserved) — the PR's original hunk predated that rewrite (our follow-up commit)
  • tests/test_windows_subprocess_no_window_flags.py: +6 mocked tests (ours; the PR shipped none)

Validation

Result
5 touched/related test files 199 passed, 0 failed
suppress_platform_ver_console() on Linux no-op, platform.win32_ver() unaffected
Base drift 0 behind origin/main

Authorship preserved via cherry-pick (env_probe conflict resolved by dropping only the stale hunk from their commit); rebase-merge.

Closes #67690.

Infographic

win32ver-lazydeps

@github-actions

github-actions Bot commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

૮ >ﻌ< ა ci review

ran on 9235802

all good!

@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/cli CLI entry point, hermes_cli/, setup wizard comp/tools Tool registry, model_tools, toolsets platform/windows Native Windows-specific behavior or breakage sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows labels Jul 23, 2026
@teknium1
teknium1 force-pushed the salvage/67690-win32ver-lazydeps branch from 941468d to 914ddcf Compare July 23, 2026 23:24
m4r13y and others added 2 commits July 23, 2026 18:00
…talls, and platform.win32_ver()

From windowless processes (the pythonw gateway and the kanban workers it
spawns), three spawn paths flash visible console windows on Windows:

1. tools/env_probe.py::_run() ran its interpreter/pip probes
   (python3 / python / pip / 'python3 -m pip' / PEP-668 check, ~5 per
   worker start) without creationflags — one console flash per probe.

2. tools/lazy_deps.py had four spawn sites with the same defect:
   'uv pip install', the 'pip --version' probe, ensurepip, and the
   pip install fallback.

Both now pass creationflags=windows_hide_flags() (CREATE_NO_WINDOW on
Windows, 0 on POSIX) — stdio capture still works because the child is
hidden, not detached.

3. CPython 3.11's platform.win32_ver() unconditionally calls
   _syscmd_ver(), which runs 'cmd /c ver' via
   subprocess.check_output(shell=True) with no window suppression. Any
   dependency touching platform.uname()/version()/platform() at import
   time flashes one 'cmd' window per windowless process. New helper
   _subprocess_compat.suppress_platform_ver_console() (Windows-only,
   never raises) stubs platform._syscmd_ver so win32_ver() falls back to
   sys.getwindowsversion().platform_version — verified byte-identical
   platform.platform() output on CPython 3.11
   ('Windows-10-10.0.26100-SP0' either way). Called at the top of
   hermes_cli/main.py, right after the hermes_bootstrap guard, before
   heavyweight imports.

Verified on Windows 11 by polling EnumWindows at ~15 ms and attributing
new visible HWNDs to the suspect process tree (conhost child presence is
NOT evidence of a visible window — it appears even with
CREATE_NO_WINDOW). Tests: tests/tools/test_windows_native_support.py,
test_env_probe.py, test_lazy_deps.py, test_lazy_deps_durable_target.py —
153 passed; the 3 failures are pre-existing on upstream/main in a
Windows environment (POSIX-only assertions and NTFS chmod semantics).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…run + add no-window tests (#67690 follow-up)

Follow-up to the #67690 salvage (@m4r13y). The PR's tools/env_probe.py
hunk was written against the old capture_output=True _run(); #67964/#67999
rewrote _run to temp-file capture on July 20, so that hunk no longer
applied — but the rewritten _run still lacked creationflags and kept
flashing one console per probe (~5 per kanban worker start) from
windowless parents. Re-implement the one-line fix against the current
shape: creationflags=windows_hide_flags() on the temp-file subprocess.run,
preserving the #67964 grandchild-can't-wedge-the-pipe contract.

Also add the tests the PR didn't ship, in
tests/test_windows_subprocess_no_window_flags.py:
- env_probe._run passes CREATE_NO_WINDOW and keeps temp-file (non-PIPE)
  stdout/stderr + DEVNULL stdin
- lazy_deps uv install / pip --version probe / pip install fallback /
  ensurepip bootstrap all pass CREATE_NO_WINDOW
- suppress_platform_ver_console: POSIX no-op (platform._syscmd_ver
  untouched, win32_ver() still returns), and simulated-Windows stubbing
  (echo stub installed, idempotent, never raises)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard comp/tools Tool registry, model_tools, toolsets P2 Medium — degraded but workaround exists platform/windows Native Windows-specific behavior or breakage sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants