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

[551107naokimizutani-art]

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?

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.

2. 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.

3. 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.

Sentry event IDs (for engineering correlation)

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)

Stack trace (consistent across all failures)

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'

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 [BUG] Cowork fails on every new task with "Claude Code process exited with code 1." #49391 and [BUG] Claude Code process exited with code 1 - happening with cowork on Desktop #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

[roboro-tom]

Hitting what looks like the same issue on Windows 11 / PowerShell.

• Started ~April 24, 2026 (Friday before this comment)
• claude exits immediately on launch
• Stray characters leak to the terminal: initially [|0, later just [, and clicking the window after exit prints [I / [O (focus-in/out reports), which suggests Claude enables raw-mode terminal features (focus reporting, etc.) and then crashes before tearing them down
• Downgrading with npm i -g @anthropic-ai/claude-code@2.1.118 fixes it
• Reproduces in PowerShell directly (not a Git Bash / MinTTY issue)

Happy to provide claude --version / node --version / verbose logs if useful.

[weichensw]

This also applies to the invocation of $EDITOR. Any $EDITOR that is npm based (inherently on path as some-editor.cmd on windows) will fail to spawn.