v2.1.116 crashes on Linux x64 with Bun CommonJS module error (regression of #45541)

Status Fixed / completed
Reported on v2.1.116
Maintainer reply None cached
Activity 4 comments · opened Apr 21, 2026 · closed Apr 22, 2026

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:

| Version | Works? |
|---|---|
| 2.1.90 | ✅ |
| 2.1.110 | ✅ |
| 2.1.112 | ✅ |
| 2.1.113 | ✅ |
| 2.1.114 | ✅ |
| 2.1.116 | ❌ crashes as above |

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.

View original on GitHub ↗

4 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/45541
  2. https://github.com/anthropics/claude-code/issues/12543
  3. https://github.com/anthropics/claude-code/issues/31345

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

michael-123123 · 5 months ago

Please don't auto-close — this is a regression, not a duplicate.

All three issues the bot flagged are closed and (in the case of #45541) locked:

  • #45541 — same crash, reported for v2.1.97, fixed in v2.1.100. This issue re-reports the same crash reappearing in v2.1.116 (v2.1.100–v2.1.114 all worked fine for me in between). Locked, so I can't comment there; that's why I filed a new issue per the auto-locking bot's own instructions.
  • #12543 — v2.0.55, closed Dec 2025.
  • #31345 — older Linux Bun exception, closed and stale.

Closing this as a duplicate of any of them means the current 2.1.116 regression has nowhere to be tracked. The issue body already states the regression relationship explicitly and lists the working/broken versions. Please keep it open.

michael-123123 · 5 months ago

Fixed in v2.1.117. Ran 2.1.117 --version and it exits cleanly — no Bun CJS-wrapper crash. Closing.

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.