claude-code - 💡(How to fix) Fix v2.1.116 crashes on Linux x64 with Bun CommonJS module error (regression of #45541) [4 comments, 3 participants]

Summary

claude crashes immediately on startup in v2.1.116 with a Bun TypeError: Expected CommonJS module to have a function wrapper. Looks like a regression of #45541 (reported for v2.1.97, fixed in v2.1.100). That issue is closed+locked, so filing a new one per the bot's instruction.

Error output (raw, as the user sees it)

$ claude
 6 |     "use strict";
 7 |
 8 |     //
 9 |     if (entry.instantiate)
10 |         return entry.instantiate;
11 |     var instantiatePromise = (async () => {
                                               ^
TypeError: Expected CommonJS module to have a function wrapper. If you weren't messing around with Bun's internals, this is a bug in Bun

Bun v1.3.13 (Linux x64 baseline)

Reproduction

1. Be on the auto-update channel running a working 2.1.11x build.
2. The in-process auto-updater (part of claude itself) fetches 2.1.116 into ~/.local/share/claude/versions/2.1.116 and flips the ~/.local/bin/claude symlink to it.
3. Open a new terminal, run claude — crashes before printing any Claude Code output. Happens regardless of CWD, repo, or config.

100% reproducible on my machine.

Versions I have on disk

All installed via the native installer's auto-updater:

Rolling the ~/.local/bin/claude symlink back to 2.1.114 restores a working CLI, so this is isolated to the 2.1.116 build itself — not a user-config or environment issue.

Environment

• OS: Ubuntu 22.04 (kernel 6.8.0-106-generic)
• Arch: x86_64
• CPU: 12th Gen Intel Core i7-1255U — has AVX2 and BMI2 (verified via /proc/cpuinfo). So the Linux x64 baseline label in the Bun error refers to the baseline Bun build shipped inside 2.1.116, not to a missing CPU feature on the host.
• Install method: native installer (curl -fsSL https://claude.ai/install.sh | bash), binary at ~/.local/bin/claude → ~/.local/share/claude/versions/2.1.116 (ELF, Bun-compiled).
• Shell: bash
• No unusual env: node/npm not aliased to bun, $BUN_INSTALL not in PATH. The crashing Bun is the one embedded inside the Claude Code ELF itself.

Relationship to #45541

Same crash site, same Bun error message. #45541 was reported for 2.1.97 and confirmed fixed in 2.1.100. 2.1.110–2.1.114 were fine for me. Re-appears in 2.1.116 — suggesting the fix for #45541 regressed, or a new code path is tripping the same Bun CJS-wrapper issue.

Why the impact is larger than it looks

The in-process auto-updater means that any long-running claude session on a user's machine can silently flip the symlink to 2.1.116, bricking all new terminals. Even users who pin their env to DISABLE_AUTOUPDATER=1 after 2.1.116 lands will keep getting re-broken by their pre-existing sessions (which were started without that env var). The only safe workarounds on the user side are: kill every running claude process, manually re-pin the symlink each time it flips, or delete 2.1.116 from disk.

Suggested follow-ups

• Yank 2.1.116 from the auto-update channel until a fixed build is available — everyone on the default baseline-Bun native-installer build gets their CLI broken with no warning, and the in-process updater propagates the break even to users who haven't explicitly updated.
• Investigate whether the baseline-Bun build used for 2.1.116 was bumped (and hit a Bun regression), or whether new CJS-wrapped code re-triggers the #45541 path.
• Consider adding a preflight ./binary --version smoke check in the updater before it commits the new symlink, so a build that can't even start its own process never replaces a working one.

User-side workaround

# Re-pin to the last working version
ls ~/.local/share/claude/versions/
ln -sfn ~/.local/share/claude/versions/2.1.114 ~/.local/bin/claude

# Set DISABLE_AUTOUPDATER=1 in your shell profile so *new* sessions don't flip it back.
# Caveat: pre-existing long-running claude sessions still have the old env and can
# re-flip the symlink on their own update timer — kill them, or keep re-pinning.