Summary

isPortBusy in src/cli/ports.ts:132 (the gateway --force kill-port guard) shares the same address-family flaw fixed for the CDP preflight in #94379 / #94415.

async function isPortBusy(port: number): Promise<boolean> {
  try {
    await tryListenOnPort({ port, exclusive: true });
    return false;
  } catch (err: unknown) {
    const code = (err as NodeJS.ErrnoException).code;
    if (code === "EADDRINUSE") {
      return true;
    }
    throw err instanceof Error ? err : new Error(String(err));
  }
}

A bare tryListenOnPort binds the IPv6 wildcard (::) on a dual-stack host. An occupant listening only on 127.0.0.1 (IPv4-only) does not conflict with that bind, so isPortBusy returns false and reports the port as free when it is actually taken.

Impact

Different surface and lower harm than #94379: this guards the gateway --force flow (used to detect/kill a stale process holding the port). A false "not busy" here means the force-kill path may conclude there is nothing to reclaim while an IPv4-only listener is in fact occupying the port. It does not silently let Chrome bind a busy port (that was the #94379 symptom), so it was deliberately left out of scope of #94415 to keep that PR focused.

Suggested fix

Route isPortBusy through checkPortInUse (exported from src/infra/ports-inspect.ts as of #94415), which probes all four endpoints — 127.0.0.1, 0.0.0.0, ::1, :: — instead of a single bare listen. Map its "busy" result to true. Add a regression test mirroring the IPv4-only guard added in src/infra/ports.test.ts.

References

• Sibling fix: [Bug]: ensurePortAvailable() pre-flight misses IPv4-only loopback occupant → Chrome CDP bind fails with misleading "HTTP 401" #94379 (CDP 401 collision), PR fix(ports): probe all address families in ensurePortAvailable #94415
• Flagged during review of fix(ports): probe all address families in ensurePortAvailable #94415 by @NianJiuZst