openclaw - 💡(How to fix) Fix [Bug]: Visible cmd.exe console windows flash on Windows from internal child_process.exec() calls (network discovery loop) [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Environment OS: Windows 10 Pro 22H2 (build 19045.6466), running directly on Windows (not WSL2) OpenClaw version: 2026.4.2 (d74a122) Node: v24.14.1 Install method: npm install -g openclaw@latest Process manager: PM2, running under interactive user session (not as a Windows service) Channels active: WhatsApp (linked), Telegram (configured)

Description On Windows, several internal subprocess calls in OpenClaw display visible cmd.exe console windows (small black flashes) for a fraction of a second before completing. The flashes happen roughly every 15 seconds, even when the gateway is otherwise idle. This is consistent with child_process.exec() calls in Node.js that don't pass windowsHide: true. On Windows, that's the difference between a silent subprocess and a momentarily-visible cmd.exe console. The behaviour is purely cosmetic — the gateway works correctly, WhatsApp/Telegram are responsive, no functional impact — but the flickering is distracting if the host PC ever has a screen attached (or when accessed via RDP).

Steps to reproduce

Steps to reproduce

Install OpenClaw on Windows: npm install -g openclaw@latest Run openclaw onboard and link a WhatsApp account Start the gateway: openclaw gateway --port 18789 Watch the desktop. Small cmd.exe windows flash and disappear roughly every 15 seconds.

Expected behavior

Expected behaviour Internal subprocess calls should run silently with no visible console window.

Actual behavior

Suggested fix Pass { windowsHide: true } to all internal child_process.exec() / execSync() / spawn() calls. For example: js// Before: exec('arp -a | findstr /C:"---"', (err, stdout) => { ... });

// After: exec('arp -a | findstr /C:"---"', { windowsHide: true }, (err, stdout) => { ... }); Or, if spawn is preferred (cleaner for piped commands): jsspawn('arp', ['-a'], { windowsHide: true }); A grep for exec(, execSync(, spawn( in the codebase, ignoring matches inside test files and node_modules, should surface the relevant call sites — likely a small number. Workarounds attempted

Running PM2 as a Windows service (Session 0 isolation) would suppress the windows, but is invasive — it migrates the PM2 dump to the SYSTEM account, breaking user-context credentials (WhatsApp pairing, OAuth tokens, etc.). Not viable for personal-assistant use cases. Living with the flashes — works, but cosmetically poor for headless/RDP users.

Additional context The Windows-direct install path is documented as supported (with WSL2 recommended). For users on this path, this issue is a noticeable UX regression vs. the macOS/Linux experience. Happy to test a fix if helpful.

OpenClaw version

2026.4.2 (d74a122)

Operating system

Windows 10 Pro 22H2 (build 19045.6466), running directly on Windows (not WSL2)

Install method

npm install -g openclaw@latest

Model

Sonnet 4.5

Provider / routing chain

PM2, running under interactive user session (not as a Windows service)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Diagnostic evidence
Polling Win32_Process for cmd.exe/conhost.exe spawns over 60 seconds (PowerShell, 100ms cadence), the openclaw node process is the parent of repeated transient cmd.exe spawns:
Time      PID    Name        Parent                    Command
--------  -----  ----------  ------------------------  -----------------------------------------
21:47:09  14388  cmd.exe     node.exe (openclaw)       cmd /d /s /c "arp -a | findstr /C:"---""
21:47:24   8936  cmd.exe     node.exe (openclaw)       (parent died before capture)
(Other transient cmd processes captured in the same window — n8n start, start-ngrok.bat — were unrelated PM2 startup wrappers, fired once at boot.)
The arp -a | findstr pattern suggests this is part of network/device discovery (probably enumerating LAN peers for channel routing or device pairing).

Impact and severity

No response

Additional information

No response