Summary
flow is macOS-only today. This issue proposes — and tracks — a
full-parity Windows port, opened per CONTRIBUTING's "discuss before
sending code" rule for out-of-scope platforms.
Current state
There are no build tags and no runtime.GOOS branching anywhere in
the tree; the session-spawn layer is entirely AppleScript-based.
Won't compile for GOOS=windows:
internal/app/auto.go — syscall.SysProcAttr{Setsid: true},
proc.Signal(syscall.Signal(0)), syscall.EPERM
internal/app/owner_tick.go — syscall.SysProcAttr{Setsid: true}
Compiles but fails at runtime:
- Process-table scans via
ps -axo (iterm.go, terminal.go,
harness/claude/claude.go) — powers the live-session guard + focus
- Terminal backends are all
osascript (iterm/terminal/warp/ghostty);
warp also uses macOS open
spawner.Detect() falls through to iTerm for unknown env
ShellQuote is POSIX single-quote; EncodeCwd assumes /-paths
- Owners scheduler doc covers launchd/systemd/cron only
In our favor: pure-Go SQLite (no CGO → trivial cross-compile),
filepath.Join + os.UserHomeDir() throughout, clean Harness
interface, and FLOW_TERM=bg background mode already bypasses
terminals entirely.
Proposed plan
- Phase 0 — compile on Windows: extract the two Setsid/liveness
sites behind a setDetached/processAlive seam (proc_unix.go /
proc_windows.go). Add a GOOS=windows cross-compile CI gate.
- Phase 1 — background mode runs on Windows: OS-aware
spawner.Detect(), Windows-correct EncodeCwd, notepad editor
default.
- Phase 2 — interactive backend:
internal/winterm driving
Windows Terminal (wt.exe); Windows-aware ShellQuote.
- Phase 3 — process-scan parity (replace
ps -axo).
- Phase 4 — distribution (
flow-windows-{amd64,arm64}.exe),
Task Scheduler for owners, windows-latest in CI, scope-statement
updates (README / CONTRIBUTING / CLAUDE.md).
Open questions
- How does Claude Code encode a Windows cwd into
~/.claude/projects/<dir>? EncodeCwd must match exactly — needs
empirical verification on Windows.
- Does the SessionStart
hookCommand fire correctly on Windows?
(Must not rename it — orphans existing installs.)
- Live-session guard: full cmdline scan vs. graceful degrade for MVP?
Summary
flow is macOS-only today. This issue proposes — and tracks — a
full-parity Windows port, opened per CONTRIBUTING's "discuss before
sending code" rule for out-of-scope platforms.
Current state
There are no build tags and no
runtime.GOOSbranching anywhere inthe tree; the session-spawn layer is entirely AppleScript-based.
Won't compile for
GOOS=windows:internal/app/auto.go—syscall.SysProcAttr{Setsid: true},proc.Signal(syscall.Signal(0)),syscall.EPERMinternal/app/owner_tick.go—syscall.SysProcAttr{Setsid: true}Compiles but fails at runtime:
ps -axo(iterm.go,terminal.go,harness/claude/claude.go) — powers the live-session guard + focusosascript(iterm/terminal/warp/ghostty);warpalso uses macOSopenspawner.Detect()falls through to iTerm for unknown envShellQuoteis POSIX single-quote;EncodeCwdassumes/-pathsIn our favor: pure-Go SQLite (no CGO → trivial cross-compile),
filepath.Join+os.UserHomeDir()throughout, cleanHarnessinterface, and
FLOW_TERM=bgbackground mode already bypassesterminals entirely.
Proposed plan
sites behind a
setDetached/processAliveseam (proc_unix.go/proc_windows.go). Add aGOOS=windowscross-compile CI gate.spawner.Detect(), Windows-correctEncodeCwd,notepadeditordefault.
internal/wintermdrivingWindows Terminal (
wt.exe); Windows-awareShellQuote.ps -axo).flow-windows-{amd64,arm64}.exe),Task Scheduler for owners,
windows-latestin CI, scope-statementupdates (README / CONTRIBUTING / CLAUDE.md).
Open questions
~/.claude/projects/<dir>?EncodeCwdmust match exactly — needsempirical verification on Windows.
hookCommandfire correctly on Windows?(Must not rename it — orphans existing installs.)