[BUG] Scratchpad/temp files accumulate without cleanup (Claude Code and Cowork) until the host OS freezes and requires a hard power-off

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 24, 2026

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?

Scratchpad/temp files under %LOCALAPPDATA%\Temp accumulate without ever being cleaned up. Once the directory grows large enough, the entire host OS freezes — no mouse, no keyboard, no Ctrl+Alt+Del — and only a hard power-off recovers it. Worse, relaunching Claude afterwards while the scratchpad is still populated freezes the machine again within seconds, creating a reboot loop the user cannot escape from inside the app. 8 unexpected shutdowns in 14 days, all during active Claude sessions. Deleting the scratchpad folder manually stopped it completely.

What Should Happen?

Scratchpad artifacts should be cleaned up when a session ends, and on startup after an abnormal termination. Per-document intermediates (.docx builds, image rendering) should be removed as soon as each build completes rather than left for end-of-session. The scratchpad should be bounded by file count and size, and startup must never block on scanning it — that blocking scan is what makes the failure unrecoverable.

Error Messages/Logs

Kernel-Power Event 41 + EventLog 6008 (unexpected shutdown) x8 in 14 days:
  2026-08-11 22:07 | 2026-08-13 06:27
  2026-08-22 04:47, 05:25, 06:32, 06:35  <- reboot loop
  2026-08-24 23:57 (stale value, see note) | 2026-08-25 00:26

LiveKernelEvent 141 (VIDEO_ENGINE_TIMEOUT_DETECTED), WATCHDOG dumps at
00:25:45, 00:26:04, 00:29:09 -> C:\Windows\LiveKernelReports\WATCHDOG\

No WHEA-Logger entries. Both SSDs SMART Healthy, PredictFailure False.

Application log: MoAppHang for Claude_1.34493.0.0_x64__pzs8sxrjxfjjc
at 2026-08-21 12:42 (app itself hung; possibly related)

NOTE: Event 6008 reports the 08-24 freeze at 23:57:35, but file writes
continued until 00:18 — impossible during a freeze. 6008 is a stale
heartbeat; the real freeze was just after 00:18.

Steps to Reproduce

Run a long Claude Code or Cowork session on a software project, including .docx generation and image rendering.
Let the scratchpad under %LOCALAPPDATA%\Temp grow without clearing it.
Host OS freezes completely; hard power-off is the only recovery.
Reboot and launch Claude again without clearing the scratchpad → freezes again within seconds.
Delete the scratchpad folder from outside the app → problem disappears entirely.

Observed trigger in the most recent case: three .docx files (43 KB / 338 KB / 43 KB) generated in 13 minutes, preceded by an SVG→PNG diagram render. Freeze occurred immediately after the last write, not during code editing.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.34493.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Reproduces in both products, which points at shared scratchpad handling rather than a product-specific bug.

Ruled out: RAM/CPU/PCIe (zero WHEA entries), disk failure (SMART clean on both SSDs), disk-full (91 GB free), VSS exhaustion (0.98 GB of a 7.71 GB cap), and runaway files inside the project folder (project tree clean — its file count is entirely .venv + node_modules). The GPU is a legacy AMD card on a frozen driver, which is a fragility factor, but the machine ran years on that exact config and the freezes correlate strictly with Claude sessions.

Independent signal: Glary Utilities became unresponsive attempting to delete the scratchpad folder and never finished — it had to be removed with shift+delete.

Honest limitation: no exact file count was captured before deletion. NTFS MFT high-water analysis afterwards showed only a ~110,000-record gap, which does not support a "millions of files" claim — the scale was likely tens of thousands. This report doesn't rest on a number; it rests on the reproduction sequence. Project and file names withheld (unpublished project); exact names available privately to a maintainer on request. A monitor now logs scratchpad size every 2 minutes, so I can supply hard numbers if it recurs.

View original on GitHub ↗