[BUG] Windows: claude.exe 2.1.221 fails to start — SyntaxError: Unexpected identifier 'atomi' (Bun v1.4.0 Windows x64 baseline)

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

After the automatic update to 2.1.221 on 2026-08-04, claude no longer starts on Windows. Every invocation — including claude --version — exits immediately with a JavaScript SyntaxError, before any CLI output. No file path, no code frame and no stack frames are printed.

The previously installed 2.1.220 binary, still present on the same disk under .local\share\claude\versions\, runs normally. Copying it over .local\bin\claude.exe fully restores the CLI — which is why I am not on the newest version right now: the newest version is the broken one.

The failure is independent of all user state. Each of the following was tested separately and the crash persisted in every case:

  • clean config dir: $env:CLAUDE_CONFIG_DIR = "C:\Temp\claude-clean"; claude --version
  • no shell profile: pwsh -NoProfile -Command "claude --version"
  • fresh environment, nothing inherited: Start-Process pwsh -ArgumentList '-NoProfile','-Command','claude --version' -UseNewEnvironment -Wait -NoNewWindow
  • outside any project directory: Set-Location C:\; claude --version

~/.claude.json parses cleanly, and no CLAUDE*, ANTHROPIC*, BUN* or NODE* environment variables are set on this machine.

On-disk state:

| File | Size (bytes) | Date |
|---|---|---|
| .local\bin\claude.exe | 278,279,328 | 2026-08-04 |
| versions\2.1.221 | 278,279,328 | 2026-08-04 |
| versions\2.1.220 | 265,720,480 | 2026-07-25 |
| versions\2.1.219 | 265,714,848 | 2026-07-24 |

2.1.221 is ~12 MB larger than 2.1.220, so this does not look like a truncated download. It is not established whether the 2.1.221 build is broken for everyone or whether the download was corrupted on this machine. The broken binary has been preserved; its SHA-256 is available on request.

What Should Happen?

claude should start normally on 2.1.221, as it does on 2.1.220.

Error Messages/Logs

PS C:\> claude --version
SyntaxError: Unexpected identifier 'atomi'. Expected either a closing ']' or a ',' following an array element.

Bun v1.4.0 (Windows x64 baseline)

Steps to Reproduce

  1. On Windows, let the CLI auto-update to 2.1.221 (native install, %USERPROFILE%\.local\bin\claude.exe).
  2. Run claude --version in any shell, from any directory.
  3. Observe the SyntaxError and immediate exit. 100% reproducible — every invocation, every shell.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.220

Claude Code Version

2.1.221

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

OS: Windows 11 Home Single Language 25H2 — build 10.0.26200.8973 (x64)
Shell: PowerShell 7.6.3
Install: native installer (%USERPROFILE%\.local\bin\claude.exe)
Broken version: 2.1.221 (auto-updated 2026-08-04)
Last working version: 2.1.220
Runtime: Bun v1.4.0 (Windows x64 baseline)

Which parser emits this message — reproduced outside Claude Code, on Bun 1.3.13:

| Code path | Message produced |
|---|---|
| JSON.parse(text) | SyntaxError: JSON Parse error: Expected ']' |
| Bun transpiler on a .js file | code frame + path + error: Expected "]" but found "atomi" |
| eval(...) / new Function(...) | SyntaxError: Unexpected identifier 'atomi'. Expected either a closing ']' or a ',' following an array element. |

Only the runtime string-parse path produces the observed message, and only that path produces it with no source path and no code frame. This points to a JavaScript string being parsed at runtime during startup — not a malformed JSON config, and not the transpiler loading a source file.

Minimal construction reproducing the exact string, including the atomi identifier:

new Function('const x = ["C:\\SomePath\\", "atomi-pack"];')

This is the classic Windows failure mode where a path ending in a backslash sits inside a quoted string in an array literal: the trailing backslash escapes the closing quote and the following word is parsed as a bare identifier. Offered as a plausible mechanism only — not confirmed against the shipped binary.

View original on GitHub ↗