openclaw - 💡(How to fix) Fix [Bug]: Hidden CMD Window Appears After Update (findstr process) [1 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After each OpenClaw update, a visible CMD window appears showing findstr /R /C:"18800 .*LISTENING" that cannot be manually closed. This window persists and interferes with the user experience.

• OS: Windows 11 Pro for Workstations 10.0.26200
• OpenClaw Version: v2026.4.1
• Installation Method: npm global install (npm install -g openclaw)
• Service Management: Windows Task Scheduler (Task Name: "OpenClaw Gateway")

Prerequisite: Every time I install a new version, I need to hide the CMD window that boots from booting, so I changed the Windows task scheduler to: powershell.exe Start in WindowStyle Hidden gateway.cmd. In fact, this problem is encountered with every update.

Steps to reproduce

1. Install OpenClaw globally via npm
2. Set up auto-start via Windows Task Scheduler (triggered on user logon)
3. Run openclaw update to update to a newer version
4. After update completes and gateway restarts, observe a visible CMD window appears
5. The window title shows something like findstr /R /C:"18800 .*LISTENING"
6. Attempting to close the window manually fails (it either doesn't respond or reappears)

Expected behavior

After the update is complete, there are no additional windows that cannot be closed, and the gateway is restarted normally

Actual behavior

After the update, a findstr CMD window appears that cannot be closed

OpenClaw version

2026.4.1

Operating system

Windows 11

Install method

npm global

Model

minimax

Provider / routing chain

minimax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

My ClaudeCode think that is an update-cli issue:

Root Cause Analysis

The issue originates from the restart script generated in dist/update-cli-BJ1Yth1Q.js (lines 520-529):

:force_kill_listener
for /f "tokens=5" %%P in ('netstat -ano ^| findstr /R /C:":${port} .*LISTENING"') do (
  taskkill /F /PID %%P >nul 2>&1
  goto port_released
)

Technical Explanation:

When using for /f with the 'command' syntax (single quotes), cmd.exe creates a child process to execute the piped command. The restart script is spawned with windowsHide: true and stdio: "ignore" (line 562-564):

spawn(isWindows ? "cmd.exe" : "/bin/sh", isWindows ? [
  "/d", "/s", "/c",
  quoteCmdScriptArg(scriptPath)
] : [scriptPath], {
  detached: true,
  stdio: "ignore",
  windowsHide: true
}).unref();

However, the child cmd.exe spawned by for /f to run netstat | findstr does NOT inherit the windowsHide property. This is a Windows limitation where:

1. Parent process starts with windowsHide: true → hidden window
2. Parent executes for /f with inline command → spawns child cmd.exe
3. Child cmd.exe window visibility is controlled by Windows defaults, not parent's spawn options
4. Child window becomes visible and persists because it's waiting for the for /f loop to complete

Suggested Fix

Modify the restart script to avoid using for /f with inline command execution. Instead, redirect command output to a temporary file first:

:force_kill_listener
netstat -ano | findstr /R /C:":${port} .*LISTENING" >"%TEMP%\openclaw_port_${port}.txt"
for /f "tokens=5" %%P in ("%TEMP%\openclaw_port_${port}.txt") do (
  taskkill /F /PID %%P >nul 2>&1
  del "%TEMP%\openclaw_port_${port}.txt"
  goto port_released
)
del "%TEMP%\openclaw_port_${port}.txt"

This approach:

• Avoids spawning a visible child cmd.exe for inline command execution
• Uses file redirection which runs in the same process context
• Properly cleans up temporary files after use