session-env dir locks and requires manual rmdir to unstick Bash tool on Windows

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?

When the Bash tool runs, it intermittently fails with:

EEXIST: file already exists, mkdir 'C:\Users\User\.claude\session-env\<uuid>'

The UUID is fixed for the life of the Claude Code session. Once the first EEXIST happens, every subsequent Bash call in the session fails the same way. Non-Bash tools (Read, Edit, Grep) continue to work fine. The only way to recover is to close Claude's reach and manually rmdir the offending folder from an external cmd window, then the next Bash call succeeds — until the next lock, which typically happens 3–4 calls later.

It looks like the shell session-env is being torn down and re-provisioned on every Bash call (the "Shell cwd was reset to ..." line appears after each successful call), and the setup step mkdirs the session-env dir without tolerating EEXIST when the previous teardown didn't clean up.

What Should Happen?

The Bash tool should either:
(a) make the session-env setup idempotent (tolerate EEXIST / use mkdir -p semantics), or
(b) ensure the teardown reliably removes the dir so the next setup starts clean.

Either way, Bash calls should continue working without manual user intervention.

Error Messages/Logs

EEXIST: file already exists, mkdir 'C:\Users\User\.claude\session-env\1ff603cc-ffaa-47b5-9d71-b06ac4350e59'

Steps to Reproduce

1. On Windows 11, start Claude Code from a cmd prompt: claude
2. In the Claude session, issue several Bash tool calls in sequence.

Any work that involves running node --check, git status, git commit,
gcloud, etc. back-to-back will reproduce. E.g.:

• ask Claude to run node --check on one or two files
• ask Claude to commit the changes
• continue editing and committing for a few iterations

1. Within ~3–10 Bash calls, one will fail with:

EEXIST: file already exists, mkdir 'C:\Users\User\.claude\session-env\<uuid>'

1. Every subsequent Bash call in the same session fails identically.
2. Recover by running in a separate cmd window:

rmdir /s /q "C:\Users\User\.claude\session-env\<uuid>"

1. Next Bash call works. The cycle repeats.

In a ~2-hour engineering session with periodic commits/checks, the
failure surfaced ~6 times and required ~6 manual rmdirs.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Unknown

Claude Code Version

2.1.111

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

The session-env UUID is stable across the entire Claude session — it's
not regenerated per tool call. The failure also seems to persist across
"Shell cwd was reset to ..." messages, suggesting those resets don't
actually teardown the session-env dir; they just reset cwd to default.

Workaround users can apply today, if they hit this:
rmdir /s /q "C:\Users\User\.claude\session-env\<uuid>"
(where <uuid> is whatever appears in the error).

Only observed on Windows. No repro on macOS/Linux in my usage.

Impact: blocks shell-dependent tool use mid-session. In practice this
kills long autonomous engineering flows because the human has to
manually intervene every few tool calls — the model can't unstick
itself, since Bash is exactly what's broken.