[mutianf]

Problem

The accelerator daemon does not compile for GOOS=windows on any architecture:

$ GOOS=windows GOARCH=amd64 go build ./internal/accelerator/...
internal/accelerator/server.go:142:21: undefined: syscall.Umask
internal/accelerator/server.go:144:10: undefined: syscall.Umask

Identical failure for 386 and arm64. syscall.Umask is POSIX-only, and server.go called it inline around the bind to keep the socket from being world-connectable during the window between creation and the chmod that follows.

Changes

Move the bind behind a listenUDS helper with a per-platform implementation.

• socket_unix.go (//go:build !windows) — the existing umask + chmod logic, moved verbatim. Linux behavior is unchanged; it is the same code in a new file.
• socket_windows.go — Windows 10 1803+ and Server 2019+ support AF_UNIX and Go's net package speaks it, so the socket path and wire behavior are unchanged there.

What has no equivalent on Windows is the access control. There is no umask, and os.Chmod only toggles the read-only attribute — it cannot express "owner may connect, nobody else," so the POSIX 0077/0600 lockdown has nothing to port to. The socket instead inherits the ACL of its containing directory, which makes socket security a property of where the caller puts it. The per-daemon directory the SDK creates under the user-scoped %TEMP% is ACL'd to the user by default and satisfies this. The Windows implementation documents that requirement rather than applying a mode that would look like a defense without being one.

Gate the parent-PID watchdog behind parentPidWatchdogSupported.

This compiled on Windows but could never fire. Windows does not reparent orphans, so a daemon whose parent exits keeps reporting the dead parent's PID forever — and because Windows recycles PIDs, that stale value may later belong to an unrelated process. Polling it is not free either: os.Getppid on Windows enumerates every process on the machine through a Toolhelp snapshot, twice a second, for a signal that never arrives.

Parent death stays covered by monitorStdin, which sees EOF as soon as the parent's pipe handle closes. That is the same fallback the POSIX build already relies on when ppid is ambiguous (a ppid of 1 — orphan vs. legitimate child of pid 1).

Also corrected the identity.json mode comment, since 0600 is a no-op on Windows. The document carries only a principal email and scope list, no secret, so inheriting the directory ACL alongside the socket is acceptable.

Testing

• windows/amd64, windows/386, windows/arm64 all build and go vet clean, including test files.
• file confirms the output: PE32 (i386), PE32+ (x86-64), PE32+ (Aarch64).
• Existing ./internal/accelerator/... tests pass on Linux; gofmt clean.

Scope

This makes the Go source cross-compile. Producing and shipping the Windows artifacts is a packaging change in the SDK that bundles the binary, and the spawn path there still needs to name the .exe.

There is also no CI guard against this regressing — nothing in .github/workflows/ cross-compiles today. A GOOS=windows go build step over amd64 + 386 would catch it, but that is shared repo-wide infra and felt out of scope here. Happy to add it if reviewers want it in this PR.

[gemini-code-assist]

Code Review

This pull request refactors the Unix domain socket binding and parent PID watchdog logic to support Windows. It extracts platform-specific socket creation and restriction logic into listenUDS across separate socket_unix.go and socket_windows.go files. It also introduces a parentPidWatchdogSupported constant to skip the parent PID watchdog on Windows, where process reparenting is not supported and polling is expensive. There are no review comments, and I have no additional feedback to provide.