Greptile Summary

This PR adds a PowerShell Get-CimInstance Win32_Process fallback to resolveWindowsCommandLine in src/infra/ports-inspect.ts, fixing the 60-second timeout on Windows 11+ machines where wmic.exe has been removed. The fix correctly addresses the root cause and uses the Microsoft-recommended migration path.

• The new resolveWindowsCommandLineViaPowerShell function is well-structured and mirrors the safety/timeout conventions of the rest of the file.
• The fallback is invoked in one unintended extra case: when wmic exits with code 0 but produces no non-empty commandline= line. On Windows 10 and earlier (where wmic is present), this causes an unnecessary powershell.exe spawn for processes whose command line isn't accessible via wmic. Adding return undefined before the resolveWindowsCommandLineViaPowerShell call — inside the if (res.code === 0) block — would restrict the fallback to only the wmic-unavailable case.
• No new unit tests cover the Windows PowerShell fallback path, though the existing test suite skips all Windows-specific tests, so this is consistent with the project's current testing approach.

Confidence Score: 3/5

• Safe to merge for the Windows 11+ fix, but has a minor regression on Windows 10 machines with wmic available.
• The core fix is correct and solves the reported Windows 11+ timeout bug. However, the fallback condition is broader than intended: PowerShell is invoked even when wmic succeeds but returns no commandline, adding unnecessary latency on machines where wmic is available. This is a logic error that should be addressed before merging to avoid degrading performance on the currently-working platform.
• src/infra/ports-inspect.ts — specifically the fallback condition in resolveWindowsCommandLine (lines 278–291)

This is a comment left during a code review.
Path: src/infra/ports-inspect.ts
Line: 278-291

Comment:
**PowerShell fallback triggered even when wmic succeeds**

The fallback to PowerShell is called in two cases, but it should only be called when `wmic` itself fails (non-zero exit code):

1. ✅ `wmic` returns non-zero (unavailable) → fallback to PowerShell — **intended**
2. ❌ `wmic` returns exit code 0 but produces no non-empty `commandline=` line → also falls through to PowerShell — **unintended regression**

Case 2 happens on machines where `wmic` **is** present (Windows 10 and earlier, the currently-working case). For any process that `wmic` can't report a commandline for (e.g. a system process with an inaccessible command line, or a process that has already exited), the code will now redundantly spawn `powershell.exe`. Since `powershell -NoProfile` can still take hundreds of milliseconds to start, this adds latency to every port inspection on the "working" Windows platform.

The fix is to only fall back to PowerShell when `wmic` returns a non-zero exit code:

```suggestion
  if (res.code === 0) {
    for (const rawLine of res.stdout.split(/\r?\n/)) {
      const line = rawLine.trim();
      if (!line.toLowerCase().startsWith("commandline=")) {
        continue;
      }
      const value = line.slice("commandline=".length).trim();
      if (value) {
        return value;
      }
    }
    return undefined;
  }
  // Fallback to PowerShell Get-CimInstance when wmic is unavailable.
  return resolveWindowsCommandLineViaPowerShell(pid);
```

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

_{Last reviewed commit: 9f4d01e}

Closing this as implemented after Codex review.

Current main already avoids the Windows restart false-timeout this PR targets by treating a busy-but-reachable gateway as healthy during restart, even when listener classification is ambiguous. The exact wmic -> PowerShell fallback in src/infra/ports-inspect.ts is not present, but the reported restart symptom is already fixed on main and shipped in v2026.4.22.

What I checked:

• Restart health no longer depends solely on listener classification: inspectGatewayRestart() first probes the gateway when the port is busy and runtime status is not running, and also probes again when runtime is running but port ownership is ambiguous. That makes a healthy restarted gateway pass even if Windows listener attribution falls back to node.exe/unknown. (src/cli/daemon-cli/restart-health.ts:137, 28fc03c386e1)
• Gateway restart command uses the new health path on Windows: openclaw gateway restart calls waitForGatewayHealthyRestart() with Windows-specific stale-listener handling, so the shipped restart flow uses the probe-backed logic. (src/cli/daemon-cli/lifecycle.ts:241, 28fc03c386e1)
• Tests cover the ambiguous-ownership and busy-port probe cases: There are explicit tests that a local probe marks the restart healthy when ownership is ambiguous, and when runtime status lags but the probe succeeds. Those are the failure modes described in this PR. (src/cli/daemon-cli/restart-health.test.ts:208, 28fc03c386e1)
• The exact PR patch is still absent from port inspection: resolveWindowsCommandLine() on current main still uses wmic only and returns undefined on non-zero exit, so this PR's code itself was not merged. The close decision is based on the restart symptom already being handled elsewhere on main. (src/infra/ports-inspect.ts:252, 28fc03c386e1)
• Shipped release contains the implemented behavior: The released commit 00bd2cf7a376f1fba26291c6c4766f1f15cbdfa5 is tagged v2026.4.22, so the current behavior is already in a release. (00bd2cf7a376)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review notes: reviewed against 28fc03c386e1; fix evidence: release v2026.4.22, commit 00bd2cf7a376.