Native binary leaks ~7MB .node files to temp directory on each session (Windows)

[SlothKing16]

Description

The native Windows binary (claude.exe) extracts native Node.js addon files to the system temp directory on each session/invocation but never cleans them up. Over time this accumulates significant disk usage.

Environment

• OS: Windows 11
• Claude Code version: Native binary (.local/bin/claude.exe, ~232 MB)
• Installation method: Native binary (not npm)
• Auto-update: Disabled

Evidence

After ~4 days of regular usage:

• 2,813 files matching pattern .789*.node
• 18 GB total disk usage
• Each file is exactly 6,965,760 bytes (~6.7 MB)
• Files are created in C:\Users\<user>\AppData\Local\Temp\
• Naming pattern: .789127d3????????-00000000.node (hash varies per session)

$ find /c/Users/slono/AppData/Local/Temp -name ".789*.node" -type f | wc -l
2813

$ du -ch /c/Users/slono/AppData/Local/Temp/.789*.node | tail -1
18G     total

$ ls -la /c/Users/slono/AppData/Local/Temp/.789*.node | head -5
-rwxr-xr-x 1 slono 197609 6965760 Jan 31 22:34 .789127d317febb4e-00000000.node
-rwxr-xr-x 1 slono 197609 6965760 Jan 31 22:52 .789127d31aef7f3e-00000000.node
-rwxr-xr-x 1 slono 197609 6965760 Jan 31 22:39 .789127d31eeffeae-00000000.node
...

The files are Windows PE64 DLLs (native Node.js addons) - identical content, just different filenames per session.

Expected Behavior

The application should either:

1. Reuse existing extracted native modules instead of creating new copies each session
2. Clean up extracted temp files on exit
3. Use a deterministic filename so subsequent runs reuse the same file

Workaround

Manual cleanup:

Remove-Item "C:\Users\<user>\AppData\Local\Temp\.789*.node" -Force

Files can be safely deleted when Claude Code is not running.

Impact

At ~7 MB per session, heavy users can accumulate tens of GB within days. This is especially problematic on systems with smaller SSDs or limited C: drive space.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Windows: .node native addon cache files accumulate in working directory (~100GB/week) #22083
2. macOS Gatekeeper warning for extracted .node native addon #14911
3. Claude for Chrome extension triggers repeated macOS Gatekeeper warnings for .node files #14914

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

[kolkov]

@wolffiex Adding another Windows data point and a broader perspective on why this class of issues keeps recurring.

This is not a duplicate of #14911

#14911 is a macOS Gatekeeper UI warning. This issue is about silent disk space exhaustion on Windows — a fundamentally different severity level:

	#14911 (macOS)	This issue (Windows)
Platform	macOS	Windows
Symptom	Gatekeeper security dialog	Disk fills up silently
User impact	Click "Done" to dismiss	System unusable at 0 bytes free
Severity	Low	High — data loss / system stability risk

Closing Windows disk exhaustion issues as duplicates of a macOS UI annoyance means nobody is tracking the actual problem.

My environment

• OS: Windows 10 (MSYS2/Git Bash)
• Claude Code: 2.1.34
• C: drive: 293 GB total, 0 bytes free (100% full)

Stats

.789*.node files in %TEMP%:  1,875 files = 11.97 GB
All .node files in %TEMP%:   1,962 files = 12.71 GB
Each file:                   ~6.6 MB (PE64 DLL, better-sqlite3)

Oldest: 2026-02-02
Newest: 2026-02-06 (today, still accumulating)

~20 GB/week (12 GB current + 8 GB manually cleaned last week). Consistent with OP's report and #22083 (~100 GB/week for heavy usage).

The pattern: no resource lifecycle management

This .node leak is not an isolated bug — it's a symptom of a recurring architectural pattern where Claude Code allocates resources without cleanup:

Issue	Resource leaked	Impact
This issue	.node native addons in %TEMP%	~20 GB/week
#10107	file-history snapshots (~36 MB each)	300 GB before user noticed
#7243	.claude.json unbounded growth (config + history + state + changelog in one file)	65 MB+ files, 30s+ startup
#8856	/tmp/claude-*-cwd tracking files	Thousands of leaked files
#14674	Memory — multiple Claude Code instances	Complete system freeze, only hard reboot recovers

Every one of these follows the same pattern: create → never clean up → user discovers when system breaks.

Why this keeps happening

The root cause was well-documented in #7243 (17 comments, strong community support, closed by bot yesterday despite active discussion):

1. No separation of concerns — config, history, state, and cache mixed together with no lifecycle boundaries
2. No resource cleanup on exit — temp files, native addons, history snapshots all persist indefinitely
3. Bun runtime extracts native modules per-session — instead of caching deterministically, each invocation creates a new 6.6 MB DLL with a unique filename

A well-architected application would:

• Use deterministic paths for extracted native modules (extract once, reuse forever)
• Register cleanup handlers (atexit, SIGTERM) for temp files
• Separate ephemeral data (cache, temp) from persistent data (config, settings)
• Implement TTL or LRU eviction for any on-disk cache

None of these are exotic requirements — they're standard practices for any application that writes to disk.

Request

Please don't close this as a duplicate of a macOS Gatekeeper warning. Windows users need a tracked issue for the disk exhaustion problem. At minimum, Bun's native module extraction should use a deterministic filename so it overwrites instead of accumulating — that alone would reduce the leak from ~20 GB/week to ~6.6 MB total.

Workaround

# When Claude Code is NOT running:
Remove-Item "$env:TEMP\.789*.node" -Force

See also: #14674 (system freeze with multiple instances on Windows), #7243 (architectural analysis, closed by bot despite community support).

[Nantris]

I don't use WSL(2) but I use Cygwin and MSYS2 and it seems like MSYS2 suffers this issue but Cygwin is spared. My other details in (now closed as duplicate) #24853

This difference seems quite possibly useful for diagnosing and fixing the root cause.

[Nantris]

It does actually occur in Cygwin too.

After weeks of facing this issue which corrupts Claude Code (not to mention other apps) by filling the disk, it would be nice to see this at least acknowledged. This is an enormous problem - one of the most serious bugs in the app, and probably relatively trivial to address.

The backup of .claude.json also doesn't happen for obvious reasons, so it tells you to cp to get back a file that's never existed, and then you have to re-setup Claude Code like you've never used it before.

This happens every third day if I forget to clean up after Claude....

[tjanssens]

Workaround: automatic cleanup via SessionEnd hook

You can add a SessionEnd hook to your ~/.claude/settings.json
that automatically cleans up the leaked .node files whenever a
session ends:

  {
    "hooks": {
      "SessionEnd": [
        {
          "matcher": "*",
          "hooks": [
            {
              "type": "command",
              "command": "find \"$TEMP\" -maxdepth 1 -name
  '.7897*.node' -mmin +5 -delete 2>/dev/null; exit 0"
            }
          ]
        }
      ]
    }
  }

This deletes all .7897*.node files from the temp directory that
are older than 5 minutes (to avoid removing files still in use by
an active session). The exit 0 ensures the hook never blocks
session termination, even if the find command fails.

Tested on Windows 11 with Git Bash — cleaned up 726 files (~4.5
GB) on the first run.

Not a proper fix of course, but it prevents the accumulation
until this is resolved upstream.