Bundled vale-ls in v0.32.0 is macOS/arm64; breaks Linux x86_64 (exit code 126)

[roldanbob]

Describe the bug
The extension v0.32.0 bundles a vale-ls binary for macOS (Mach-O arm64) but the release is installed on Linux x86_64. On Linux the language server fails with "cannot execute binary file" and exits with code 126, causing the extension to repeatedly crash.

To reproduce

1. Install ChrisChinchilla.vale-vscode v0.32.0 on a Linux x86_64 machine.
2. Open a file that triggers Vale; check Output → Vale.
3. Observe the server failing to start.

Relevant logs

Server process exited with code 126
/home/<user>/.vscode/extensions/chrischinchilla.vale-vscode-0.32.0/vale-ls: cannot execute binary file
Cannot call write after a stream was destroyed

Environment

• OS: Fedora Linux x86_64
• Extension: chrischinchilla.vale-vscode v0.32.0

Workaround I used
I backed up the bundled asset to ~/.vscode/extensions/chrischinchilla.vale-vscode-0.32.0/vale-ls.macho-arm64.bak and replaced it with the x86_64 vale-ls from the official errata-ai/vale-ls releases. After that the language server started successfully.

Suggested fix

• Include proper platform binaries for Linux x86_64, or
• Allow an extension setting to override the vale-ls path, or
• Improve packaging CI so the packaged binary matches the target platform.

Thanks for the extension; happy to provide more logs or commands if helpful

[dosubot]

Hi @roldanbob! I'm Dosu and I’m helping the vale-vscode team.

You're right about the cause—if the extension bundles or downloads a macOS/arm64 vale-ls binary on Linux x86_64, it can't run and fails with exit code 126. The extension is designed to detect your platform and architecture at runtime and fetch the correct binary from the official errata-ai/vale-ls releases, but if the wrong binary is present, it will crash repeatedly. There's currently no setting to override the vale-ls binary path, and the README confirms this limitation while noting the author is seeking a solution (source). Your workaround—replacing the binary manually—is the best option for now.

No recent pull requests address platform-specific binary bundling or CI improvements, so monitoring future updates is recommended. Your suggestions (proper platform binaries, path override, improved packaging) are all valid and align with best practices for VSCode extensions.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}