openclaw - 💡(How to fix) Fix [Bug][Windows] openclaw update still hangs with stuck findstr on 2026.4.24 — prior fixes (#57682, #44693, #27802, #41804) are incomplete [1 comments, 2 participants]

Hitting this on openclaw 2026.4.24 (Windows 11 Pro 26200, Node 22), one day after #57682 was closed as completed. The persistent visible findstr /R /C:":18789 .*LISTENING" window symptom is unchanged. #44693, #27802, and #41804 were also closed as completed but are clearly still in play — they're three symptoms of the same broken update→restart contract.

Repro: openclaw update from any terminal. The detached %TEMP%\openclaw-restart-<ts>.bat spawns. findstr window appears and never closes. Gateway eventually restarts via the force-kill fallback in some runs but the cmd+findstr pair stays alive. del %~f0 at the end of the .bat is never reached.

Concrete evidence from a live run:

ProcessId  ParentProcessId  Name         CommandLine
10164      36140            cmd.exe      cmd.exe /d /s /c %TEMP%\openclaw-restart-1777218587016.bat
2460       10164            findstr.exe  findstr /R /C:":18789 .*LISTENING"
19576      34768            node.exe     ...openclaw\dist\index.js gateway --port 18789

Both cmd 10164 and findstr 2460 were still alive 4+ minutes after spawn. Gateway log shows restart attempt source=update target=OpenClaw Gateway with no restart done line — the script never reached :port_released.

Root cause (chain that links the four closed issues):

1. ~/.openclaw/gateway.cmd (the action of the OpenClaw Gateway scheduled task) does:

   start "" /b "C:\Program Files\nodejs\node.exe" ...openclaw\dist\index.js gateway --port 18789 >nul 2>&1
   exit /b 0

   The cmd action exits immediately, so the scheduled task is no longer in a "running" state. Node is orphaned from the task — there's no parent/child link.

2. The post-update restart .bat from dist/update-cli-*.js::prepareRestartScript calls schtasks /End /TN "OpenClaw Gateway" to release the port. The task isn't running (per #1), so /End is a no-op. The orphan node still holds 18789. This is what #27802 was about; closing it didn't fix the underlying shape of gateway.cmd.

3. The polling loop (netstat | findstr ":18789 .*LISTENING") never sees the port released. After 10 attempts (~10s) it falls through to force_kill_listener:

   for /f "tokens=5" %%P in ('netstat -ano ^| findstr /R /C:":18789 .*LISTENING"') do (
     taskkill /F /PID %%P
     goto port_released
   )

   On some configs (likely under AV real-time scanning of findstr.exe in a piped for /f) this subshell deadlocks — findstr stays alive forever, cmd never exits, .bat never del'd. This is the visible-hanging symptom from #57682.

4. Even when the for/f doesn't deadlock, the children (timeout /t, netstat, findstr, taskkill, schtasks) flash visible consoles. Parent cmd is spawned with windowsHide: true (update-cli line 619), but windowsHide doesn't propagate to descendant console-creating processes. This is #44693.

The bug is structural, not a Windows-config edge case. The .bat is built on an assumption (schtasks /End releases the port) that gateway.cmd's shape contradicts. Patching windowsHide on the parent (#44693) doesn't help the children. Fixing the polling loop in isolation (#57682) doesn't help when the port can't be released. They have to be fixed together.

Suggested fixes (any one helps; combining is cleanest):

• (a) Fix gateway.cmd so the scheduled task actually owns the gateway process. Replace start "" /b node ... & exit /b 0 with foreground exec: "C:\Program Files\nodejs\node.exe" ...index.js gateway --port 18789 (no start /b, no exit). Then schtasks /End reliably terminates the listener. This single change makes the polling loop exit in <1s on every Windows machine and resolves #27802 directly.
• (b) Replace the polling .bat with PowerShell. Use Get-NetTCPConnection -LocalPort 18789 -State Listen + Stop-Process instead of netstat | findstr | for /f | taskkill. PowerShell handles pipes deterministically and runs hidden cleanly with -WindowStyle Hidden. Drops both the flicker and the deadlock surface.
• (c) Move the port-wait + kill logic into Node (in update-cli) before spawning the detached helper. Helper then only starts the task. Smaller scripts → smaller bug surface.

Happy to send a PR for (a)+(b) if a maintainer flags which direction is acceptable.

User-side workaround that fully bypasses today: openclaw update --no-restart, then restart by hand (schtasks /End + kill any orphan node on 18789 + schtasks /Run). Wrapping that in a personal openclaw-update.cmd shim makes it a drop-in replacement for openclaw update.