[BUG] Cowork (Windows): Claude Code child process exits with code 1 immediately on spawn; misleading CLAUDE_CODE_GIT_BASH_PATH warning

Resolved 💬 3 comments Opened Apr 22, 2026 by 551107naokimizutani-art Closed Jun 4, 2026

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

  1. The bash warning is a red herring (proven by step 3).
  2. CLAUDE_CODE_GIT_BASH_PATH set at User scope does not reach the MSIX desktop app's spawned child — likely MSIX env-isolation or an internal override.
  3. The real failure is upstream: the child claude.exe exits 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

  1. Fix the misleading stderr. "Claude Code was unable to find CLAUDE_CODE_GIT_BASH_PATH path '...'" should not fire when bash.exe is present at the named path. Either gate it on a real FS check or improve the message.
  1. Make CLAUDE_CODE_GIT_BASH_PATH actually 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.
  1. Address Cowork CLI version drift. Host CLI is 2.1.117, Cowork-bundled CLI is 2.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--version returns 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.exe spawn.

<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

  1. Install Claude Desktop on Windows 11 (any recent version; I am on 1.3883.0.0, auto-updated from 1.3561.0.0)
  2. Launch Claude Desktop from Start menu
  3. Open Cowork tab
  4. Start a new task with any prompt (e.g., "hello" or "おはよう")
  5. 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)

  1. Unsetting CLAUDE_CODE_GIT_BASH_PATH → no effect
  2. Installing Git for Windows 2.54.0 and setting path to C:\Git\bin\bash.exe → no effect
  3. Placing working bash.exe + msys-2.0.dll at C:\Users\<user>\.local\bin\ (the path the warning references) → no effect
  4. Forcibly killing all claude.exe processes 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_

View original on GitHub ↗

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