Bash tool invocations fail with EPERM on Windows when writing per-task output capture file under %LOCALAPPDATA%\Temp\claude\...\tasks\*.output

Also submitted via Claude Code internal feedback channel for full session context and version/telemetry attachment. This public report is to surface the issue for other Windows users who may hit the same failure mode.

Summary

On Windows, individual Bash-tool invocations inside an otherwise-healthy Claude Code
session intermittently fail with EPERM: operation not permitted when opening the
per-task output capture file. The session itself launches, chat works, file tools
(Read/Edit/Write) work — only Bash is blocked. Non-destructive commands
(echo hello, gh auth status) fail identically.

Environment

• OS: Windows 11 (host), Git Bash / MSYS shell (Claude Code Bash harness)
• Claude Desktop installed via standard installer
• Claude CLI: v2.x (Opus 4.7 + Sonnet 4.6 selectable per turn)
• Project root on D:\DesktopStorage\... (non-system drive); Claude session temp

under default %LOCALAPPDATA%\Temp\claude\...

• No custom sandbox config; default permissions; no AV exclusion on temp path

Reproduction

1. Open a Claude Code session on a Windows host; let it run for an extended period

with many Bash invocations (this report: hundreds across a multi-hour session).

1. Issue any Bash command, including trivial ones:

``
echo hello
``

1. Error returned:

``
EPERM: operation not permitted, open
'C:\Users\<SHORTNAME>\AppData\Local\Temp\claude\<project-hash>\<session-uuid>\tasks\<id>.output'
``

1. Retrying the same command returns the same error on a different <id>.output

path — the harness generates a fresh filename per invocation, all blocked.

Expected behaviour

Bash invocation executes; stdout/stderr captured to the task output file; result
returned to the model.

Actual behaviour

Every Bash call fails at the fs.open step on the output capture file, before the
command itself runs. Session state is otherwise healthy — Read/Edit/Write on project
files succeed concurrently. /mcp, /model, etc. all work.

Workaround (confirmed)

Quitting Claude Desktop via the tray/menu, then killing any lingering
Claude.exe / node.exe processes in Task Manager, then relaunching Claude Desktop
restores Bash to a working state. A simple close-and-reopen is not sufficient
on this host — orphan processes survive the UI close and appear to retain open
handles on the tasks\ directory.

A one-time Windows restart had the same effect. In both cases the issue did not
recur immediately; it returns after some number of Bash invocations in long sessions.

Suspected root cause (speculative — for triage only)

Orphan/zombie session processes holding handles on
%LOCALAPPDATA%\Temp\claude\<project>\<session>\tasks\ appear to block new
fs.open calls on that directory even after the owning UI instance has exited.
An antivirus or Windows Defender real-time scan hooking \Temp\claude\ at write
time is a plausible secondary factor but was not directly confirmed in this
environment.

Impact

Blocks all shell-driven work mid-session (git, gh CLI, build, test, MCP-less flows).
Workaround requires closing the session and killing processes, so any in-flight
Bash-dependent task must be re-planned. File tools continue to function, which
means some work can continue, but any task requiring shell fails hard until
restart.

What would help

1. Harness-level retry or fallback path if fs.open on the task output file fails

with EPERM (e.g. fall back to a secondary capture path, or surface a clearer
diagnostic distinguishing "orphan handle" from "permission / config issue").

1. Harness cleanup of orphan per-session task directories on startup, OR a

Claude Code-side signal that tears down handles when the UI process exits.

1. Documentation note on Windows AV exclusion guidance for

%LOCALAPPDATA%\Temp\claude\.

Happy to share further diagnostic info — process tree, handle.exe output,
Defender event logs — on request.

---
Originator & approver: Venkatesh · Executor: Claude Opus 4.7.