[BUG] Native binary segfaults within ~2 seconds while nProtect GameGuard (Helldivers 2) is running — GameGuard module confirmed in crash stack

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 Code segfaults reliably whenever Helldivers 2 is running. The game bundles nProtect GameGuard, an anti-cheat that scans and injects into other processes system-wide.

This is not intermittent. Four reproductions, three deliberate. With the game running, Claude Code cannot stay alive — it dies about two seconds after launch. Not degraded: unusable.

What Should Happen?

No crash

Error Messages/Logs

============================================================
Bun v1.4.0 (63bb0ca0d) Windows x64 (baseline)
Windows v10.26200
CPU: sse42 avx avx2
Args: "C:\Users\Main\.local\bin\claude.exe" "--model" "opusplan" "--effort" "high"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) fetch(3) jsc spawn(12) standalone_executable yaml_parse(2) claude_code
Elapsed: 2182ms | User: 687ms | Sys: 359ms
RSS: 0.31 GB | Peak: 0.31 GB | Commit: 0.45 GB | Faults: 82516 | Machine: 34.14 GB
panic(thread 14696): Segmentation fault at address 0x3C
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Crash report: https://bun.report/1.4.0/e_163bb0camgggkEugogCCYnpggNT64.desy2TCYnpggNT64.desynouE_A2A4D

The encoded stack names the external module. It contains npggNT64.des twice — the injected 64-bit component of GameGuard. The equivalent positions in an unrelated Windows Bun crash trace contain ntdll.dll. GameGuard code was executing inside the Claude Code process at fault time. This is confirmed injection into your shipped binary, not inference from timing.

The stack is identical across crashes with completely different process state. The 2,182 ms crash above and the 4,844,218 ms crash produced the same fault address (0x3C) and byte-identical bun.report URLs, despite different resident set size (0.31 GB vs 0.43 GB) and an order of magnitude difference in page faults (82,516 vs 1,000,782). That points at a single deterministic failure point rather than accumulated corruption — something is blocked the moment it is attempted.

0x3C is a small offset off a null base, consistent with an allocation or page-protection call returning null and being dereferenced unchecked. JavaScriptCore's JIT allocates pages and re-marks them executable at runtime, which is difficult for a process scanner to distinguish from code injection.

Steps to Reproduce

Fastest path (~2 seconds):

Launch Helldivers 2 (Steam) and enter gameplay.
Start Claude Code from a terminal.
Segfault at roughly 2,182 ms.

Also reproduces in the other direction:

Start a Claude Code session and leave it running.
Launch Helldivers 2.
Segfault. In my case after roughly 80 minutes of session uptime.

Neither reproduces with the game closed.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

Unknown. I have only ever run Bun-backed builds on this machine.

Claude Code Version

2.1.201 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Summary. Claude Code segfaults reliably whenever Helldivers 2 is running. The game bundles nProtect GameGuard, an anti-cheat that injects into other processes system-wide. Four reproductions, three deliberate. With the game running, Claude Code cannot stay alive — it dies about two seconds after launch. Not degraded: unusable.

Reproduction, fastest path (~2 seconds):

Launch Helldivers 2 (Steam), enter gameplay.
Start Claude Code.
Segfault at roughly 2,182 ms.

Also reproduces in reverse — an established session dies when the game launches (in my case after ~80 minutes of uptime). Neither reproduces with the game closed.

Crash output:

============================================================
Bun v1.4.0 (63bb0ca0d) Windows x64 (baseline)
Windows v10.26200
CPU: sse42 avx avx2
Args: "C:\Users\Main\.local\bin\claude.exe" "--model" "opusplan" "--effort" "high"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) fetch(3) jsc spawn(12) standalone_executable yaml_parse(2) claude_code
Elapsed: 2182ms | User: 687ms | Sys: 359ms
RSS: 0.31 GB | Peak: 0.31 GB | Commit: 0.45 GB | Faults: 82516 | Machine: 34.14 GB
panic(thread 14696): Segmentation fault at address 0x3C
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Crash report: https://bun.report/1.4.0/e_163bb0camgggkEugogCCYnpggNT64.desy2TCYnpggNT64.desynouE_A2A4D

The encoded stack names the external module. It contains npggNT64.des twice — the injected 64-bit component of GameGuard. The equivalent positions in an unrelated Windows Bun crash trace contain ntdll.dll. GameGuard code was executing inside the Claude Code process at fault time. Confirmed injection into your shipped binary, not inference from timing.

The stack is identical across crashes with completely different process state. The 2,182 ms crash above and a 4,844,218 ms crash produced the same fault address (0x3C) and byte-identical bun.report URLs, despite different resident set size (0.31 GB vs 0.43 GB) and an order of magnitude difference in page faults (82,516 vs 1,000,782). That points at a single deterministic failure point rather than accumulated corruption — something is blocked the moment it is attempted.

0x3C is a small offset off a null base, consistent with an allocation or page-protection call returning null and being dereferenced unchecked. JavaScriptCore's JIT allocates pages and re-marks them executable at runtime, which a process scanner struggles to distinguish from code injection.

Environment evidence. GameGuard's user-mode monitors, still resident with the game closed:

ProcessName Id
----------- --
GameMon.des 40076
GameMon64.des 23148

Both block queries against their own Path and StartTime from an unelevated shell. npggsvc present but Stopped; no matching kernel driver loaded. User-mode injection and hooking.

The crash message routes users away from you. The banner reads: "Bun has crashed. This indicates a bug in Bun, not your code," and supplies a link to Bun's tracker. That text is inherited from the embedded runtime, but from a user's perspective it is Claude Code disclaiming responsibility and redirecting them elsewhere.

I suspect this is why the trigger has gone unidentified. Segfault reports naming Claude Code are scattered across the Bun tracker, where maintainers have no visibility into your users' environments, while Anthropic never sees them at all. Intercepting the panic and pointing at your own tracker — or both — is probably the highest-leverage change here, because it fixes the reporting path for every future instance of this class.

No supported runtime fallback exists. Your docs state the npm package installs the same native binary and that it does not invoke Node. That's clear and accurate, but it means a user hitting a Bun-specific incompatibility has no fallback except WSL 2, version pinning, or not using Claude Code on that machine. Defensible tradeoff; still a real gap for anyone whose workstation is also their gaming machine.

Requests:

A troubleshooting note that anti-cheat and endpoint security software which injects into processes can destabilize the runtime, naming WSL 2 as the supported mitigation. WSL 2 works because its processes live in a Hyper-V utility VM that a Win32 process scanner cannot reach.
A crash message that points at Claude Code's tracker.
A diagnostic instead of a bare segfault when a memory operation is externally blocked.
Scope guidance. If the answer is "run it in WSL 2," that's fine — I'd just like it written down somewhere findable.

Triage note: Windows Event Viewer logs nothing for these crashes. The runtime handles the exception itself and exits, so Windows Error Reporting never records a fault. Its absence is expected, not evidence against the report.

Cross-references: filing parallel reports with oven-sh/bun and Arrowhead Game Studios; will link all three once numbers exist.

Diagnostics ✔
├ Currently running: native (2.1.201)
├ Commit: 5bb45156ece6
├ Platform: win32-x64
├ Path: C:\Users\Main\.local\bin\claude.exe
├ Config install method: native
└ Search: OK (bundled)

Multiple installations found ⚠
├ npm-global at C:\Users\Main\AppData\Roaming\npm\claude
└ native at C:\Users\Main\.local\share\claude

Installation warnings ⚠
├ Leftover npm global installation at C:\Users\Main\AppData\Roaming\npm\claude
└ Run: npm -g uninstall @anthropic-ai/claude-code

Updates ✔
├ Auto-updates: disabled (set by env: DISABLE_AUTOUPDATER)
├ Auto-update channel: latest
├ Last update attempt: success → 2.1.201 (2026-07-05)
├ Stable version: 2.1.212
└ Latest version: 2.1.220

Background server ◯
├ Mode: ephemeral
└ See claude daemon status for details

Remote Control ✔
└ Control this session from claude.ai/code or the Claude mobile app

MCP servers ⚠
├ 1 MCP server not connected — run /mcp to authenticate, retry, or see details:
└ claude.ai Google Calendar: needs authentication

Plugin errors ✘
├ 1 plugin error detected:
└ playwright@claude-plugins-official [playwright]: Plugin "playwright" not cached at
C:\Users\Main\.claude\plugins\cache\claude-plugins-official\playwright\unknown — run /plugin to refresh