feat: ship Windows binaries and fix broken install instructions

[husniadil]

Two independent user-facing gaps, both about the path between "CI is green" and "a user can actually install this".

1. Windows is built by CI but never shipped

ci.yml has built windows/amd64 on windows-latest with CGO_ENABLED=1 on every PR, and it passes — for example run 30671147270, job Build (windows, amd64, windows-latest) | success.

release.yml does not contain the string windows at all. Its matrix has four entries; the latest release (v0.0.11) accordingly has four archives, none for Windows.

So everything needed for Windows already exists — internal/app/runner_windows.go, the danieljoos/wincred dependency, the Credential Manager keyring backend documented in SSO.md:161 and CONFIGURATION.md:808 — and CI proves it compiles. Only the release matrix was missing.

go install is not a workaround here: the whole binary requires cgo (bitwarden/sdk-go wraps a Rust static lib), so a Windows user would need a mingw-w64 toolchain installed. The Bitwarden SDK does bundle internal/cinterface/lib/windows-x64/libbitwarden_c.a, so this is purely a packaging gap.

Change: one matrix entry (windows-latest, binary_name: sstart.exe), and a Windows-only archive step.

Windows gets a .zip rather than a .tar.gz — it is what Windows users expect, and the publish job's collector already globs *.zip alongside *.tar.gz. The archive step is split by OS rather than made conditional inline, so the existing four targets keep their exact current code path and cannot regress. Compress-Archive is used because it is guaranteed present on the runner image, unlike zip(1).

2. Every install command in the README returns 404

This one is independent of Windows and affects everyone today:

sstart_Linux_x86_64.tar.gz    HTTP 404
sstart_Darwin_x86_64.tar.gz   HTTP 404
sstart_Darwin_arm64.tar.gz    HTTP 404

Correction to an earlier revision of this description: I first wrote that these URLs also pointed at the wrong repository. That was wrong, and I want to be precise since it changes the diagnosis.

dirathea/sstart is not a separate repository — it is a redirect. The repo was transferred into the securestart org and GitHub keeps the old path working (GET /repos/dirathea/sstart → 301 → full_name: securestart/sstart). My initial check used curl without -L, so the 301 body simply had no tag_name and I misread it as "no releases". Releases resolve fine through the redirect:

https://github.com/dirathea/sstart/releases/download/v0.0.11/sstart-0.0.11-linux-amd64.tar.gz   HTTP 200
https://github.com/dirathea/sstart/releases/latest/download/sstart_Linux_x86_64.tar.gz          HTTP 404

So there is exactly one cause, not two: the filenames are wrong. The README uses goreleaser-style names (sstart_Linux_x86_64.tar.gz); the workflow produces sstart-<version>-<os>-<arch>.tar.gz. The 404 reproduces against securestart directly, so the repo path was never the issue.

There is also a structural problem independent of naming: because asset names embed the version, releases/latest/download/<name> can never resolve for any filename. The instructions now read the latest tag first, then build the URL.

The README links are updated to securestart/sstart anyway — it is the canonical location and does not depend on a redirect being kept alive — but that part is cosmetic, not the fix.

linux-arm64 was also shipped but undocumented, so ARM users had no idea it existed. Now listed.

The go install line still points at dirathea/sstart — that is the Go module path and it resolves correctly (all tags v0.0.1–v0.0.11 are on the module proxy), so I left it alone. If the intent is to move the module path to securestart, that is a separate change.

Verification

The new bash snippet was extracted verbatim from the README and executed:

resolved: VERSION=0.0.11 OS=darwin ARCH=arm64
sstart version v0.0.11 (commit: 8fdfb86..., built: 2026-01-19T21:43:57.109Z)

An earlier draft of that snippet mis-parsed the tag; it was caught by running it, and the committed version is the one that works.

release.yml parses as valid YAML and each archive step carries exactly one branch of the OS condition, so no target is skipped or double-handled.

What I could not verify: the PowerShell archive step. release.yml only triggers on tag push, so nothing exercises it until an actual release, and I have no Windows/pwsh environment. I kept it deliberately plain for that reason — $ErrorActionPreference = 'Stop', explicit .FullName, no .NET type usage — but it deserves a careful read, or a throwaway tag on a fork to confirm before relying on it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Hmh2p2Bg6kmxxvzpFDW2WL