Skip to content

fix: use VBS launcher for silent Windows gateway start (no CMD console flash) - #48373

Closed
Ados6666 wants to merge 1 commit into
NousResearch:mainfrom
Ados6666:fix/windows-gateway-silent-start
Closed

fix: use VBS launcher for silent Windows gateway start (no CMD console flash)#48373
Ados6666 wants to merge 1 commit into
NousResearch:mainfrom
Ados6666:fix/windows-gateway-silent-start

Conversation

@Ados6666

Copy link
Copy Markdown

Problem

On Windows, hermes gateway install creates a Scheduled Task that executes a .cmd batch file. Task Scheduler invariably opens a visible CMD console window when launching .cmd files — even when the script immediately launches pythonw.exe (GUI subsystem, no console) and exits. This causes a visible CMD flash every time the ONLOGON trigger fires.

The current _build_gateway_cmd_script() docstring acknowledges the goal of silent start, noting that pythonw.exe is a GUI-subsystem executable — but the parent .cmd file still creates a console window. pythonw.exe prevents the gateway process from showing a window, but does not prevent the CMD host from flashing one.

Fix

Generate a companion VBScript launcher (.vbs) alongside the existing .cmd:

  • .vbs file — runs via wscript.exe (true GUI subsystem, zero console window), sets environment variables & working directory, then spawns pythonw.exe with SW_HIDE (0)
  • .cmd file — simplified to a thin wrapper: wscript.exe //B //Nologo "%~dp0%~n0.vbs"

The scheduled task still points at the .cmd file (no change to _install_scheduled_task), preserving the existing schtasks quoting and lifecycle contracts.

Changes

hermes_cli/gateway_windows.py:

  • Add _build_gateway_vbs_script(python_path, working_dir, hermes_home, profile_arg) — generates the VBScript launcher with proper VBS string escaping
  • Simplify _build_gateway_cmd_script() — now just hands off to the VBS via wscript.exe, no longer sets env vars or runs pythonw directly
  • Update _write_task_script() — writes both .cmd and .vbs files side by side

tests/hermes_cli/test_gateway_windows.py:

  • Update test_gateway_cmd_script_delegates_to_vbs_launcher (was test_gateway_cmd_script_uses_pythonw_without_replace_or_start_churn) — verifies .cmd delegates to VBS, not pythonw directly
  • Add test_build_gateway_vbs_script_contains_env_and_hidden_run — verifies VBS sets env vars and calls Run(…, 0, False)
  • Update test_write_task_script_writes_vbs_with_hermes_home_anchor — verifies VBS is written alongside .cmd with correct working directory

Testing

All 35 tests in test_gateway_windows.py pass on Windows 10 (Python 3.11):

35 passed in 4.86s

User impact

Before After
CMD window flashes for 1-3s every login No visible window at all
Env vars set in .cmd (lost if cmd exits early) Env vars set in VBS (persists for child process)
Working dir set in .cmd Working dir set in VBS

Task Scheduler always opens a visible CMD console window when executing
.cmd files, even when the script immediately launches pythonw.exe (a
GUI-subsystem process) and exits. This causes a visible console flash
every time the ONLOGON trigger fires.

Fix: generate a companion .vbs launcher alongside the existing .cmd.
The .vbs runs through wscript.exe (GUI subsystem, no console window)
and spawns pythonw.exe with SW_HIDE (0). The .cmd is now a thin wrapper
that hands off to the VBS via 'wscript.exe //B //Nologo "%~dp0%~n0.vbs"'.

- Add _build_gateway_vbs_script() — generates the VBScript launcher
- Simplify _build_gateway_cmd_script() to delegate to the VBS
- Update _write_task_script() to write both .cmd and .vbs files
- Add/update tests for the new VBS builder and delegation pattern
@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard comp/gateway Gateway runner, session dispatch, delivery P2 Medium — degraded but workaround exists duplicate This issue or pull request already exists labels Jun 18, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Duplicate of #37037 — same mechanism: generate a companion VBScript launcher run via wscript.exe //B //Nologo (GUI subsystem, no conhost) that spawns pythonw.exe with SW_HIDE (0), replacing the .cmd -> cmd.exe -> pythonw chain in hermes_cli/gateway_windows.py. #37037 (2026-06-01) is the earlier open implementation of the identical fix. Part of the Windows blank-console-window cluster (#40696, #38387).

@alaamohanad169-ship-it

Copy link
Copy Markdown
Contributor

Note: This is NOT a duplicate of the prior closed PRs (#37037, #37037, #40696, #38387). The earlier PRs were closed because they were stale (far behind upstream main). This version has been cherry-picked onto the latest origin/main with a clean diff containing only the fix changes. No conflicts. CI green. Ready for review.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the focused Windows launcher fix. This is an automated hermes-sweeper review; the requested behavior is already implemented on current main with a stronger direct launch path.

  • 433db17c0 (fix(windows): harden gateway scheduled task (#45610)) added the console-less VBS/wscript approach.
  • hermes_cli/gateway_windows.py:625 makes the Scheduled Task execute wscript.exe //B //Nologo against the generated .vbs; it does not retain a .cmd hop.
  • hermes_cli/gateway_windows.py:440 builds the VBS launcher, including the gateway environment and hidden pythonw.exe launch.
  • tests/hermes_cli/test_gateway_windows.py:313 verifies the Scheduled Task uses the VBS launcher and excludes cmd.exe; :321 covers the hidden VBS launch itself.

The later implementation therefore satisfies the PR's no-console-flash goal and supersedes this patch.

@teknium1 teknium1 closed this Jul 14, 2026
@teknium1 teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jul 14, 2026
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/gateway Gateway runner, session dispatch, delivery duplicate This issue or pull request already exists P2 Medium — degraded but workaround exists sweeper:implemented-on-main Sweeper: behavior already present on current main type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants