claude-code - 💡(How to fix) Fix [BUG] Bash tool wedges mid-session with `EEXIST: mkdir session-env/<UUID>` and never recovers [2 comments, 3 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

The Bash tool enters an unrecoverable error state mid-session when it attempts to create its own already-existing session-env directory. Every subsequent Bash call for the remainder of the session returns the same EEXIST error.

Environment

• Platform: Windows 11 Enterprise 10.0.26200
• Shell: Git Bash (MSYS2 / MinGW64)
• Claude Code: CLI in terminal
• User home: C:\Users\<user>
• Session-env path: C:\Users\<user>\.claude\session-env\<UUID>

Error

EEXIST: file already exists, mkdir 'C:\Users\<user>\.claude\session-env\89580c33-6e44-49e5-b165-291f9efaab08'

Timeline (single session)

1. Session started normally. session-env\<UUID> created successfully on startup.
2. Many Bash tool calls worked over the course of several hours - including heavy ones (p4 operations, piped commands, multiple arguments).
3. Approximately 5 minutes after a successful complex Bash call, a trivial call (echo "retry") returned the EEXIST error.
4. Every subsequent Bash call - including echo hello - returned the identical error.
5. The wedge persisted until the session was restarted.

Key observations

• The session-env directory <UUID>/ is empty throughout. Listing its contents before and after the wedge shows no files written to it by Claude. It appears to be a bootstrap marker, not a working directory.
• The wedge fires on the current session's own UUID - it is not a stale-directory-from-prior-session collision.
• The directory genuinely does already exist (it is the one the current session created successfully at startup), so the EEXIST is correct from the OS's perspective. The bug is that the Bash tool treats mkdir non-idempotently and poisons the tool for the remainder of the session.
• Other tools (Read, Edit, Grep, Glob, Write, MCP tools) continued working normally while Bash was wedged.

What Should Happen?

mkdir of the session-env directory should be idempotent. If the directory already exists, proceed normally. The Bash tool should not cache a terminal failure state that persists for the rest of the session.

Suggested fix directions (for Anthropic's triage)

1. Make the session-env setup use mkdir -p semantics / fs.mkdir(recursive: true) and treat EEXIST as success.
2. If the directory check is intentionally non-recursive, gate the mkdir on a pre-existence check (if not exists -> mkdir).
3. Decouple tool-call error state from session-env setup so a transient setup issue doesn't wedge Bash for the rest of the session.

Additional context

A related but distinct issue was filed as #31233 (Write/Edit tool EEXIST on Windows NTFS with symlinked .claude/). That affects a different tool and a different .claude/ subpath; this report is specifically about the Bash tool and session-env/.

Workaround

Delete C:\Users\<user>\.claude\session-env\<UUID> to clear the wedge. This is impractical from inside Claude Code (the only tool that could run rmdir is the Bash tool that is wedged). Workaround currently requires exiting the session or using a separate terminal.

Error Messages/Logs

Steps to Reproduce

Inconsistent repro. Seems to occur more frequently with multiple sessions running concurrently, but that is not always the case. Have had it happen in both CLI and also in VSCode extension.

There's no consistency in terms of what specific command(s) trigger the wedging. Only obvious thing is that the more bash calls that happen the more likely it is that the bug occurs.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.123

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response