Porting a tmux daemon to Windows in three days

tebis runs as a daemon that drives coding agents in tmux. In April I planned a Windows port. The plan mapped all 19 security invariants and estimated a phased rollout of five to seven weeks, “starting with a 1-hour psmux spike”. The Windows commits span 23 to 25 April.

psmux turned out to be “tmux-compatible in every dimension we exercise”, so the code’s Tmux type became Mux, with a binary per OS. The one quirk I found: psmux treats = literally.

Two choices were specific to Windows. The daemon runs from Task Scheduler instead of the Windows service manager, because it needs the user’s SID, %APPDATA% and Git Bash. The named pipe checks the caller’s token SID. A PID check was “explicitly rejected (Project Zero 2019: spoofable)”.

What the plan didn’t cover was the user’s whole journey: install, upgrade, uninstall. A review in May walked through it on purpose and found 9 lifecycle bugs. Among them: copying a running .exe over itself, a TLS enum missing on PowerShell 5.1, the 1,024-character limit in setx, and a fixed 2 s wait before the uninstaller deleted itself, which now retries for up to 30 s.

The same day, opt-level “z” cut the binary from 5.6 MB to 4.4 MB, and the pedantic clippy pass left CI. It “produced no actionable signal”, and macOS runner minutes cost “10× Linux minute rate”.