[Windows] Daemon supervisor runs but never creates its control named pipe — bg service reads as 'not running'

Summary

On Windows, the background-service supervisor process starts and stays alive, but it never creates its control named pipe \\.\pipe\cc-daemon-<id>-control. Because the pipe is absent, every client (claude daemon status, and anything launching a bg session) gets connect ENOENT and reports:

Starting background service…
Couldn't reach the background service (not running) — run 'claude daemon status'

The service is unusable: a transient supervisor spins up, no client can attach (the pipe it would connect to does not exist), the supervisor idles out after 50s and exits, and the cycle repeats on every trigger.

Decisive evidence — a live supervisor with zero control pipe

Started a supervisor in the foreground, then queried status while it was alive:

$ claude daemon status
pid:     <pid>
version: 2.1.169
uptime:  54s
origin:  foreground
...
bg sessions:
  sock dir:     \\.\pipe\cc-daemon-*
  control.sock: unreachable (connect ENOENT \\.\pipe\cc-daemon-<id>-control)
  bg workers:   0 in roster.json (control unreachable)

status can see the process (reports pid, version, 54s uptime) — so the supervisor is genuinely alive — yet control.sock is ENOENT. A full listing of \\.\pipe\ while that supervisor is alive shows no cc-daemon-* pipe of any name:

\\.\pipe\cowork-daemon-console-<id>
\\.\pipe\claude-mcp-browser-bridge-<user>
\\.\pipe\<guid>
\\.\pipe\AppContracts_<id>

Other Claude pipes (MCP browser bridge, cowork daemon) are present, so named-pipe creation works for this user in general — only the bg-service control pipe is never created. The expected id <id> is computed deterministically (no daemon.json on disk) and is the same across every restart.

daemon.log — supervisor healthy, workers=0, silent on the pipe

[supervisor] ─── daemon start ─── version=2.1.169 pid=<pid> origin=foreground
[supervisor] workers=0
[supervisor] idle 50s with no clients — exiting
[supervisor] shutting down

No line is logged around control-pipe creation — the failure is silent.

Environment

• OS: Windows 11 Pro (10.0.26200)
• Claude Code: 2.1.169
• CLI: C:\Users\<user>\.local\bin\claude.exe (Node 22 at C:\Users\<user>\.local\node22\node.exe)
• Shell: PowerShell 7 + Git Bash

Expected

A running supervisor creates its control named pipe so clients can attach, and claude daemon status reaches the control socket of a supervisor it can already see by pid.

Actual

The supervisor runs without ever creating \\.\pipe\cc-daemon-<id>-control. Every client gets ENOENT, so the bg service reads as "not running" from the client's perspective even with a live supervisor process.

Repro

1. On Windows, trigger anything that needs the bg service (or run claude daemon run).
2. While the supervisor is alive (claude daemon status shows a pid and uptime), list \\.\pipe\ → no cc-daemon-* pipe exists.
3. claude daemon status reports control.sock: unreachable (connect ENOENT …), and launching a bg session shows "Couldn't reach the background service (not running)."

Note on roster staleness

Because no client can ever attach, background workers are never registered or reconciled, so a roster.json from an earlier working session lingers and status reports "N workers in roster (control unreachable)". Running claude daemon stop reaps those entries but does not restore reachability — the next supervisor still creates no pipe. The missing control pipe is the root cause; the roster staleness is downstream of it.

Related

• #60455 — [Windows] supervisor exits early on idle; same family (Windows bg-session unreachable) but framed as idle-timeout duration.
• #66358 — orphaned workers after auto-update (macOS, control-key skew); different root cause (workers alive, locked to an old key) versus here (control pipe never created).