plumb has only been validated on macOS and Linux. Windows is not supported yet — and we'd love help from someone who runs Windows to (a) confirm exactly where it breaks today and (b) chip away at the port. This is a great issue if you're comfortable with Go on Windows.
Heads-up: the daemon will not start on Windows today
Two core pieces are POSIX-only:
- The MCP wire is a Unix domain socket —
net.Listen("unix", …) in internal/cli/daemon.go (both plumb.sock and the plumb.ctrl.sock admin socket), dialled across serve.go/restart.go/log_level.go/doctor_checks.go. There's no named-pipe / AF_UNIX path yet.
- Singleton + session locking is
syscall.Flock — internal/cli/lock.go (spawn + daemon locks) and internal/session/session.go (session-file read-modify-write). Flock is POSIX-only.
What we believe already works cross-platform (please confirm)
- Base-dir resolution via
internal/paths + adrg/xdg (%AppData% / %LocalAppData%)
- Binary discovery via
exec.LookPath (honours PATHEXT, so gopls → gopls.exe)
file:// URIs for drive letters (protocol.FileURI: C:\x → file:///C:/x)plumb setup claude-desktop (writes to %APPDATA%\Claude\)
Known rough spots beyond the blockers
- The process monitor is a no-op stub (
internal/monitor/process_windows.go)
- Most non-Claude-Desktop
plumb setup <client> targets write home dotdirs (~/.cursor, …) rather than %AppData%
- A couple of daemon tests already
t.Skip on Windows (restart_test.go, daemon_test.go)
How to help (any of these is valuable)
- Build & smoke-test —
go build ./... on Windows 10/11 (amd64). Does it compile? Report any build breaks.
- Map the runtime breakage precisely — run
plumb daemon, plumb serve, plumb doctor and paste the exact errors + where they originate (we expect the Unix-socket bind to fail first).
- Confirm the "should-work" list above (paths,
LookPath/PATHEXT, FileURI, setup claude-desktop).
- Stretch — port the blockers: a Windows transport (named pipe or Win10+
AF_UNIX) behind an OS-abstracted listener/dialer, and a Windows file-lock (LockFileEx, or a small lib) behind a build-tagged lock_windows.go / lock_unix.go. Happy to advise on the seam.
Please include: Windows version + build, Go version, and full command output. Comment here to claim a piece so we don't overlap.
plumb has only been validated on macOS and Linux. Windows is not supported yet — and we'd love help from someone who runs Windows to (a) confirm exactly where it breaks today and (b) chip away at the port. This is a great issue if you're comfortable with Go on Windows.
Heads-up: the daemon will not start on Windows today
Two core pieces are POSIX-only:
net.Listen("unix", …)ininternal/cli/daemon.go(bothplumb.sockand theplumb.ctrl.sockadmin socket), dialled acrossserve.go/restart.go/log_level.go/doctor_checks.go. There's no named-pipe / AF_UNIX path yet.syscall.Flock—internal/cli/lock.go(spawn + daemon locks) andinternal/session/session.go(session-file read-modify-write).Flockis POSIX-only.What we believe already works cross-platform (please confirm)
internal/paths+adrg/xdg(%AppData%/%LocalAppData%)exec.LookPath(honoursPATHEXT, sogopls→gopls.exe)file://URIs for drive letters (protocol.FileURI:C:\x→file:///C:/x)plumb setup claude-desktop(writes to%APPDATA%\Claude\)Known rough spots beyond the blockers
internal/monitor/process_windows.go)plumb setup <client>targets write home dotdirs (~/.cursor, …) rather than%AppData%t.Skipon Windows (restart_test.go,daemon_test.go)How to help (any of these is valuable)
go build ./...on Windows 10/11 (amd64). Does it compile? Report any build breaks.plumb daemon,plumb serve,plumb doctorand paste the exact errors + where they originate (we expect the Unix-socket bind to fail first).LookPath/PATHEXT,FileURI,setup claude-desktop).AF_UNIX) behind an OS-abstracted listener/dialer, and a Windows file-lock (LockFileEx, or a small lib) behind a build-taggedlock_windows.go/lock_unix.go. Happy to advise on the seam.Please include: Windows version + build, Go version, and full command output. Comment here to claim a piece so we don't overlap.