[BUG] claude.exe triggers Windows BSOD via Wof.sys during directory listing (NtQueryDirectoryFileEx)

[VRDate]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

claude.exe (Claude Code CLI) triggers a Windows kernel BSOD (Blue Screen of Death) by performing heavy NtQueryDirectoryFileEx syscalls (standard directory listing). The crash occurs in Wof.sys (Windows Overlay Filter) at WofPreDirectoryControlCallback+0x695 — a CFG (Control Flow Guard) indirect-call guard violation.

This is not an external Windows kernel bug in Wof.sys, but a Claude Code bug, due to Claude Code's intensive directory scanning, no delay in the same instant makes it a reliable trigger. Filing here so Anthropic is aware that Claude Code can crash Windows systems with this specific Wof.sys version, as well as wsl hypervisor.

Crash Statistics (all triggered by claude.exe)

Date	BSODs	Bugcheck codes
2026-03-06	7	0x139, 0x3B, 0x50, 0x10E, 0x1E, 0x14F
2026-03-09	1	0x139
2026-03-10	5	0x139 (x2), 0x3B (x2), 0x1E (x1)
2026-03-11	1	0x50
Total	14	4 distinct types at same Wof.sys +0x695 offset

All March 9-11 crashes have identical call stack:

NtQueryDirectoryFileEx → FLTMGR → Wof!WofPreDirectoryControlCallback+0x695 → CFG guard violation

4 manifestations of the same bug — the corrupted indirect call target lands in different memory regions:

1. 0x139 — CFG guard catches invalid target before execution
2. 0x3B (c0000005) — pointer escapes CFG, hits unmapped memory → access violation
3. 0x1E (c0000005) — same access violation via different exception path
4. 0x3B (c000001d) — pointer lands on non-code bytes → illegal instruction
5. 0x50 — pointer references invalid page in nonpaged pool

Affected Configuration

• Wof.sys: 10.0.26100.5074 (ships with Windows 11 25H2 build 26200)
• Compact OS: Enabled increases crash frequency, but crashes also occur with CompactOS disabled
• WOF minifilter: Attached at altitude 40700, intercepts every NTFS directory IRP

Microsoft Bug Report

Filed on Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i

Potential Mitigation

Could Claude Code reduce the frequency/intensity of NtQueryDirectoryFileEx calls, or batch directory listings differently? This wouldn't fix the kernel bug, but might reduce the trigger rate on affected systems.

What Should Happen?

Claude Code should be able to perform directory listings without triggering a Windows BSOD. On systems with Wof.sys 10.0.26100.5074, the high volume of NtQueryDirectoryFileEx calls from claude.exe reliably crashes the kernel.

Ideally:

1. Claude Code could throttle or batch directory enumeration on Windows to reduce the frequency of NtQueryDirectoryFileEx calls
2. Or detect the vulnerable Wof.sys version and warn the user to disable Compact OS (compact /CompactOS:never)

Error Messages/Logs

WinDbg !analyze -v output (abbreviated):

KERNEL_SECURITY_CHECK_FAILURE (139)
  Arg1: 000000000000000a — indirect call guard check detected invalid control transfer
FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback+0x695
FAILURE_ID_HASH: {78ac0991-5393-0281-b23b-ce115373dc6d}

STACK_TEXT:
  nt!KeBugCheckEx
  nt!guard_icall_handler+0x1e
  nt!KscpCfgDispatchUserCallTargetEsSmep+0x11
  Ntfs!FindNextIndexEntry2+0x675
  Ntfs!NtfsContinueIndexEnumeration+0x10e
  Ntfs!NtfsQueryDirectory+0xd32
  FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe
  FLTMGR!FltPerformSynchronousIo+0x443
  Wof!WofPreDirectoryControlCallback+0x695    <-- CRASH
  FLTMGR!FltpPerformPreCallbacksWorker+0x58f
  nt!NtQueryDirectoryFileEx+0xd8

PROCESS_NAME: claude.exe
MODULE_NAME: Wof
IMAGE_VERSION: 10.0.26100.5074

Second manifestation (0x3B at the same offset):
SYSTEM_SERVICE_EXCEPTION (3b)
  ExceptionCode: c0000005 (ACCESS_VIOLATION)
FAILURE_BUCKET_ID: AV_Wof!WofPreDirectoryControlCallback+0x695
FAILURE_ID_HASH: {3ae300a6-24ac-569b-3ce2-789a00065d56}

Steps to Reproduce

1. Run Windows 11 25H2 (build 26200) with Wof.sys 10.0.26100.5074
2. Optionally enable Compact OS: compact /CompactOS:always (increases frequency but not required)
3. Run claude in a large directory (e.g., a monorepo with many files/subdirectories)
4. Claude Code performs intensive directory listings via NtQueryDirectoryFileEx
5. System BSODs with bugcheck 0x139 (KERNEL_SECURITY_CHECK_FAILURE) or 0x3B (SYSTEM_SERVICE_EXCEPTION)

Workaround: compact /CompactOS:never reduces frequency but does not eliminate the bug.

Environment:

• Windows 11 25H2 Build 26200.7922
• 192GB RAM, 32 cores, NVIDIA RTX 5000 Ada
• 3.8 TB disk
• Monorepo with ~100K files across nested directories

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.72 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Minidumps & Diagnostics

Two ZIP archives with all kernel minidumps and diagnostic outputs:

1. Original ZIP (Mar 9 dump) — 1x .dmp from 03-09
2. New ZIP (Mar 10-11 dumps) — 5x .dmp files from 03-10 and 03-11

Contents: 6x .dmp files total, WinDbg analysis, system info, event logs, driver list, triage output.

Hardware Tests Performed (all clean)

• Windows Memory Diagnostic: PASSED
• Disk scan: No corruption
• SFC /scannow: No integrity violations
• DISM /RestoreHealth: Clean
• In-place upgrade, repair install from ISO: Completed (replaced all files except Wof.sys)

Why This Is a Wof.sys Bug, Not Hardware

14 crashes at the exact same instruction (WofPreDirectoryControlCallback+0x695) across 6 days, producing 4 different exception types (0x139, 0x3B, 0x1E, 0x50) at the same offset. Random memory corruption wouldn't hit the same instruction deterministically. The 4 different bugcheck codes are expected — the corrupted indirect call target lands in different memory regions each time, producing different CPU exceptions.

Microsoft Q&A Thread

https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i

[VRDate]

Related: #30137 reports the same BSODs (0x139, 0x1E, 0x50) on Windows 11 build 26200 — 5 BSODs in 2 days. Another user in that thread reports 15 BSODs in one day. Same root cause: Wof.sys CFG guard bug triggered by claude.exe directory enumeration.

[VRDate]

Related Issues (for context)

Claude Code has a pattern of causing OS-level crashes across platforms. The Wof.sys BSOD is a separate kernel driver bug, but these show the broader stability picture:

Same Wof.sys BSOD (kernel-mode, fix owner: Microsoft):

• [BUG] Claude Code sessions cause Windows kernel BSODs (0x139, 0x1E, 0x50) — not application crashes, full OS crashes requiring hard reboot #30137 — 5 BSODs in 2 days, another user reports 15 BSODs in one day. Same bugcheck codes (0x139, 0x1E, 0x50), same Windows build 26200.

Separate Bun/memory issues (user-mode, fix owner: Anthropic/Oven):

• Repeated Bun v1.3.5 segfaults -- 78 crashes, root cause identified (Windows + WSL) #21875 — 78 Bun segfaults, N-API race condition identified (Windows + WSL)
• [BUG] Repeated Bun panic "switch on corrupt value" on Windows 11 x64 during long sessions (v2.1.50 / Bun 1.3.10) #27847 — Bun switch on corrupt value panics on Windows (Bun 1.3.10)
• [BUG] orphaned processes from subagents crashing computer #18405 — Orphaned subagent processes accumulating 1GB+ RAM
• Kernel panic: 3 Claude processes hit 17.3 GB resident on 18 GB machine, MacBook powered off (v2.1.37) #24960 — Kernel panic on macOS: 3 Claude processes hit 17.3GB on 18GB machine
• Critical Memory Leak: Claude Code Consumed 129GB RAM and Caused System Freeze #11315 — 129GB memory leak on Linux causing system freeze
• [Windows] N-API vtable corruption causes segfault, TUI escape, and orphaned processes in Bun v1.3.10 oven-sh/bun#27471 — N-API vtable corruption causing hard reboots (5 in 8 days)

Important distinction: #30137 attributes BSODs to "Bun memory corruption propagating to kernel" — this is incorrect. User-mode memory corruption cannot cause a CFG guard failure (GUARD_ICALL_CHECK_FAILURE) in Wof.sys. CFG checks are compile-time integrity validations in the driver binary. The Wof.sys bug and the Bun memory bugs are two independent problems that Claude Code happens to trigger simultaneously through heavy directory enumeration and Node.js/Bun runtime usage respectively.

[VRDate]

Update: 14 BSODs, 4th bugcheck type (0x50)

New crash — 2026-03-11 04:18 UTC:

Bugcheck	Params	Dump
0x00000050 PAGE_FAULT_IN_NONPAGED_AREA	0xffffbb0e0760f040, 0x2, 0xfffff8040d352e58, 0x2	031126-30703-01.dmp

Running total: 7 (Mar 6) + 1 (Mar 9) + 5 (Mar 10) + 1 (Mar 11) = 14 BSODs in 6 days.

4th bugcheck type: 0x50 joins 0x139, 0x3B, 0x1E. All are different manifestations of the same Wof.sys +0x695 indirect call corruption — the invalid pointer lands in different memory regions producing different exceptions:

• 0x139 = CFG guard catches invalid target
• 0x3B = access violation (unmapped) or illegal instruction (non-code)
• 0x1E = kmode exception (access violation)
• 0x50 = page fault in nonpaged area (NEW)

Wof.sys: Still 10.0.26100.1 — no Microsoft patch. CompactOS remains disabled. WOF minifilter still attached (cannot safely detach).

Trigger: claude.exe directory enumeration → NtQueryDirectoryFileEx → FLTMGR → Wof!WofPreDirectoryControlCallback+0x695.

Updated dump ZIP shared on MS Q&A #5814272.

[VRDate]

Update: 16 BSODs — corruption spreading to other kernel modules

3 new BSODs today (2026-03-11), with a significant change: two of the three crashes are NO LONGER in Wof.sys.

Time	Bugcheck	Faulting Module	WinDbg Bucket
04:18	0x50 PAGE_FAULT	Wof.sys +0x695 (same known bug)	AV_Wof!WofPreDirectoryControlCallback
12:31	0x1E KMODE_EXCEPT	Ntfs.sys NtfsContinueIndexEnumeration+0x14	AV_Ntfs!NtfsContinueIndexEnumeration
12:52	0x3B SYS_SVC_EXCEPT	nllNetHub.sys (Norton) +0x876d	AV_nllNetHub!unknown_function

Running total: 7 (Mar 6) + 1 (Mar 9) + 5 (Mar 10) + 3 (Mar 11) = 16 BSODs in 6 days.

Escalation: Kernel memory corruption spreading

Previously all 13 crashes blamed Wof.sys +0x695. Today, only 1 of 3 is Wof.sys — the other two are:

1. Ntfs.sys — NtfsContinueIndexEnumeration+0x14 is a push r15 instruction that caused a General Protection Fault. A #GP on push r15 means the stack pointer (RSP) was corrupted. This is still in the directory enumeration path (downstream from WOF's minifilter callback).

2. nllNetHub.sys — Norton LifeLock network hub driver, in afwServ.exe (Norton Application Firewall). Unrelated to filesystem — suggests kernel pool corruption spreading beyond the directory enumeration path.

Theory: Wof.sys corruption at +0x695 is poisoning kernel pool/stack memory. When the corrupted pointer lands in WOF's own code, WinDbg blames Wof.sys. When it lands in NTFS or Norton memory, those modules crash instead. The Ntfs.sys crash (stack corruption in directory enumeration) strongly supports this — WOF's minifilter runs before NTFS in the filter chain, and could corrupt NTFS's stack frame.

System state

• Wof.sys: 10.0.26100.1 (unchanged, no Microsoft patch)
• CompactOS: OFF (disabled 2026-03-09)
• WHEA: none (hardware errors clean)
• Disk: 132GB free / 3.8TB
• NVIDIA: 32.0.15.9571 (unchanged)

This is no longer just a WOF code defect — the corruption is destabilizing other kernel components. The system is becoming less stable over time, not more.

Related: #30137, MS Q&A #5814272

[VRDate]

Control test: TreeSize Free scanned entire 3.8TB SSD — zero BSODs

To isolate whether the crash trigger is any directory enumeration or specifically Claude Code's parallel pattern, I ran TreeSize Free 4.8.1 as a control test:

• Workload: Full-disk scan of 3.8TB SSD (every directory enumerated via NtQueryDirectoryFileEx through the same FLTMGR → Wof.sys minifilter chain)
• Duration: ~5 minutes of heavy I/O (435 CPU seconds), 19+ minutes total monitoring
• Result: Zero BSODs. Zero new minidumps. System completely stable.
• Meanwhile: Claude Code triggered 3 BSODs in 8 hours today (0x50 Wof.sys, 0x1E Ntfs.sys, 0x3B nllNetHub.sys)

This proves:

1. The hardware is not causing random memory corruption during disk I/O
2. Wof.sys handles single-process sequential directory enumeration correctly
3. The trigger is specific to Claude Code's pattern: dozens of concurrent ripgrep processes doing parallel directory walks simultaneously

The bug is a concurrency defect in Wof!WofPreDirectoryControlCallback — the callback's indirect call dispatch at +0x695 is not thread-safe under high-concurrency minifilter re-entrancy. Single-threaded callers (TreeSize, dir /s) never hit the race condition.

This also explains why "millions of Windows users" don't see this — most tools don't generate this level of concurrent directory enumeration through the minifilter stack.

[VRDate]

Progress sync — all vendors now engaged

Actions taken today (2026-03-11)

Diagnostics:

• WinDbg analyzed all 3 new dumps — crash is spreading: Wof.sys (1), Ntfs.sys (1), nllNetHub.sys/Norton (1)
• TreeSize control test: full 3.8TB SSD scan, 30 min, zero BSODs — proves concurrency-specific trigger
• MSI Center diagnostics inventory: HW Diagnosis, System Diagnosis, diskspd, pwrtest available
• msinfo32 system report exported (2.1MB)
• ACPI thermal zone: 85.1°C at idle — investigating (may be stale sensor)

Bug reports filed/updated across 4 platforms:

Platform	ID	Owner	Status
GitHub (Anthropic)	#32870	Software vendor	Open — no response yet
GitHub (Anthropic)	#30137	Software vendor (3 users)	Open — no response yet
MS Q&A (Microsoft)	#5814272	OS vendor	David-M (community) engaged, rebutted with evidence
MSI (HW vendor)	#1320187	Hardware vendor	Filed today + msinfo32 attached

Key evidence posted today:

1. 3 different kernel modules crashing = escalating instability
2. Ntfs.sys stack corruption (#GP on push r15) = WOF corrupting downstream modules
3. TreeSize control test = hardware stable, concurrency-specific trigger confirmed
4. BIOS E1822IWS.10E is latest — no MSI firmware fix available

Waiting on:

• Anthropic: any acknowledgment or workaround (reduce concurrent ripgrep processes?)
• Microsoft: Wof.sys patch (concurrency fix in WofPreDirectoryControlCallback)
• MSI: BIOS/firmware investigation, thermal/memory controller assessment

[VRDate]

Feedback Hub report filed

Microsoft's community advisor (David-M) confirmed this is a core driver defect and recommended filing via Feedback Hub for direct escalation to Microsoft engineers.

Feedback Hub link: https://aka.ms/AA106t77

Please upvote if you're experiencing Wof.sys BSODs during Claude Code sessions. Higher engagement = higher priority for Microsoft's kernel team.

Current status: 17 BSODs in 7 days (2026-03-06 through 2026-03-12). Wof.sys 10.0.26100.1 still unpatched. CompactOS OFF, still crashing. 3 faulting kernel modules (Wof.sys, Ntfs.sys, Norton nllNetHub.sys).

[VRDate]

BSOD #20 — 2026-03-14 00:19

Another crash overnight. Same identical bug:

Bugcheck: 0x139 KERNEL_SECURITY_CHECK_FAILURE
Bucket: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback
Hash: {78ac0991-5393-0281-b23b-ce115373dc6d}
Process: claude.exe

Stack:

claude.exe → NtQueryDirectoryFileEx → FLTMGR → Wof!WofPreDirectoryControlCallback+0x695
  → Ntfs!FindNextIndexEntry2+0x675 → KscpCfgDispatchUserCallTargetEsSmep+0x11
  → KiGeneralProtectionFault → guard_icall_handler → KeBugCheckEx

System state:

• Wof.sys 10.0.26100.5074 — unchanged, no Microsoft patch
• CompactOS OFF since 03-09
• No WHEA hardware errors
• System uptime before crash: 1 day 21 hours
• Dump: 031426-31890-01.dmp (17MB)

Running total: 20 BSODs in 9 days (03-06 through 03-14). Same offset (+0x695), same process (claude.exe), same trigger (NtQueryDirectoryFileEx from concurrent ripgrep).

Still waiting for any acknowledgment or workaround suggestion from Anthropic. Even a simple "limit concurrent ripgrep processes" flag would help.

[VRDate]

Workaround: Run Claude Code in WSL to avoid Wof.sys BSOD

Full writeup: https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548

---

Claude Code BSOD Workaround — Wof.sys Crash on Windows 11 Build 26200+

Problem

Claude Code triggers BSOD (Blue Screen of Death) on Windows 11 Build 26200+ during normal operation. The crash occurs in Wof.sys (Windows Overlay Filter) when Claude's filesystem operations call NtQueryDirectoryFileEx, which passes through the WOF minifilter and hits a CFG (Control Flow Guard) violation.

Bugcheck codes: 0x139 (KERNEL_SECURITY_CHECK_FAILURE), 0x3B, 0x1E, 0x50

Faulting module: Wof.sys 10.0.26100.5074 at WofPreDirectoryControlCallback+0x695

Trigger: Any filesystem-heavy operation — directory listing, file search, glob patterns — the kind of thing Claude Code does constantly.

Bug reports:

• Feedback Hub
• claude-code #32870 — "Claude Code triggers Wof.sys BSOD on Windows 11 Build 26200"
• claude-code #30137
• MS Q&A #5814272

Root Cause

This is a Windows kernel bug, not a Claude Code bug. Wof.sys (Windows Overlay Filter) handles WIM-backed files and CompactOS compression. When Claude Code (or any process) makes rapid NtQueryDirectoryFileEx calls on NTFS volumes, the WOF minifilter crashes in its directory control callback. CompactOS ON/OFF makes no difference — the bug is in the minifilter code path itself.

WOF is a critical Windows component — it cannot be disabled, detached, or unloaded without breaking Windows.

Workaround: Run Claude Code in WSL

Since the crash only happens on NTFS (Windows filesystem), running Claude Code inside WSL2 (which uses ext4) completely bypasses the Wof.sys code path.

Setup (5 minutes)

Prerequisites: WSL2 with Ubuntu (from Microsoft Store).

# 1. Install Ubuntu from MS Store (if not already)
wsl --install Ubuntu-24.04

# 2. Install Node.js inside WSL
wsl -d Ubuntu-24.04 -u root -- bash -c '
  curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
  apt install -y nodejs
'

# 3. Install Claude Code inside WSL
wsl -d Ubuntu-24.04 -u root -- npm install -g @anthropic-ai/claude-code

# 4. Verify
wsl -d Ubuntu-24.04 -u root -- claude --version

Create the wrapper

Create claude.cmd in the same directory as claude.exe (typically %USERPROFILE%\.local\bin\):

@echo off
wsl -d Ubuntu-24.04 -u root -- claude %*

On Windows, .cmd takes priority over .exe in the same directory. Every claude invocation from cmd.exe, PowerShell, or Windows Terminal now goes through WSL automatically.

How it works

BEFORE (crashes):
  Windows cmd/terminal
    → claude.exe (Windows native)
      → NtQueryDirectoryFileEx on NTFS
        → Wof.sys minifilter → BSOD

AFTER (safe):
  Windows cmd/terminal
    → claude.cmd (wrapper)
      → wsl -- claude (runs in WSL)
        → ext4 filesystem (no Wof.sys)
        → /mnt/c/ for Windows files (read/write, no WOF callback)

Your project files stay on C:\ — Claude in WSL accesses them via /mnt/c/. Your IDE (VS Code, IntelliJ, etc.) runs on Windows watching the same files. No file duplication needed.

Reverting

When Microsoft patches Wof.sys, simply delete the wrapper:

del %USERPROFILE%\.local\bin\claude.cmd

Claude will fall back to claude.exe (Windows native).

What doesn't work

Attempted fix	Result
Disable CompactOS (compact /compactos:never)	Still crashes
Windows Update (KB5079473)	Did not update Wof.sys
Norton AV exclusions	Unrelated (separate nllNetHub.sys crash)
Disabling WOF service	DO NOT — breaks Windows

Affected versions

• Windows: Build 26200+ (Windows 11 24H2 Insider/Dev)
• Wof.sys: 10.0.26100.5074 (unchanged across updates)
• Claude Code: All versions (the bug is in the OS, not Claude)
• Also affects: Any process making rapid filesystem directory queries (not Claude-specific)

Timeline

Date	Event
2026-03-06	First BSODs after Windows upgrade to Build 26200
2026-03-06	7 crashes in one day
2026-03-12	Feedback Hub report filed, GitHub issues opened
2026-03-14	WSL workaround deployed, 21 total crashes logged
TBD	Microsoft Wof.sys patch

[VRDate]

Update: Root cause proven + workaround tested (23 BSODs total)

What causes the crash

Claude Code fires multiple filesystem operations (reading files, searching directories) at the same time — especially when using sub-agents. On Windows 11 Build 26200+, the kernel driver Wof.sys cannot handle this many simultaneous directory queries and crashes with a Blue Screen.

It's not about how many files you have — it's about how many are read at the same time. One agent reading files one after another is fine. Two or more agents reading files simultaneously triggers the crash.

Proof from session logs

Extracted the exact tool calls from the JSONL transcript before each crash:

• BSOD Model Selection Flexibility for Cost-Effective AI Interactions #22 (03-14 04:42) — 5 agents running in parallel via WSL, all reading files at the same time → kernel crash
• BSOD public release has happened :-D #23 (03-14 05:32) — 2 sub-agents launched in the same response, both scanning 18 files concurrently → kernel crash

03:48:26  Claude finds 18 files matching *.jbang.kt
03:48:42  Sub-agent 1 starts reading all 18 files
03:49:51  Sub-agent 2 starts reading all 18 files (while #1 still running)
          ── both agents reading files at the same time ──
          ── 30-50 simultaneous filesystem calls ──
05:32:59  *** BLUE SCREEN — Wof.sys crash ***

Workaround: a "traffic light" for file operations

The fix is a tiny server that acts like a traffic light — it makes Claude's file operations wait in line instead of all running at once. Only one operation goes through at a time.

How it works:

1. A small background server runs on your machine (port 9876)
2. Before every file operation, Claude Code asks the server "can I go?"
3. The server lets one operation through at a time, with a small delay between each
4. This prevents the simultaneous burst that crashes Windows

Setup (2 minutes):

Install JBang (one-line install, runs on any Java), then:

# 1. Start the traffic light server in the background
jbang Mutex.jbang.kt &

# 2. Add this to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Read|Glob|Grep|Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash mutex-acquire.sh"
          }
        ]
      }
    ]
  }
}

That's it. Claude Code will now wait in line for file operations instead of firing them all at once. If the server isn't running, Claude works normally (no impact on single-agent usage).

Speed: The default delay is 2 seconds between operations (safest). For faster interactive work, start with jbang Mutex.jbang.kt --interval 100 (100ms between operations — 10x faster, still safe in testing).

Test results

Scenario	Tool calls	Result
5 agents, no traffic light	~36 concurrent reads	BSOD in minutes
5 agents, with traffic light	381 serialized calls	Stable, no crash
Normal tools (TreeSize, robocopy)	Sequential	Stable, no crash

Files (all in the gist)

https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548

File	What it does
Mutex.jbang.kt	The traffic light server (~120 lines of Kotlin)
mutex-acquire.sh	The hook script that asks "can I go?" (6 lines of bash)
TestMutex.jbang.kt	Tests to verify the traffic light works correctly
gen-repro-data.sh	Script to reproduce the crash: generates test data + agent prompts
claude-bsod-workaround.md	Full documentation with setup instructions