fix(ssh): hide Windows console subprocesses

[lord-roachington]

Summary

• Hide SSH/SCP subprocess windows on Windows by reusing the existing windows_hide_flags() helper.
• Apply the hidden-console kwargs to SSH connection probes, sync/delete calls, tar-over-SSH pipes, command execution, and cleanup.
• Add focused regression coverage for the hidden-console kwargs and _run_bash() forwarding behavior.

Root cause

When the Windows desktop gateway runs as pythonw.exe, SSH backend status/output polling launches console-mode ssh.exe children without CREATE_NO_WINDOW. Windows Terminal is configured as the default console host, so each short-lived SSH probe creates a visible OpenConsole.exe window. A background gateway loop polling /tmp/hermes_bg_proc_*.log and .pid therefore produced hundreds of orphaned console windows.

Tests

• uv run --extra dev python -m pytest tests\\tools\\test_ssh_environment.py -q
• Result: 16 passed, 11 skipped

Deployment status

• Immediate live mitigation performed locally: stopped the runaway pythonw.exe -m hermes_cli.main gateway run process and cleaned up orphaned OpenConsole.exe/conhost.exe windows.
• Live editable checkout at C:\\Users\\Benjamin\\AppData\\Local\\hermes\\hermes-agent has been synced with the production-code portion of this fix.
• Gateway restarted from the patched live checkout as PID 69476; status reports Telegram and Signal connected.
• Post-restart watch: no new OpenConsole.exe and no current ssh.exe processes.

[liuhao1024]

Verification: Reviewed the diff — clean Windows-specific security improvement for SSH subprocess visibility.

Checked:

• _hidden_console_kwargs() correctly returns {"creationflags": 0x08000000} on Windows and {} elsewhere via windows_hide_flags()
• Applied consistently across all 14 subprocess.run/Popen calls in the SSH environment (connection establishment, remote home detection, directory creation, SCP upload/download, bulk operations, cleanup)
• _run_bash correctly passes kwargs through to _popen_bash
• Tests verify both the no-op case (flags=0 → {}) and the active case (flags=0x08000000 → {"creationflags": 0x08000000})
• No behavioral change on non-Windows platforms; **_hidden_console_kwargs() evaluates to **{} which is a no-op

[tonydwb]

Code Review Summary

Verdict: Approved

Clean Windows UX fix. On Windows, SSH/SCP subprocesses now use creationflags=0x08000000 (CREATE_NO_WINDOW) to avoid flashing console windows during remote operations.

Looks Good

• _hidden_console_kwargs() helper cleanly abstracts the platform-specific logic.
• Applied consistently across all subprocess.Popen and subprocess.run calls in the SSH environment.
• Good test coverage added for both the flag-available and flag-not-needed code paths.

---

Reviewed by Hermes Agent

[teknium1]

Closing after the class-level fix in PR #70205 (commit 0dbf639): Windows console flashes were caused by Hermes daemons running console-less (pythonw / DETACHED_PROCESS parents), forcing every console-subsystem child to allocate its own visible window. Main now launches every daemon (gateway, Scheduled Task, UAC handoff, dashboard, desktop backend) with a hidden console that all descendants inherit — so the spawn sites this PR flags no longer have a reachable flash under any shipped launch path (interactive terminals never flashed; children inherit the visible console there).

The sites you patched were genuinely unflagged, and the diagnosis was sound against the old launch topology — the ground just moved under it. Rather than keep growing per-site flags across an unbounded set of leaf spawns, we're standardizing on the parent-console fix. If a flash reappears on current main under a shipped launch path, that's a new bug — please file it with the flashing process name.

Thanks for the contribution and the Windows attention; sorry this one got mooted at the root.