Windows: Temp directories and `nul` files not cleaned up

Status Fixed / completed
Maintainer reply ✓ Yes — ant-kurt
Activity 9 comments · opened Jan 12, 2026 · closed Feb 15, 2026
💡 Likely answer: A maintainer (ant-kurt, collaborator) responded on this thread — see the highlighted reply below.

Windows: Temp directories and nul files not cleaned up

Description

On Windows, Claude Code leaves behind two types of orphaned files/directories that accumulate over time:

  1. tmpclaude-*-cwd directories - Working directories created for subagents that aren't deleted after the agent completes
  2. nul files - Empty files named "nul" appearing in various project directories

The nul files are particularly problematic because "NUL" is a reserved device name on Windows (like /dev/null on Unix). Once created, these files cannot be deleted through normal Windows operations (del, rd, Explorer, PowerShell Remove-Item, etc.).

Environment

  • OS: Windows 11 (Build 26200.7462)
  • Claude Code version: (latest as of 2026-01-12)
  • Shell: Git Bash / PowerShell

Steps to Reproduce

  1. Use Claude Code on Windows with subagents (Task tool)
  2. After several sessions, check for orphaned directories:

``powershell
Get-ChildItem -Recurse -Directory -Filter 'tmpclaude-*'
``

  1. Check for nul files:

``powershell
Get-ChildItem -Recurse -Filter 'nul'
``

Observed Behavior

After normal usage, I found:

  • 42 tmpclaude-*-cwd directories scattered across project trees
  • Multiple nul files in various directories

New tmpclaude-* directories appear during each session and persist after Claude Code exits.

Expected Behavior

  • Subagent working directories should be cleaned up when the subagent completes or when Claude Code exits
  • No nul files should be created (suspect this is a /dev/null -> nul cross-platform bug)

Workaround

The only reliable way to delete these on Windows is via WSL:

# Delete tmpclaude directories
wsl rm -rf /mnt/c/path/to/project/tmpclaude-*

# Delete nul files (Windows can't delete these normally)
wsl rm -f /mnt/c/path/to/nul

Standard Windows deletion methods all fail for nul files:

  • del \\?\C:\path\nul - doesn't work
  • rd /s /q \\?\C:\path\nul - doesn't work
  • PowerShell Remove-Item - doesn't work
  • .NET [System.IO.File]::Delete() - access denied
  • Python os.remove() - file not found
  • robocopy /MIR empty folder trick - doesn't work

Suspected Cause

For the nul files: Somewhere in the codebase there may be a reference to /dev/null that isn't being translated to NUL (the Windows equivalent device). Instead of writing to the null device, it creates a literal file named "nul".

Additional Context

These files don't cause functional issues but clutter the filesystem and the nul files can prevent folder deletion entirely (e.g., can't delete a project folder containing a nul file without using WSL).

View original on GitHub ↗

9 Comments

alessandrozuliani · 7 months ago

related /w #8856 and #17777

i actually was able to delete (strictly via windows cmd prompt, not powershell) with

del \\?\C:\path\nul

comdexxsolutionsllc · 7 months ago

+1
| Version 2.1.5 is still performing this way.

deleting via cmd works, or rename and delete in pwsh also works, but this is annoying.

bigshiny90 · 7 months ago

same here. my root directories are currently awash in cwd temp files and nul. thanks 2.1.5

BenGardiner123 · 7 months ago

omg guys... this is so annoying its killing me

if its not the nul files randomly being created, its the temp files.

<img width="361" height="117" alt="Image" src="https://github.com/user-attachments/assets/61fe1828-62dd-4d6d-9159-de1b09ab3bbd" />

this really isn't good for an expensive product.

KvFxKaido · 7 months ago

Reopening - the nul file issue is still active.

During a single Claude Code session today, the nul file was recreated multiple times after deletion. This confirms it's being actively created during sessions, not just leftover artifacts.

The file requires WSL to delete since Windows reserves "nul" as a device name:

wsl rm -f /mnt/c/path/to/nul

Likely cause: somewhere in the subprocess spawning code, output is being redirected to a literal file named "nul" instead of using the proper null device (subprocess.DEVNULL in Python or equivalent in Node.js).

trueliarx · 7 months ago

Recently installed and the problem is quite annoying in my case since the "nul" file renders unresponsive my backup application due to high cpu usage (I'm excluding the files as workaround).

ant-kurt collaborator · 6 months ago

Hi - can you confirm if the tmpclaude-* issue is still occurring on latest? We believe this was fixed around 2.1.7.

For the NUL files - we've made some adjustments in today's release 2.1.42, and there's a larger discussion on #4928

KvFxKaido · 6 months ago

Tmp files aren't an issue anymore. Null files were still being created for me last night but haven't gotten the chance to check today. I can close this if there's already a wider discussion.

github-actions[bot] · 6 months ago

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.