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

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22083
2. https://github.com/anthropics/claude-code/issues/14911
3. https://github.com/anthropics/claude-code/issues/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

@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).

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.

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....

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.

I really wish for a proper fix here. This is running me out of disk space and corrupting Claude every other day. Thanks for the workaround suggestion @tjanssens.

Bumping so the bot doesn't close this.

How exciting - hitting this today not only corrupted the Claude config file as usual, but also obliterated my existing session(s), losing all of the conversation forever. It still shows the session and its size, but you cannot resume it.

Edit: I was able to recover the session with claude --resume 5aa55b12-d4cd-4bff-87cc-4098933e34c5 but the GUI resume menu is now completely useless - it resumes different sessions than the one you select, doesn't list new ones, and sometimes restores nothing. I don't know how I would even fix this and it's a whole new issue I don't care to file considering issues get ignored anyway.

Edit 2: Nope even --resume seems to resume an unexpected session...

Edit 3: I guess it's the right session but it's lost so much text and it's rolled back to before a previous compact... My work is gone.

Unfortunately @tjanssens either does not fully address this or does not work at all in our environment (though I don't see why it wouldn't.)

Also .node files can have prefixes besides .7897* which makes it harder still to safely clean these up programmatically.

@stevenpetryk I'm sorry to ping you - you're the only Anthropic employee I've ever seen reply to any bug report and I hope somebody might be able to take a look at this one soon.

This bug keeps corrupting Claude's config and Claude's outputs. Claude fills the disk multiple times per day with gigabytes of .node temp files.

This also worsens Claude Code's quality in addition to its usability because once the agent hits an empty disk it starts frequently worrying about disk space.

I'm also concerned about what Claude might do to resolve this situation with --dangerously-skip-permissions set.

@SlothKing16 is this resolved for you? It's fixed for me. If so it would be good to close this as "Completed."

Confirmed fixed on my end — zero .789*.node files in %TEMP% after recent sessions. Thanks @Nantris for the nudge, and thanks to whoever shipped the fix. Closing as completed.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.