hermes - 💡(How to fix) Fix Windows Gateway update/restart path relaunches console python.exe and shows conhost window

Bug description

On Windows, the Gateway can re-open a visible black console window after an update/manual restart path even when the scheduled task/service installation uses the hidden pythonw.exe launcher.

The installed scheduled-task script remains windowless, but the detached restart/takeover path builds its own argv and currently falls back to the venv console interpreter (python.exe -m hermes_cli.main gateway run --replace). That process owns a conhost.exe, so users see a black console window after an update or restart.

Reproduction observed

1. Run Hermes Gateway on Windows via the normal hidden scheduled-task install.
2. Trigger an update/manual Gateway restart that relaunches the Gateway with --replace.
3. Inspect processes or the desktop.

Observed process shape:

python.exe -m hermes_cli.main gateway run --replace
└─ conhost.exe

The scheduled-task command itself was still correct and hidden:

start "" /B "...\\venv\\Scripts\\pythonw.exe" -m hermes_cli.main gateway run

So the regression is in the internal detached restart/takeover path, not in the scheduled task script.

Expected behavior

All Windows background Gateway launch paths should use the same windowless launcher resolution:

pythonw.exe -m hermes_cli.main gateway run [--replace]

No visible console/conhost window should be created.

Root cause

launch_detached_profile_gateway_restart() used _gateway_run_args_for_profile() to construct only argv. On Windows, that helper returned the generic get_python_path() result, which points at the venv console interpreter/launcher in uv-installed environments. That bypassed the Windows-specific _build_gateway_argv() logic used by service start/install, including:

• resolving the base pythonw.exe instead of the uv venv console launcher,
• setting stable Gateway working directory/HERMES_HOME,
• preserving the needed PYTHONPATH, VIRTUAL_ENV, and detached env overlay.

Suggested fix

Make the manual/update restart argv builder return (argv, cwd, env_overlay) and, on Windows, delegate to hermes_cli.gateway_windows._build_gateway_argv(..., replace=True). The watcher should then pass through cwd/env_overlay when it starts the replacement process.

High-level patch shape:

• extend _build_gateway_argv() to accept optional profile_arg, hermes_home, and replace parameters;
• make _gateway_run_args_for_profile(profile) return (argv, cwd, env_overlay);
• on Windows, call _build_gateway_argv(profile_arg=..., hermes_home=get_profile_dir(profile), replace=True);
• update the watcher subprocess to JSON-pass the env overlay and apply cwd/env to subprocess.Popen();
• preserve POSIX behavior as ([get_python_path(), "-m", "hermes_cli.main", ...], None, {}).

Verification

A local Windows regression test was added to cover the manual --replace restart path using pythonw.exe, plus existing Windows Gateway tests.

Command run successfully on Windows:

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 uv run --with pytest --with pyyaml --with psutil \
  python -m pytest tests/hermes_cli/test_gateway_windows.py -q --tb=short -o addopts=''

Result:

35 passed in 4.53s

Also verified live Gateway after applying the local fix:

✓ Scheduled Task registered: Hermes_Gateway
✓ Gateway process running (PID: 43592)

pythonw.exe -m hermes_cli.main gateway run --replace

Logs showed both platforms reconnecting:

✓ weixin connected
✓ qqbot connected
QQBot Ready

Environment

• OS: Windows 10
• Install style: Hermes local git/uv install
• Repo: NousResearch/hermes-agent