[BUG] Windows: Bash tool fails with EINVAL on tasks/*.output file open (v2.1.53)

Resolved 💬 3 comments Opened Feb 25, 2026 by masahiroono36 Closed Feb 25, 2026

Description

On Windows 11, the Bash tool consistently fails with EINVAL: invalid argument when attempting to open its output file in the tasks temp directory. Every Bash invocation fails, including trivial commands like echo hello.

Error

Error: EINVAL: invalid argument, open 'C:\Users\<user>\AppData\Local\Temp\claude\C--Users-<user>-work-<project>\tasks\<id>.output'

Environment

  • OS: Windows 11 Home (10.0.26200)
  • Claude Code version: v2.1.53 (native installer, ~/.local/bin/claude.exe)
  • Shell: Git Bash (C:\Program Files\Git\bin\bash.exe)
  • Installation method: Anthropic native installer (not npm)

Key observations

  • Write/Read tools work fine on the exact same temp directory path — the directory itself is healthy and writable
  • The issue is Bash tool specific — something in how Bash tool opens/creates the .output file
  • Previously worked around v2.1.50 (not 100% confirmed, but high confidence)
  • Suggests a regression introduced between v2.1.50 and v2.1.53

Reproduction steps

  1. Install Claude Code v2.1.53 via native installer on Windows 11
  2. Open any project directory
  3. Run any Bash command (even echo hello)
  4. Observe EINVAL error on the .output file

Attempted workarounds (all failed)

  1. Deleting temp directory (%LOCALAPPDATA%\Temp\claude\) and restarting — tried multiple times, no effect
  2. Setting preferredShell to explicit Git Bash path (C:\Program Files\Git\bin\bash.exe) in settings.json — no effect
  3. dangerouslyDisableSandbox: true — same EINVAL error, confirms sandbox is not the cause
  4. Changing TEMP/TMP environment variables to C:\tmp to avoid long path — no effect
  5. Setting CLAUDE_TMPDIR to C:\tmp\claude — no effect
  6. Windows Defender exclusion added for %LOCALAPPDATA%\Temp\claude folder — no effect

Analysis

Since Write tool can create files at the same path successfully, the EINVAL is not a filesystem/permissions issue. The problem appears to be in the Bash tool's internal file handling code — possibly how it opens, creates, or passes the output file path to the shell subprocess.

Related issues

  • #26545 — Bash tool returns exit code 1 with no output on Git Bash (Windows) since v2.1.45
  • #26505 — v2.1.45 Windows: Bash tool fails silently when WSL bash is on PATH alongside Git Bash
  • #21915 — Bash tool produces no output on Windows
  • #18552 — Bash script stdout not captured on Windows/MINGW64 (regression)

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗