WhatsApp reconnect loop flashes Windows Terminal windows on every retry

[Frankchensir]

Summary

On Windows, the WhatsApp gateway reconnect loop opens visible console windows whenever the bridge is unhealthy or awaiting re-pairing. The windows are created by short-lived console subprocesses launched without CREATE_NO_WINDOW.

In a 30-minute capture, 15 visible Windows Terminal/OpenConsole windows appeared: three per reconnect cycle across five cycles, with each cycle roughly 5 minutes 34 seconds apart.

Environment

• Windows 11
• Hermes Agent 0.18.2
• Reproduced on commit 8e3f9537db21b49ebe796f7b5a6ff489028fe1fb
• Confirmed still present on current main candidate 7b5ba2054721dde998ed47fd4a0f031955278e99
• WhatsApp mode: self-chat
• Trigger condition: bridge connection times out / account requires re-pairing

Steps to reproduce

1. Enable the WhatsApp platform on Windows.
2. Use a session that cannot connect and requires re-pairing, or otherwise force the bridge to time out.
3. Start the Hermes gateway.
4. Leave the reconnect watcher running.

Actual behavior

Each reconnect cycle produces visible terminal flashes:

1. Two short flashes around the Node requirement probes.
2. One longer flash when the timed-out bridge is terminated.

The gateway log repeats:

Reconnecting whatsapp (attempt N)...
Reconnect whatsapp error: whatsapp connect timed out after 30s, next retry in 300s

Process/window tracing aligned the flashes with:

• node.exe --version
• node.exe .../whatsapp-bridge/bridge.js
• taskkill /PID ... /T after the 30-second timeout

The Node probe windows were typically visible for only a few milliseconds; the timeout cleanup window was visible for roughly 0.5–0.6 seconds.

Expected behavior

All WhatsApp gateway background subprocesses should run without creating or activating a visible console window.

Root cause

In plugins/platforms/whatsapp/adapter.py, these Windows subprocess calls do not pass the existing windows_hide_flags() compatibility helper:

• _terminate_bridge_process(): taskkill
• check_whatsapp_requirements(): node --version
• WhatsApp dependency repair: npm install --silent

The long-running bridge Popen already uses windows_detach_popen_kwargs(), and the port-cleanup netstat / taskkill path already uses windows_hide_flags().

Suggested fix

Import windows_hide_flags alongside windows_detach_popen_kwargs and pass:

creationflags=windows_hide_flags()

to the three subprocess.run() calls above. The helper returns CREATE_NO_WINDOW on Windows and 0 elsewhere.

Validation

A local patch was tested with:

• 16 passing Windows subprocess regression tests
• Focused async tests for the npm-install and bridge-taskkill paths
• End-to-end process/window monitoring across multiple real reconnect attempts

Before the patch: 15 visible terminal windows over five reconnect cycles.

After the patch and gateway restart: 0 visible windows while the monitor recorded 908 process-start events, including repeated real bridge.js starts and taskkill.exe timeout cleanup.

Related

The same Windows console-flash class is being addressed for another platform in #54565.

[teknium1]

Resolved by PR #70205 (commit 0dbf639) — the root cause of Windows console flashes was Hermes daemons running console-less (pythonw.exe / DETACHED_PROCESS parents), which forced every console-subsystem child to allocate its own visible console. All daemon launch paths (gateway start/restart watchers, Scheduled Task launcher, UAC handoff, dashboard actions) now run console python with CREATE_NO_WINDOW: one hidden console, inherited by all descendants, nothing flashes. The desktop backend got the same treatment earlier in aa2ae36, and PR #69850 covered the desktop exec RPC paths.

If a console still flashes on a current build, that's a new leg — please open a fresh issue with the flashing process name (Task Manager or the title bar) and how Hermes was launched.