Desktop 0.0.26 backend + CLI crash-loop on pre-AVX CPUs — ship Windows x64 `-baseline` Bun binaries

Cline Surface

Desktop App

Cline Version

0.0.26 (Desktop; CLI cline.exe bundles Bun 1.3.13)

Beta version

• I am using a beta version of Cline

What happened?

Desktop 0.0.26 backend + CLI crash-loop on pre-AVX CPUs — ship Windows x64 -baseline Bun binaries

Summary

Cline Desktop (and the cline CLI) are unusable on CPUs without AVX support because both bundle the standard (AVX2) build of Bun v1.3.13 instead of the -baseline build. The backend code-sidecar.exe crash-loops every ~4 minutes and never exposes its endpoint, so the desktop app is permanently stuck on "Connecting..." and sign-in fails. The CLI dies silently for the same reason.

Environment

• App: Cline Desktop 0.0.26 (Cline_0.0.26_x64-setup.exe, SHA256 verified e0687bb4…dab5a4a1), fresh clean reinstall
• OS: Windows 11 24H2, build 10.0.26100.8972 (ntdll.dll 10.0.26100.8972)
• CPU: Intel(R) Core(TM) i7 Q 740 @ 1.73GHz — Nehalem, SSE4.2, no AVX/AVX2
• WebView2 152.0.4191.66, 6 GB RAM, no third-party DLLs injected (verified module list), no AV drivers active

Repro

1. Install Cline Desktop 0.0.26 on a pre-AVX machine, launch it.
2. App shows "Connecting..." forever; clicking Sign in → "Waiting for browser..." → Sign in failed: Tauri invoke failed for get_desktop_backend_endpoint: desktop backend endpoint not ready. Browser never opens.
3. cline --version (npm CLI) prints nothing and the process dies.
4. Windows Error Reporting collects an AppCrash_code-sidecar.exe report roughly every 4 minutes while the app is open (16 reports in one day on my machine).

Evidence

Version strings extracted from the shipped binaries:

• code-sidecar.exe → Bun v1.3.13 (bf2e2cec) Windows x64 (no baseline tag; file version 1.3.13)
• cline.exe (CLI, @cline/cli-windows-x64) → Bun v1.3.13 (bf2e2cec) Windows x64 (same build; also crashes — 2 WER reports)
• opencode.exe on the same machine → Bun v1.3.14 (0d9b296a) Windows x64 (baseline) — zero crashes, works fine
• Cline VS Code extension on the same machine works fine (Node.js, no Bun involved)

Crash signature (Windows Event Log / WER), identical across reinstalls:

P1: code-sidecar.exe
P2: 1.3.13.0
P4: ntdll.dll (10.0.26100.8972)
P7: c0000005 (access violation)

Observed behavior of the sidecar before each crash: burns ~1+ CPU core with zero stdout output, zero TCP listeners, zero outbound connections (provable with Get-NetTCPConnection -OwningProcess <pid>), then faults. BUN_JSC_useJIT=0 does not prevent it (tested with guaranteed env propagation — still crashed at the ~4 min mark), so this is not just the JIT path; the standard 1.3.13 binary is broken on this CPU class, consistent with upstream oven-sh/bun#30613 (crashes on non-AVX2 CPUs in all versions after 1.3.8).

Notably, the binary even contains the string CPU lacks AVX support. P... — it detects the CPU but crashes anyway.

Expected fix

Ship the -baseline Windows x64 Bun build for code-sidecar.exe and @cline/cli-windows-x64 (what opencode already does), or feature-detect at install and pick the right binary like bun.sh/install does. At minimum, fail fast with a clear "CPU unsupported" message instead of an endless Connecting spinner.

Workarounds tried (all failed except switching products)

• Killed duplicate app/sidecar instances, clean reinstall with hash verification — crash loop persists
• BUN_JSC_useJIT=0 (user + process env) — still crashes on the same ~4 min cycle
• API-key sign-in instead of OAuth — unreachable, backend never becomes ready
• Only working option on this hardware: the VS Code extension

Steps to reproduce

Provider/Model

No response

Diagnostics

No response

System Information

No response