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}