[Bug] Windows: session create always fails — worker handshake budgets cannot accommodate AV-slowed process launches

[ysquare]

Affected area

TUI

What happened?

Any launch that needs a new session worker fails after 30 s with:

Error: Timed out after 30000ms waiting for the Prime Agent daemon response to "create"

The daemon log shows the supervisor's retry loop dying at either stage:

supervisor: Supervisor command create failed: Error: Timed out connecting to daemon session worker:
  Error: Timed out waiting for daemon worker hello
supervisor: Supervisor command create failed: Error: Timed out connecting to daemon session worker:
  Error: Timed out waiting for daemon worker response to worker_auth

On this machine each worker_auth takes 2.2–3.4 s of synchronous work (a PowerShell spawn inside the supervisor-claim check), while the per-attempt budgets are 1000 ms each — so the handshake can never succeed.

Steps to reproduce

1. Use a Windows machine with real-time AV/EDR scanning enabled (process launches and file reads get scanned).
2. Ensure no daemon is already running, then start any session that requires a new worker, e.g. prime-agent -p "Reply with exactly: OK".
3. It fails after ~30 s with the create timeout above; the daemon log shows the hello/worker_auth timeout loop.

Expected behavior

Session creation succeeds on machines where process launch + PowerShell startup take a few seconds — the handshake budgets should tolerate the measured per-attempt cost.

Prime Agent version

0.8.0

Environment

• Windows 11 Enterprise (10.0.26100), x64 - Node.js v24.19.0 - machine with real-time AV/EDR scanning

Additional context

DaemonSupervisor.connectWorker (src/modes/daemon/daemon-supervisor.ts) allows 1000 ms per attempt for hello and 1000 ms for worker_auth, inside a 30 s window (WORKER_CONNECT_TIMEOUT_MS); DaemonClient.request (src/modes/daemon/daemon-client.ts) defaults to 30 s for create. On an AV-scanned machine:

• Worker boot (node + bundle) takes 30–50 s until it can accept pipe connections.
• Each worker_auth runs assertSupervisorClaimCurrent → assertDaemonSupervisorOwnerCurrent (src/modes/daemon/daemon-supervisor-ownership.ts) → isProcessIdentityAlive → getProcessStartId, which synchronously spawns powershell.exe (2–4 s under AV) and blocks the worker's event loop while it runs.

With temporary instrumentation we measured worker_auth received → claim ok at 2.2–3.4 s per attempt. Widening the budgets locally fixed everything:

Constant	Upstream	Local (working)
waitForHello per attempt	1000 ms	10 000 ms
authenticateWorker per attempt	1000 ms	10 000 ms
WORKER_CONNECT_TIMEOUT_MS	30 000 ms	60 000 ms
DaemonClient.request default	30 000 ms	120 000 ms

Two structural notes beyond the numbers:

1. getWindowsProcessStartId blocks the worker's event loop for seconds per auth attempt. Caching the supervisor's start-id (it cannot change during the life of the process) or computing it once at startup would remove most of the pressure.
2. connectWorker's retry loop opens a fresh connection every ~25 ms during the window, and each fresh connection re-runs the PowerShell identity check on the worker — so a slow machine multiplies the very work that makes it slow.

Happy to turn the timeout widening (or the start-id caching) into a PR.

[cyberranger93]

Independent reproduction, on a machine with no AV/EDR involvement — which I think widens the scope of this report usefully.

Same failure, same two stages, Windows 11 (10.0.26200) / Node 24.12 / prime-agent 0.7.4. In my case the trigger was simply a heavily loaded box (~150 concurrent node/python processes, 60% CPU), not real-time scanning. So the budgets are under-provisioned for any source of contention, not just AV.

Measured here with temporary instrumentation inside the worker's worker_auth handler:

Stage	Measured	Budget upstream
worker_auth received -> claim ok	~1.20s (consistent, 20+ samples)	1000ms
bare powershell.exe -NoProfile -Command spawn	~1.55s	—
full supervisor -> worker-ready cycle	~20-28s	30s (DaemonClient.request)

That 1.20s against a 1000ms budget is the whole bug: it fails just over the line, which is why it presents as flaky alternation between hello and worker_auth rather than a clean deterministic error.

The instrumentation trace, showing the loop never converging:

01:01:41.114  worker_auth parsed, checking claim
01:01:42.309  claim check passed, 0 previous claims     <- 1.195s
01:01:42.311  about to write worker_auth success response
01:01:42.331  connection received                        <- supervisor already gave up, retried
01:01:43.505  claim check passed ...                     <- repeats until the 30s window closes

Note the worker succeeds every time and writes its success response — the supervisor has simply already abandoned that attempt. So the retry loop in connectWorker can never converge no matter how many attempts fit in the 30s window.

Two negative results that may save someone time:

1. The fd-3 startup gate is not at fault. It looks like a prime suspect (Windows stdio inheritance is a classic source of this failure shape), and I initially "fixed" it. It is fine — Node on Windows inherits the fourth stdio pipe correctly, including under detached: true:

   spawn(process.execPath, ["child.cjs"], { stdio: ["ignore","ignore","pipe","pipe"], detached: true })
     .stdio[3].end("start\n");     // child: fs.readFileSync(3, "utf8") -> "start\n"

   Skipping the gate on win32 also removes its durability guarantee and breaks 5 tests in daemon-supervisor-monitor.test.ts. Worth leaving alone.

2. A long-lived supervisor caches its compiled source, so edits to daemon-supervisor.ts have no effect until the supervisor process is actually killed — with no error either way. This masks whether a candidate fix works at all, and cost me several test cycles before I noticed the worker-side instrumentation was firing while the supervisor-side was not.

Patch I am running, matching @ysquare's conclusion — two constants, win32-gated, literal no-op on Linux/macOS:

• daemon-supervisor.ts: WORKER_HANDSHAKE_TIMEOUT_MS = process.platform === "win32" ? 15_000 : 1_000, used for both waitForHello and authenticateWorker in connectWorker.
• daemon-client.ts: DaemonClient.request default timeoutMs -> 120_000 on win32.

Result: prime-agent -p completes in ~28s cold, ~20s warm, consistently.

On regression risk — vitest --run daemon gives 33 failed | 668 passed | 9 skipped both with and without the patch on this machine, i.e. zero net change. (Those 33 are pre-existing Windows failures where tests bind Unix-domain .sock paths and get EACCES; they fail identically on unpatched main.) biome check, tsgo --noEmit, installer and browser-smoke checks all pass.

I have this on a branch and opened it as a PR before reading CONTRIBUTING.md properly — it was correctly auto-closed as unvouched (#2013), so I am adding it here instead. Happy to leave it at that, or hand the branch over if a maintainer wants it; entirely up to you.

A design thought for whoever picks this up: raising the constants fixes the symptom, but getProcessStartId() spawning powershell.exe synchronously on the worker's event loop is the underlying cost. Caching the start-id per pid for the lifetime of the handshake, or moving it off the hot path, would make the budgets irrelevant rather than merely larger.

🤖 Generated with Claude Code