Repository navigation
Windows host: daemon never becomes reachable (0.21.23) #3291
Description
Activity
Thanks for the report. Two separate causes, and the first is a quick fix:
- Log truncation (fixing first):
src/daemon-registration-owner.tsopens the daemon log for append and then truncates it through that handle, which fails with EPERM on Windows. That alone stops the daemon from starting, and it's independent of the second cause. - Process identity: daemon ownership is checked with
ps/lstart, which Windows doesn't have. That's being replaced with a single cross-platform approach (see macOS sandbox blocks ps-backed recording process identity #2376).
- Log truncation (fixing first):
Correction to my triage comment above — point 2 pointed the Windows identity work at the wrong issue, so let me set the record straight:
-
Both fixes land in fix(daemon): make the daemon reachable on native Windows hosts (#3291) #3330; neither is waiting on anything. The log-truncation fix and the Windows process-identity branch ship together there:
host-process.tsanswers birth,CommandLine, and liveness from a single PowerShell CIM (Win32_Process) query at the existing host-process seam, with a platform split so POSIX behavior is byte-identical tomain. My earlier sentence claiming identity was "being replaced with a single cross-platform approach (see macOS sandbox blocks ps-backed recording process identity #2376)" was wrong. -
macOS sandbox blocks ps-backed recording process identity #2376 is not the successor to this fix. It is the macOS-sandbox problem —
/bin/psexecution refused under the sandbox, answered by a nativeproc_pidinfo(PROC_PIDTBSDINFO)+sysctl(KERN_PROCARGS2)probe for simulator-recording ownership — and its required behavior explicitly keeps non-macOS behavior unchanged. It never mentions Windows. It is a sibling at the same host-process seam, not a prerequisite for fix(daemon): make the daemon reachable on native Windows hosts (#3291) #3330. -
The Windows identity path has live evidence. An external tester ran the full checklist on native Windows 11 (10.0.26200, Node 24.21.0 + Electron 44.4.2, both transports) at fix(daemon): make the daemon reachable on native Windows hosts (#3291) #3330 head
a7821ef58: clean start with zero EPERM, aprocessStartTimematching the daemon pid's CIMCreationDateexactly, daemon reuse, graceful stop — plus a non-ASCII-path round-trip, and a 0.21.12 baseline on the same host still failing. Details in fix(daemon): make the daemon reachable on native Windows hosts (#3291) #3330 (comment).
Housekeeping: I am dropping the
ready-for-agentlabel I applied during triage — with the fix PR open, green, and awaiting human review, leaving this in an agent queue invites duplicate work on a fixed bug. State lives on #3330 (ready-for-human) until a maintainer merges; #3330 saysRefs #3291, so closing this issue stays the maintainer's call.-
Just ran into this myself. 0.21.20 works well on Windows but 0.21.21-23 do not.
- added a commit that references this issue
on Oct 9, 2026 Fixed on
mainby #3330 (87c5b3b): the daemon log is now truncated through a handle that permitsftruncateon Windows, and process identity (start time, command line, liveness) is read from a PowerShell CIMWin32_Processquery instead ofps.This isn't in a release yet — 0.21.21–0.21.23 still have the bug, and the fix will ship in the next release after 0.21.23. Until then, 0.21.20 is the last version that works on native Windows.
Environment
npx agent-deviceDescription
On a native Windows host the daemon never becomes reachable, so every command fails with
COMMAND_FAILED: Failed to start daemon. There are two separate causes:EPERMintruncateDaemonLog(src/daemon-registration-owner.ts). The log is openedwith flag
'a'and then emptied withfs.ftruncateSync. On Windows a handle opened forappend only cannot be truncated, so the daemon exits:
Daemon error: EPERM: operation not permitted, ftruncate.Creating the file with
'a'and then truncating through a handle opened with'r+'fixesthis: the daemon starts and listens.
Live daemon reported as
not-running. With (1) patched, the daemon is listening(
netstatshows it on the port indaemon.json), but the client still reportsstartError: daemon process … exited before readinessand"termination": {"status": "not-running"}.It then logs
Daemon registration busy; exiting.on every retry. Process identity inowner-identity.jsrelies onps -ax -o pid=,ppid=,command=/lstart, which do not existon Windows, so ownership can never be verified.
Not a regression as far as I can tell: the docs never state Windows host support. Previous
Windows fixes (#2022, #2526, #502) suggest it is intended to work.
Reproducible Demo
On native Windows 11:
Result:
Failed to start daemon;~/.agent-device/daemon.logshows the EPERM from (1). Afterpatching (1), the same command shows the daemon listening while the client reports it as
not-running, which is (2).