[BUG] claude.exe crashes with ACCESS_VIOLATION (0xc0000005) on Windows, repeatable, same code offset

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?

claude.exe repeatedly crashes on Windows with a native access-violation exception. The crash is caught by Windows Error Reporting (Application Error, Event ID 1000), not by Node/V8 — there is no "JavaScript heap out of memory" message, and system memory is not exhausted (32GB total, ~20GB free at crash time). The crash happens roughly every 7–10 minutes during an active session, including mid-way through running /doctor. After the crash, the terminal is left with mouse-tracking escape sequences leaking to the console (e.g. [555;151;22M), suggesting the process died before it could restore console mode.

What Should Happen?

claude.exe should not crash, or should at minimum fail gracefully (clean up console mode, exit without an unhandled access violation) instead of terminating via an unhandled native exception.

Error Messages/Logs

Faulting application name: claude.exe, version: 2.1.227.0, time stamp: 0x6a61a193
Faulting module name: claude.exe, version: 2.1.227.0, time stamp: 0x6a61a193
Exception code: 0xc0000005
Fault offset: 0x000000000381234e
Faulting application path: %APPDATA%\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe

--- second occurrence, ~9 minutes later ---
Faulting application name: claude.exe, version: 2.1.227.0, time stamp: 0x6a61a193
Faulting module name: claude.exe, version: 2.1.227.0, time stamp: 0x6a61a193
Exception code: 0xc0000005
Fault offset: 0x0000000003812368

Note: the two fault offsets are only 26 bytes apart, and the faulting module is `claude.exe` itself (not a system DLL) in both cases — this points to a specific, repeatable code path rather than random memory corruption.

Steps to Reproduce

1. Run claude interactively on Windows in an environment where one or more third-party processes inject Win32 API-hooking DLLs into every process (common with enterprise endpoint-security/DRM agents and Citrix HDX virtualization client components — see Additional Information below for the exact DLLs observed).
2. Use Claude Code normally, or leave a session idle/active for several minutes.
3. Within roughly 7–10 minutes, claude.exe terminates unexpectedly. Windows Event Viewer (Application log) shows an Event ID 1000 "Application Error" with Exception code 0xc0000005, faulting module claude.exe.
4. This also happens mid-execution of /doctor.

I don't have a minimal, non-corporate-environment repro yet — flagging this as environment-dependent (see below), but the consistent fault offset suggests it's a genuine bug in claude.exe's own code, likely triggered when a hooked Win32 API (possibly console-mode related, given the mouse-tracking leftover artifacts) is called.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.227 (claude --version)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

This machine is a corporate-managed Windows 11 endpoint. Inspecting the loaded modules of the running claude.exe process (via Get-Process -Module) shows several third-party Win32 API-hooking DLLs injected into the process, beyond standard Windows/Node system DLLs:

• Citrix HDX client hooks: Citrix.Hdx.Seamless.Hooking.dll, CxInjIme.dll, FullScreenHook.dll, MfApHook.dll, PicaWtsHook.dll, SCardHook.dll, ShellHook.dll (all under C:\Program Files\Citrix\HDX\bin\)
• A document-DRM agent's hooking DLLs under C:\Windows\pcdrm\ (names like NBID64.dll, NFD0164.dll, NFD0264.dll, NSC*.dll) — vendor name withheld, this is an internal corporate security tool
• A print-security agent's hooking DLLs under C:\PAPERSECU\ (names like PAPERHK64.DLL, PAPERPHK64.DLL, SPCOREHK64.DLL) — vendor name withheld

The naming convention (*Hook*, *HK*) indicates these all do inline/IAT API hooking. claude.exe's InternalName in its version resource is bun, i.e. it's a Bun-compiled single-executable binary. My working theory is that one of these hooks intercepts a Win32 API that claude.exe calls (a console-mode-related call is my best guess, given the leftover mouse-tracking escape codes after the crash), and the hook's trampoline is incompatible with how Bun's compiled/JIT code makes that call, causing the return address to end up corrupted or landing in unmapped/invalid memory inside claude.exe's own code — which is why Windows reports the fault as being inside claude.exe itself at a consistent offset.

I'm also reporting this internally to have our security team check whether these agents have known compatibility issues with Node/Bun-based CLI tools, but wanted to flag it here in case this reveals a genuine bug in claude.exe's Windows console handling that's simply triggered by API hooking (rather than being purely an environment problem) — e.g., if a Win32 call isn't checking a return value or is making an assumption about calling-convention/register state that a hooking trampoline can legitimately violate.

Happy to provide the raw Windows Error Reporting report (crash dump) if that would help — I've stripped the report IDs and hostname from this write-up for privacy but can share the dump directly if useful.