[BUG] Bash tool fails with EINVAL when project is on non-C: drive (Windows)

Finding: A single external report, https://github.com/anthropics/claude-code/issues/100957, says that on Windows 11 with the VS Code extension and Claude Code 2.1.220, every Bash tool call fails when the project lives on the E: drive (E:\Code\Code). The error is EINVAL when opening a per-task .output file under the user's Temp\claude\e--Code-Code\tasks directory on C:. This is an external report only; KFA did not reproduce it. Reported symptoms: Even a trivial command such as echo test fails. The reporter says the directory exists and can be written manually from CMD (echo test > file.txt works), so they believe the failure is specific to the Claude Code Node.js process creating the output file. The error string reported is: EINVAL: invalid argument, open 'C:\Users\USER\AppData\Local\Temp\claude\e--Code-Code\tasks\<random>.output'. Environment as reported: Windows 11, VS Code integrated terminal, Claude Code 2.1.220, Sonnet default model, Anthropic API platform. The reporter ticked that they use the latest version but did not say whether this is a regression and gave no last working version. That version claim is unverified. Cause: unknown. The title and body tie the failure to a project on a non-C: drive, but this is the reporter's hypothesis. The issue has no comments, no maintainer response, and no confirmed root cause. The suggestion that moving the project to C: likely fixes it is untested speculation, and the reporter notes it is not a viable long-term answer. Fix status: the issue is open and the supplied sources show no fix commit and no released fix. Diagnostic use: if you see the same EINVAL on a .output path under Temp\claude\<project-slug>\tasks, note whether the project is on a non-system drive, since that is the only condition the report associates with the failure. Treat that only as a lead to compare, not as a confirmed cause. Limitations: this is one report, there is no independent reproduction, the thread may be incomplete, and no workaround has been verified.