v0.3.0

Highlights

Major performance fix — Windows process pile-up. The status line no longer spawns dozens of subprocesses per render. Helpers now return through globals (printf -v) instead of $(...) subshells, and time formatting uses the printf '%(...)T' builtin. On Linux/macOS, where fork() is native, this was already cheap; on Windows, where Git Bash emulates fork(), it was catastrophic at refreshInterval: 1.

Measured before and after with the same script and input, 60 renders per group:

environment	before	after
macOS (native arm64), bash 3.2	61 ms	24 ms
macOS (native arm64), bash 5	64 ms	26 ms
Windows 11 ARM64 VM, Git Bash (bash 5.3)	1823 ms	366 ms

The Windows box is a Windows 11 ARM64 VM on a MacBook Air M5, with the x64 Git Bash running under Windows' x64 emulation, so it's a heavier case than native x64 Windows (two emulation layers). But that's also why it shows the bug so clearly: at 1.82s per render while Claude Code launches a new one every second, renders can't finish before the next starts, which is how a few minutes produced 15k+ processes. After the fix each render is ~0.37s, comfortably under a second, so nothing accumulates. On macOS, where fork() is native, it was never a pile-up — just a touch slower. Output is byte-identical, verified across pill/lean/auto/ASCII and bash 3.2 vs 5.

Also in this release

• New Dracula theme (thanks @redtear1115).
• project segment falls back to the current directory outside a git repo instead of disappearing — unless dir is already shown (thanks @redtear1115).
• Windows support documented: runs via Git Bash; a native PowerShell port for the no-Git-Bash case is on the roadmap (#8).

Thanks to @redtear1115 for two more contributions this release.