[Bug] Windows named-pipe daemon: session worker listens but create times out on hello/worker_auth

[YashvantHange]

Affected area

Coding agent and CLI, Installation or updates

What happened?

On native Windows, a source checkout under Git Bash cannot complete daemon-backed commands. model list (and any path that creates a session worker) fails after 30s:

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

The supervisor log shows the worker process did start and bind a named pipe, then the supervisor cannot complete worker handshake:

supervisor: Session worker ... stderr: Prime Agent daemon listening on \\.\pipe\prime-agent-worker-...
supervisor: Supervisor command create failed: Error: Timed out connecting to daemon session worker: Error: Timed out waiting for daemon worker hello

A later retry failed at worker_auth instead of hello. The catalog helper also dies immediately: Daemon catalog exited (1).

--help and --version work. Those paths do not need a session worker.

This blocked a Bedrock /model repro for discussion 1611. I never reached model lookup.

Steps to reproduce

1. Windows 10, Git Bash, Node v22.23.2, source tree at 8c749fb, npm ci, no packages/*/dist.
2. Isolated config dir. Custom daemon socket //./pipe/prime-agent-repro-1611.
3. export PI_OFFLINE=1
4. ./prime-agent.sh --daemon-socket '//./pipe/prime-agent-repro-1611' model list haiku

Expected behavior

model list returns, or fails with a model/auth error. Session worker hello/auth should succeed on the named pipe the worker logged.

Prime Agent version

0.7.4 source 8c749fb (./prime-agent.sh --version)

Environment

Windows 10 (build 26220), Git Bash (C:\Program Files\Git\bin\bash.exe), Node v22.23.2. Default Windows daemon socket is \\.\pipe\prime-agent-daemon.

Additional context

Related: closed Windows PRs were contribution-gated (#1053, #1119, #978). I am not opening an unsolicited PR.

Supervisor connectWorker waits 1s for hello (daemon-supervisor.ts) via DaemonWorkerClient.waitForHello. The worker log line appears, so this looks like a handshake/connect mismatch on Win32 named pipes, not a missing worker process.