[BUG] Cowork (Windows): Claude Code child process exits with code 1 immediately on spawn; misleading CLAUDE_CODE_GIT_BASH_PATH warning
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?
Cowork (Windows): Claude Code child process exits with code 1 immediately on spawn; misleading CLAUDE_CODE_GIT_BASH_PATH warning
Note on repo choice: filing here because the failing component is the bundled Claude Code CLI (2.1.111) spawned by Cowork. If this belongs in a separate desktop-app repo, please redirect — happy to refile.
Summary
Cowork is hard-broken on Windows 11 (MSIX desktop app Claude_1.3883.0.0_x64__pzs8sxrjxfjjc). Every session attempt fails in ~1 second:
[warn] [HostLoop] cli.js stderr: Claude Code was unable to find
CLAUDE_CODE_GIT_BASH_PATH path "C:\Users\<user>\.local\bin"
[error] Sentry: write EOF
[error] Claude Code process exited with code 1
error_category: 'process_crashed'
The stderr message points at bash, but bash is not the cause — see step 3 in the matrix below.
Reproduction matrix
I tested four workarounds. All four produced the identical error (same warning text, same exit code, same Sentry signature):
| # | Action | Expected | Actual |
|---|---|---|---|
| 1 | Unset CLAUDE_CODE_GIT_BASH_PATH (was a stale C:\gitbash\bash.exe); restart desktop app | Warning text changes or disappears | Identical warning, same .local\bin path |
| 2 | Install Git for Windows; set CLAUDE_CODE_GIT_BASH_PATH=C:\Git\bin\bash.exe (User scope, verified in registry); restart desktop app | Warning reflects new path or clears | Identical warning, still .local\bin |
| 3 | Copy a working bash.exe + msys-2.0.dll into C:\Users\<user>\.local\bin\ (the exact path the warning names; verified bash runs standalone from there); restart desktop app | Bash check passes | Identical warning, identical exit code 1 |
| 4 | Forcibly kill all desktop claude.exe between every step before relaunch (so no stale env in memory) | Fresh process picks up new env | No effect on outcome |
Control test: invoking the same claude.exe 2.1.111 binary directly from PowerShell with my chosen CLAUDE_CODE_GIT_BASH_PATH produces a warning that correctly echoes my value. So the CLI honors the env var when invoked normally — only the desktop app's spawn path doesn't deliver it.
What this points to
- The bash warning is a red herring (proven by step 3).
CLAUDE_CODE_GIT_BASH_PATHset at User scope does not reach the MSIX desktop app's spawned child — likely MSIX env-isolation or an internal override.- The real failure is upstream: the child
claude.exeexits in milliseconds, and the host's first stdin write hits a closed pipe ("write EOF"). Plausible candidates (you have the source): OAuth handshake, host↔child IPC version mismatch, or a 2.1.111-specific bug already fixed in 2.1.117.
Three product-side asks
- Fix the misleading stderr.
"Claude Code was unable to find CLAUDE_CODE_GIT_BASH_PATH path '...'"should not fire whenbash.exeis present at the named path. Either gate it on a real FS check or improve the message.
- Make
CLAUDE_CODE_GIT_BASH_PATHactually overridable in the MSIX desktop app. Right now the value the child sees is decoupled from User-scope env. If this is intentional, document it; if not, fix the propagation. Either way, users can't currently override it.
- Address Cowork CLI version drift. Host CLI is
2.1.117, Cowork-bundled CLI is2.1.111. Bug fixes shipped to the host don't reach Cowork. A pinned-old version is fine if intentional, but it should be auto-updated alongside the desktop app, or surfaced in/doctor.
Environment
- OS: Windows 11 Pro 10.0.26200, x64, ja-JP locale
- Desktop app:
Claude_1.3883.0.0_x64__pzs8sxrjxfjjc(MSIX, current-user) - Claude Code CLI (host, separate install):
2.1.117— works fine standalone - Claude Code CLI (Cowork-bundled):
2.1.111—--versionreturns cleanly when run directly - CoworkVMService: Running. VM lifecycle is healthy (boots in ~12s, network connected, sdk-daemon ready, API reachable). Failure is purely host-side, on the child
claude.exespawn.
<details>
<summary>Sentry event IDs (for engineering correlation)</summary>
All from 2026-04-22 JST, same machine, same user, identical failure signature across multiple env-var configurations:
32d551c21c2b40e1bf4ec20226de352a— write EOF (10:16:27, after step 3)91e5a681669a45b3ac87042dc32152a1— exit 1 (10:16:27, after step 3)94f41a3fbc7449d0862aee6e152caaaf— write EOF (10:07:20, after step 1)5d889b24c36446dea22a2367d45e410a— write EOF (08:05:44, original)dea8bd157d9b41a7b79cdd2c809bbf26— exit 1 (08:05:44, original)
</details>
<details>
<summary>Stack trace (consistent across all failures)</summary>
Error: Claude Code process exited with code 1
at sIr.getProcessExitError
(...app.asar\.vite\build\index.js:390:8041)
at ChildProcess.i (...index.js:390:11086)
at Object.onceWrapper (node:events:623:26)
at ChildProcess.emit (node:events:520:35)
at ChildProcess._handle.onexit (node:internal/child_process:294:12)
Error: write EOF
at WriteWrap.onWriteComplete [as oncomplete]
(node:internal/stream_base_commons:87:19)
CycleHealth log marks every failure as:
had_first_response: false
seconds_to_outcome: 1
host_loop_mode: true
unhealthy_reason: 'system_error'
error_category: 'process_crashed'
</details>
Related
I have an open support ticket (215474003560565) with the full diagnostic bundle, raw logs, and install history. Filing here in parallel for engineering visibility.
---
SUGGESTED TITLE FOR THE GITHUB FORM:
Cowork (Windows): Claude Code child process exits with code 1 immediately on spawn; misleading CLAUDE_CODE_GIT_BASH_PATH warning
SUGGESTED LABELS (if auto-suggested): bug, windows, cowork
What Should Happen?
Cowork should successfully spawn the Claude Code child process and respond to user prompts, just as the standalone claude CLI does in a terminal. The CLI crash within 1 second of spawn should not occur regardless of CLAUDE_CODE_GIT_BASH_PATH state or bash availability, since the same binary works when invoked directly from PowerShell.
Error Messages/Logs
[warn] [HostLoop] cli.js stderr: Claude Code was unable to find CLAUDE_CODE_GIT_BASH_PATH path "C:\Users\<user>\.local\bin"
[error] Sentry: write EOF
[error] Claude Code process exited with code 1
error_category: 'process_crashed'
Stack trace from main.log:
at sIr.getProcessExitError (C:\Program Files\WindowsApps\Claude_1.3883.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:390:8041)
CycleHealth log:
had_first_response: false
seconds_to_outcome: 1
host_loop_mode: true
unhealthy_reason: 'system_error'
error_category: 'process_crashed'
Sentry Event IDs (for Anthropic backend correlation):
- 5d889b24c36446dea22a2367d45e410a
- dea8bd157d9b41a7b79cdd2c809bbf26
Steps to Reproduce
Minimal Reproduction
- Install Claude Desktop on Windows 11 (any recent version; I am on 1.3883.0.0, auto-updated from 1.3561.0.0)
- Launch Claude Desktop from Start menu
- Open Cowork tab
- Start a new task with any prompt (e.g., "hello" or "おはよう")
- Observe: Task fails immediately with "Claude Code process exited with code 1"
Environment Details
- Claude Desktop: 1.3883.0.0 (MSIX package:
Claude_1.3883.0.0_x64__pzs8sxrjxfjjc) - Claude Code host CLI: 2.1.116 (native install at
C:\Users\<user>\.local\bin\claude.exe) - Claude Code VM-bundled CLI: 2.1.111 (spawned by Cowork)
- OS: Windows 11 Pro (64-bit)
- Plan: Claude Max (annual)
Control Test (proves this is Desktop-side bug, not CLI bug)
Invoking the same claude.exe 2.1.111 binary directly from PowerShell:
- Honors user-set
CLAUDE_CODE_GIT_BASH_PATH✅ - Does NOT crash ✅
- Works exactly as expected ✅
Invoking via Desktop app's Cowork spawn:
- Env var appears stripped/overridden ❌
- Crashes within 1 second ❌
- Returns exit code 1 ❌
Same binary, same machine, same environment variables — only the spawn path differs.
Workarounds Attempted (All Failed - see reproduction matrix in main body)
- Unsetting
CLAUDE_CODE_GIT_BASH_PATH→ no effect - Installing Git for Windows 2.54.0 and setting path to
C:\Git\bin\bash.exe→ no effect - Placing working
bash.exe+msys-2.0.dllatC:\Users\<user>\.local\bin\(the path the warning references) → no effect - Forcibly killing all
claude.exeprocesses between each attempt to ensure no cached state → no effect
All four workarounds produced identical error output, identical exit code, identical Sentry signature.
Notes
- Full diagnostic bundle available at support ticket 215474003560565 if engineering wants raw logs
- 8 Sentry Event IDs captured (representative:
5d889b24c36446dea22a2367d45e410a,dea8bd157d9b41a7b79cdd2c809bbf26) - Appears to be the same cross-platform regression as #49391 and #49328 (macOS reports)
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
1.3561.0.0
Claude Code Version
2.1.116
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗