Accepting the "non-flickering version" opt-in corrupts the native Windows CLI binary into bare Bun

Summary

Accepting the in-CLI prompt to try the new "non-flickering" version triggered a binary swap that left the native Windows CLI binary (~/.local/bin/claude.exe) in a broken state: instead of Claude Code, the binary now runs as the bare Bun runtime that Claude Code is compiled with. The Claude Code payload appears to be missing/not injected after the swap.

Symptoms

• claude --version → 1.4.0
• claude --help → prints Bun's help (Bun is a fast JavaScript runtime... (1.4.0+fe06227f0), with run/test/install/add commands)
• claude doctor → error: Script not found "doctor" (Bun interpreting doctor as a package script)
• Effectively, the terminal claude command no longer launches Claude Code at all.

Environment

• OS: Windows 11 Home (10.0.26200)
• Install: native installer (~/.local/bin/claude.exe)
• Healthy version (per the bundled VSCode extension binary): 2.1.193 (Claude Code)
• Node: v24.15.0

Timeline / cause

• The binary at ~/.local/bin/claude.exe was rewritten the morning I accepted the "non-flickering version" prompt.
• The normal update log (~/.claude/.last-update-result.json) only recorded a clean update the previous day (2.1.186 → 2.1.191) — i.e. the corrupting swap happened outside the normal updater path, immediately after accepting the opt-in.
• The corrupt and healthy binaries are byte-identical in size (231,359,136 bytes), consistent with a Bun-compiled SEA whose embedded Claude Code payload didn't survive the swap.

Workaround

Replaced ~/.local/bin/claude.exe with the healthy binary bundled in the VSCode extension (...anthropic.claude-code-<version>/resources/native-binary/claude.exe). claude --version then correctly reported 2.1.193 (Claude Code). (Re-running the official installer did not fix it — it reported success but never overwrote the corrupt file.)

Expected

The non-flickering opt-in should not be able to leave the CLI as bare Bun; a failed swap should roll back to the working binary.