Platform support evidence#
The completed engineering phase is the E3–E5 checkpoint . E4 source tests/vet/race and required non-skipped installer/lifecycle events passed on native Linux amd64, macOS arm64 and Windows amd64. macOS 15/26 before/after reductions prove the final-output repair; Linux retains immediate EOF and macOS retains the slave through bounded drain/cleanup. These source results are distinct from final release-byte qualification. Private v0.4.0-rc.2 completed its exact-byte three-host qualification; readiness and scope . Published v0.4.0-rc.2 passed native public archive/action, upgrade and binary-only checks on Linux amd64, macOS arm64 and Windows amd64; publication evidence . For those rc.2 bytes, wide-cell cursor layout and terminal-query-dependent flows remain explicitly unsupported; exact fidelity boundary .
Later development source corrects the selected two-column CJK rendering cases, with unchanged MICRO-08 and full tests/vet/race on native Linux amd64, macOS arm64 and Windows amd64. Development evidence does not extend the published rc.2 bytes. Combining clusters and terminal query round trips remain outside the rendering contract.
The new v0.4.0-rc.3 release record qualifies and verifies public bytes on Windows amd64, Linux amd64 and macOS arm64. The native build used macos-latest (macOS 26 image); qualification/public lanes also exercised macos-15. Recorded image identities remain distinct. Existing 120-workflow Windows-runner coverage includes separately labeled WSL target lanes; it is not a 120-by-three native application matrix. All 3,000 selected repeated attempts used the exact frozen host executable hashes. Complex Unicode and terminal queries remain excluded; no broader OS/framework claim is implied.
Stable v0.1.0 is verified on these native GitHub-hosted runners:
| Release target | Native runner | Terminal tests | Release package |
|---|---|---|---|
| Linux amd64 | ubuntu-latest | Passed | Passed |
| macOS arm64 | macos-latest | Passed | Passed |
| Windows amd64 | windows-latest | Passed | Passed |
The stable release
was built from commit 4ed8884e674f6a2625034850073b648d7a7b2aa2 by
native release run 34695578919
.
All three jobs built, packaged, checksum-verified, extracted, and exercised the
stable-version binary. The Linux and macOS jobs also passed a real target that
opens /dev/tty; all three jobs exercised cancellation against the extracted
binary. Terminal tests run 34695568888
passed at the same commit on all three hosts.
After publication, install run 34701451854 downloaded the public archives and checksum files, rejected deliberately corrupted copies, extracted into paths containing spaces, and passed version/help, pass, intentional failure, recovery, missing-target, invalid-spec, report-write failure, artifact, and cleanup checks without a Go runtime. Linux and macOS passed the controlling-terminal check. A separate download of all six public files matched the pre-publication workflow artifacts byte-for-byte. The archive hashes are recorded in the v0.1.0 release record .
The nine-application campaign was refreshed with the exact stable Linux and Windows binaries: all 18 intended cells and 54/54 frozen primary attempts passed with external oracles, fault/recovery, cancellation, cleanup, and second sessions. Two Windows Node applications initially produced an empty screen on one cold-start attempt; those attempts failed safely and cleaned up, unchanged diagnostics were recorded, and each frozen workflow then passed 3/3. During the Linux ipm-cli setup, Windows-installed dependencies were rejected and replaced with a native install of the same pinned package. These observations constrain the evidence; they are not claims of universal compatibility.
The terminal-test run
for commit bcd1b6e passed unit and real-PTY integration tests, vet, the demo specs, the pinned Charm Gum trial, the deliberate snapshot mismatch, and evidence upload on all three hosts. Its artifacts are terminal-evidence-ubuntu-latest, terminal-evidence-macos-latest, and terminal-evidence-windows-latest.
The historical Sprint 4 packaging run built and exercised binaries before packaging. It established the initial packaging path but did not execute the extracted archives.
The v0.1.0-rc.1 release run
closed that gap at commit 1dde372282a574025957c4bf1b603287cbef93e4. Each native job built and packaged the runner, verified its SHA-256 checksum and exact archive member list, extracted it into a path containing spaces, and invoked that extracted binary. Version/help output, passing specs, a deliberate snapshot_mismatch, its report, and screen/diff evidence passed before the assets were uploaded.
The published v0.1.0-rc.1 prerelease contains the three native archives and their checksum files. All six files were downloaded again through their public release URLs and matched the workflow artifacts byte-for-byte. The tag resolves to the commit above.
The repaired published-install run
downloaded rc.1 again and passed checksum rejection, spaced-path extraction, version/help, good → bad → recovered behavior, missing-target and invalid-spec handling, report-write failure, and cleanup on Linux amd64, macOS arm64, and Windows amd64. The run used workflow commit 9cf00e89f378703d66b6bc05978777c6dc8e2ec1. Its Unix /dev/tty gate was explicitly disabled because rc.1 is the known-bad baseline; this run validates installation behavior, not the missing controlling terminal.
A later real-application trial found that the rc.1 Linux asset does not provide a controlling terminal to targets that open /dev/tty directly. Lazygit v0.65.0 therefore exits during launch even though the original release fixture suite passed. That defect remains part of rc.1’s historical record.
The published v0.1.0-rc.2 prerelease
replaces those bytes. Native packaging run 34333242993
built it from 583352ad381df15f0fda652dae9ef819f5f24c9a; every native job exercised the extracted archive, and Linux and macOS passed a target that opens /dev/tty. Published install run 34333615063
then downloaded the public candidate with controlling-terminal verification enabled and passed on all three hosts. The public archives matched the workflow artifacts byte-for-byte.
Downloaded rc.2 passed natural exit, cancellation, total timeout, output limit, and descendant-cleanup release fixtures on Windows and Linux. Candidate-specific real-application evidence includes 10/10 primary attempts for each of Lazygit, Lazydocker, and K9s on both hosts, with independent exact-state oracles and no hidden retries. Supported broader paths covered Git state changes, Docker lifecycle changes, Kubernetes live YAML and pod mutation, help/resize, negative endpoints/APIs, empty state, and a fresh or reset second session per target and host. The compact Lazydocker v0.25.2 Linux help flow immediately after resizing to 80x24 remains excluded; resize-only and normal-viewport help passed. The candidate 60/60 sample remains separate from the historical six-cell campaign because its Linux runner came from a checkout.
The later R3c operator campaign used the extracted public rc.2 binaries with Posting, litecli, mitmproxy, bottom, GitUI, television, npkill, create-vite, and ipm-cli. All 18 intended Windows amd64 and WSL Linux amd64 cells completed, with 54/54 frozen primary attempts plus independent oracles, controlled failure/recovery, application and runner cancellation, confirmed cleanup, and second sessions. These results apply only to the pinned versions and workflows in that record. WSL Linux is not native Windows and is not a claim for every Linux distribution.
At this historical checkpoint Windows amd64 passed the local race detector; Linux/macOS race coverage had not yet been recorded. The current E4/E5 native source records above now include actual race runs on all three hosts.
Source at that historical checkpoint passed the complete three-host Terminal tests run
at commit 6c378a5cc34efb481bc61bd4ce1cad2862a82ef9. The immediately preceding failed run
is retained: it exposed a macOS cleanup exit race and a cold-start budget issue in the external Gum sample. Both causes were corrected before the green run.
This evidence supports only the targets in the table and the terminal behavior described in Terminal compatibility . It does not imply support for other architectures, every OS version or distribution, every CLI/TUI framework, or macOS real-application compatibility.