bitwarden: crashes on Linux — platform detection assumes macOS or Windows only

[fabioxd20]

Extension name

bitwarden

Description

The Bitwarden extension crashes immediately on Linux. The root cause is platform
detection that assumes only macOS and Windows exist, which produces three chained
failures.

1. Platform detection falls through to Windows

All 11 command bundles contain:

var X = process.platform === "darwin" ? "macos" : "windows";

On Linux process.platform is "linux", so it resolves to "windows". The
extension then downloads bw-windows-<version>.zip and tries to execute the
resulting .exe (a PE32+ binary):

/…/support/store.raycast.bitwarden/bw-2026.4.2.exe: 1: MZ…: not found
/…/support/store.raycast.bitwarden/bw-2026.4.2.exe: 2: Syntax error: ")" unexpected
Worker store.raycast.bitwarden:search exited with code 1

2. Hash validation has no Linux entry

After patching (1) so the platform resolves to "linux", it correctly downloads
bw-linux-<version>.zip, but the bundled hash table only covers macOS and
Windows, so validation rejects it:

EnsureCliBinError: Hash did not match, expected 1dc091b, got 431dbe7.

3. The fallback path is macOS-specific

When the download fails it falls back to installedBin, which is hardcoded:

installedBin(){ return X === "windows" ? "C:\\ProgramData\\chocolatey\\bin\\bw.exe"
                                       : process.arch === "arm64" ? "/opt/homebrew/bin/bw"
                                                                  : "/usr/local/bin/bw" }

giving InstalledCLINotFoundError: Bitwarden CLI not found at /usr/local/bin/bw.

Workaround

Patching all 11 bundles so that (a) the platform resolves to "linux",
(b) installedBin returns $HOME/.local/bin/bw, and (c) get bin() prefers
installedBin on Linux — skipping the download and hash check entirely — makes
the extension fully functional against a natively installed bw CLI.

One thing worth knowing for anyone scripting this: the minified name of the
platform variable differs per bundle (te, Q, G, B, W, ee, z, M…),
so a patch has to detect it per file rather than hardcode a single name.

Separate observation — self-hosted servers

With serverUrl set in the extension preferences, the extension still ran
bw login --apikey against the default bitwarden.com, failing with
client_id or client_secret is incorrect even though the API key was valid on
the self-hosted instance. The bundle does contain a bw config server call, but
it did not run in this flow. Running bw config server <url> directly inside the
extension's BITWARDENCLI_APPDATA_DIR resolved it. I was not able to isolate the
trigger, so please treat this as an observation rather than a confirmed
diagnosis — it may be specific to a first-run state.

Environment

Linux Mint 22.1 (Ubuntu 24.04 base), X11 / XFCE, x86_64. Bitwarden CLI 2026.8.0
installed natively; the extension pins CLI version 2026.4.2.

Tested on Raycast?

I didn't test on Raycast

Steps to reproduce

1. On Linux, install the bitwarden extension from the Raycast store via the Raycast compatibility store.
2. Set the required clientId / clientSecret preferences.
3. Launch any of its commands (e.g. Search).
4. The extension crashes immediately; the worker exits with code 1.

Vicinae version

0.26.3

[bl4zee1g]