Greptile Summary

This PR adds windowsHide: true to the spawn() options to suppress visible console windows during gateway startup on Windows. However, the existing if (process.platform === 'win32') guard at line 46 returns early with mode: "disabled" before spawn() is ever called on Windows, so the new option is dead code on the only platform it targets. The fix needs to be rethought alongside the orphan-process concern that motivated the Windows early-return.

Confidence Score: 4/5

The change is a no-op on Windows due to the early-return guard; safe to merge in the sense it cannot regress, but it does not fix the reported issue.

One unresolved P1 finding: the added option is unreachable on Windows, so the stated bug is not actually fixed.

src/infra/process-respawn.ts — the Windows platform guard and spawn call need to be restructured for the fix to take effect.

This is a comment left during a code review.
Path: src/infra/process-respawn.ts
Line: 46-62

Comment:
**`windowsHide: true` is unreachable on Windows**

The `if (process.platform === 'win32')` guard at line 46 returns `{ mode: "disabled" }` before the `spawn()` call is ever reached, so the newly added `windowsHide: true` option is never exercised on any Windows process. The fix has no effect on the platform it targets.

For `windowsHide` to have any impact, the Windows early-return must either be removed (if the orphaning risk is now acceptable) or the spawn must be restructured to allow detached spawning on Windows — `windowsHide` alone does not address the orphan-process concern that motivated the guard.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (2): Last reviewed commit: "Merge branch 'main' into fix/windows-gat..." | Re-trigger Greptile}

Heyyy,
After a catch by the automated review.

I did a full audit of the actual Windows-supervised spawn paths (windows-task-restart.ts, daemon/schtasks.ts, and update-cli/restart-helper.ts) and verified that they already have windowsHide: true applied correctly.

I am leaving windowsHide: true here on the detached spawn as a defensive guardrail. If this spawn path is ever reached on a Windows-like environment (e.g., WSL interop, MSYS) or if the early return guard is refactored in the future, this ensures the flicker regression won't occur.

Since Node silently ignores the windowsHide flag on non-Windows operating systems, it is completely safe to include here for future-proofing.

Closing this as duplicate or superseded after Codex automated review.

PR #70308 should close in favor of the canonical linked bug #70238. Current main shows the proposed windowsHide additions are unreachable for Windows gateway respawn, while the actual Windows supervised/restart helpers already set windowsHide: true; any remaining flicker needs a fix against #70238’s real Windows startup path.

Best possible solution:

Close this PR and keep #70238 as the canonical tracker for the reported Windows gateway flicker. A real fix should start from a current Windows repro and target the actual scheduled-task/gateway startup path; defensive windowsHide flags on unreachable respawn branches should not be merged as the bug fix.

What I checked:

• Canonical tracker remains [Bug]: Gateway OpenCLAW spawns flashing command prompt windows in background on Windows #70238: The PR explicitly closes [Bug]: Gateway OpenCLAW spawns flashing command prompt windows in background on Windows #70238, and the supplied GitHub context shows [Bug]: Gateway OpenCLAW spawns flashing command prompt windows in background on Windows #70238 is still open with the Windows gateway flicker report. That issue is the right place to track any remaining real bug after this PR’s proposed patch was shown not to affect the active path. (c74fb781943f)
• CLI respawn patch is unreachable on Windows: buildCliRespawnPlan() returns null when platform === "win32", so the src/entry.ts spawn that this PR modifies is not used for Windows startup respawn. (src/entry.respawn.ts:67, c74fb781943f)
• Gateway detached respawn patch is bypassed on Windows: restartGatewayProcessWithFreshPid() uses triggerOpenClawRestart() for Windows Scheduled Task supervision and returns mode: "disabled" on win32 without task markers before reaching the detached spawn() branch. (src/infra/process-respawn.ts:35, c74fb781943f)
• Tests lock in the bypassed Windows process-respawn behavior: The current tests assert that Windows task-marker restarts call the supervisor path and do not call the spawn mock, and that Windows without Scheduled Task markers returns disabled and also does not spawn. (src/infra/process-respawn.test.ts:170, c74fb781943f)
• Actual Windows task restart already hides its helper window: The current Scheduled Task restart handoff spawns cmd.exe detached with stdio: "ignore" and windowsHide: true. (src/infra/windows-task-restart.ts:82, c74fb781943f)
• Scheduled Task fallback launcher already hides child windows: The current Windows scheduled-task fallback launcher sets windowsHide: true both when launching parsed program arguments and when falling back to cmd.exe /d /c for the task script. (src/daemon/schtasks.ts:321, c74fb781943f)

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against c74fb781943f.