Win-CodexBar
Unblocked Windows devs on first-run setup.

the project
Win-CodexBar is a Rust-based Windows utility. First-run setup runs through a PowerShell script (setup-windows.ps1) that installs the Rust toolchain and MinGW for new contributors. I tried to install it on a clean Windows 11 box — the script refused to even parse.
the bug
PowerShell 5.1 — the default shell on Windows 10/11 — failed immediately with:
The string is missing the terminator: ".Confusing — there was no obviously-broken string in the source. Tracing it: PowerShell 5.1 falls back to ANSI (Windows-1252) when a file has no BOM, but the script contained UTF-8 characters in its decorative comment box. Bytes misinterpreted, parser broken.
the contribution
PR #6 — re-saved setup-windows.ps1 as UTF-8 with BOM (EF BB BF). PowerShell 5.1 now correctly interprets the file. No logic changes, no behavior changes, no surface-area expansion. The functional diff is three bytes.
Wrote up the root cause + verification steps + before/after screenshots in the PR description so the maintainer could merge with confidence. Merged same day.
why it mattered
First-run scripts are the highest-leverage code in any open-source project — they gate every new contributor and user. A 3-byte BOM stops a flood of “can't install” issues from Windows developers (the majority of the Windows dev population still defaults to PowerShell 5.1). Small fix, outsized funnel impact.
what this demonstrates
- Root-cause discipline. The error message pointed at a missing string terminator. The real cause was three layers down: shell default, file-encoding fallback, glyph misinterpretation.
- Minimum-surface fix. No script logic touched. Easy to review, easy to merge, low risk of regression.
- Cross-platform empathy. Most contributors run macOS or Linux where this never fires. Windows-default behavior is its own ecosystem; treating it as a first-class environment matters.