[BUG] Windows: incomplete Claude Code update leaves two versioned runtime folders under `%APPDATA%\Claude\claude-code\`, causing a deterministic Bun segfault at Code startup (every session)

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?

Preflight

• I searched existing issues. This is related to but distinct from #62690 (stale versioned claude-code runtime folder → app appears to have multiple installed versions). #62690 reports version-resolution confusion; this report describes the same two-folder state producing a deterministic startup crash of the in-app Code feature. Cross-referencing rather than duplicating.
• Single bug report.
• Reproduced on the latest version available to me (Claude for Windows desktop 1.15962.1, embedded Claude Code 2.1.187).

What's wrong

After an overnight background auto-update, the Code feature inside Claude for Windows began crashing at startup with a Bun segmentation fault. The crash happens during initialization, before any session loads: every session failed identically — newly created ones and previously saved ones alike. The main Chat and Cowork UI opened normally; only Code was affected.

Crash signature reported by the in-app error reporter:

Bun v1.4.0 ... on windows x86_64 [(pre-init)]
Segmentation fault at address 0xFFFFFFFFFFFFFFFF

The same desktop version (1.15962.1 / Code 2.1.187) runs without any problem on a second machine, which rules out the build itself being universally broken.

Root state on disk (the likely cause)

Under %APPDATA%\Claude\claude-code\ there were two coexisting versioned runtime folders:

%APPDATA%\Claude\claude-code\2.1.181\   (claude.exe)
%APPDATA%\Claude\claude-code\2.1.187\   (claude.exe, .verified)

After a clean update, the previous version directory should normally be removed. The presence of both is the fingerprint of a 2.1.181 → 2.1.187 update that did not finish cleanly (binary written, but the final verify / cleanup step apparently not completed). This stale two-folder state correlates with the failure and is the leading lead — but see the Reproduction section: relaunching with two version folders present did NOT reproduce the crash, so two coexisting folders are demonstrably not sufficient on their own to trigger it. The exact trigger in the original post-update state is unconfirmed.

This persisted across a full reinstall of the desktop app, because reinstalling does not clear %APPDATA%\Claude\claude-code\. That is a significant part of the bug: an end user cannot recover by reinstalling, and there is no surfaced error pointing at the stale runtime.

Environment

| | Failing machine | Working machine |
|---|---|---|
| OS | Windows 11 | Windows 10 |
| CPU | AMD Ryzen 5 5500 (Zen 3) | Intel i5-4460 (Haswell) |
| Desktop app | 1.15962.1 (1e236d) | 1.15962.1 (1e236d) |
| Embedded Code | 2.1.187 | (works) |
| Result | Code segfaults at startup | Code works |

Note the failing machine is the newer/more capable one, and antivirus was fully disabled during testing — so neither hardware capability nor AV is the cause.

Steps taken and results (in order)

1. Full quit + kill all Claude.exe processes, reboot PC → no effect.
2. Antivirus real-time protection fully disabled → no effect.
3. Reinstall desktop app via the web installer → no effect (does not touch %APPDATA%\Claude\claude-code\).
4. Cleared Electron caches under %APPDATA%\Claude\ (Cache, Code Cache, GPUCache) → no effect. (Recorded only as a step that was attempted. This did NOT resolve the problem — the crash persisted unchanged afterward. The issue was fixed later, in step 5.)
5. Discovered the two versioned folders (2.1.181 + 2.1.187). Renamed 2.1.187\claude.exe and 2.1.187\.verified to .bak, copied 2.1.181\claude.exe into the 2.1.187 folder, and launched.

• On relaunch, the end state was a single 2.1.187\ folder with a freshly written .verified and claude.exe reporting 2.1.187.0; the 2.1.181\ folder was no longer present. (I did not directly observe what removed it, so I'm not attributing this to an automatic self-repair.)
• Code started working again. All sessions work.

The fix appears to be the rename + copy + relaunch sequence; the exact internal mechanism is unconfirmed.

Reproduction attempt (could NOT reproduce — and two coexisting folders did not trigger the crash)

I tried to reproduce the crash afterward by recreating a 2.1.181 folder next to the working 2.1.187 and relaunching the desktop app. It did not crash: Claude Code started and worked normally with both version folders present. I then deleted the recreated 2.1.181 folder manually, by hand, while Claude was running — it was not removed by any launcher self-repair on this occasion.

This is an important negative result: the mere coexistence of two versioned runtime folders is not, by itself, sufficient to trigger the startup crash. If it were, this relaunch would have crashed as well. Whatever caused the original failure was something more specific about that particular post-update state, which I have not been able to isolate or reproduce.

Fidelity caveats: by this point the machine had already been through the original fix (step 5) and an earlier Electron cache clear (step 4 — which, to be clear, did not fix anything; the crash persisted unchanged after it). So the on-disk/local state was no longer in its original pre-fix condition, and a perfectly clean reproduction was not possible.

What remains solid:

• The crash was real, deterministic, machine-specific, and survived reboot + reinstall + AV-disable + cache-clear.
• The fix is cleanly attributable to step 5 (stop Code, rename the 2.1.187 claude.exe/.verified, copy the 2.1.181 claude.exe in, restart — after which the 2.1.181 folder was gone and .verified had been rewritten).
• The exact original trigger is unconfirmed. The incomplete-update / two-folder state is the leading correlate but is demonstrably not sufficient on its own.

Suggested follow-ups for the team

• Make the auto-updater atomic / guarantee removal of the previous %APPDATA%\Claude\claude-code\<old-version>\ folder once the new version is verified, so the post-update state is always clean (two coexisting runtime folders should never be a normal outcome, even if they are not by themselves sufficient to crash).
• Surface a clear error (and a "repair / re-verify runtime" action) when Code fails to initialize, instead of an opaque Bun pre-init segfault.
• Have reinstall of the desktop app clear or re-verify %APPDATA%\Claude\claude-code\ so users can self-recover.
• Cross-reference #62690 (same stale-versioned-runtime phenomenon, different symptom).

What Should Happen?

The 2.1.181 → 2.1.187 auto-update should complete cleanly and atomically: the new runtime verified and the previous version folder removed, leaving a single %APPDATA%\Claude\claude-code\<version>\. Code should initialize and start normally for every session, never segfaulting at Bun pre-init.

If the on-disk runtime state is ever left inconsistent by an incomplete update, the launcher should detect and repair it (or surface a clear, actionable "repair / re-verify runtime" error) instead of an opaque segfault — and reinstalling the desktop app should be able to recover the user, since it currently does not clear %APPDATA%\Claude\claude-code\.

Error Messages/Logs

Bun v1.4.0 ... on windows x86_64 [(pre-init)]
Segmentation fault at address 0xFFFFFFFFFFFFFFFF

Steps to Reproduce

IMPORTANT: this is an incomplete-update state that I could NOT deterministically reproduce after the fact — see the "Reproduction attempt" section in the description for the full caveat. The sequence that originally produced the crash:

1. Have Claude for Windows installed with embedded Claude Code 2.1.181 (working).
2. Let the app auto-update in the background overnight to 2.1.187.
3. The update left two coexisting versioned runtime folders under %APPDATA%\Claude\claude-code\ (2.1.181\ and 2.1.187\) — the fingerprint of an update that did not finish cleanly.
4. Open the desktop app and select the Code feature → it segfaults at Bun pre-init, before any session loads. Every session fails identically (new and previously saved). Chat and Cowork still open normally.

Fix that worked (step 5 in the description): stop Code, rename 2.1.187\claude.exe and 2.1.187\.verified to .bak, copy 2.1.181\claude.exe into the 2.1.187 folder, and relaunch — after which the end state was a single 2.1.187\ folder with a freshly rewritten .verified and the 2.1.181\ folder no longer present, and Code starts working again. (I did not directly observe what removed the 2.1.181\ folder.)

Note: manually recreating the two-folder state afterward did NOT reproduce the crash, so the exact trigger within the incomplete-update state is unconfirmed (details in the description).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.181

Claude Code Version

2.1.187 (Claude Code) — embedded in Claude for Windows desktop 1.15962.1 (1e236d)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_