Claude Code process exits with code 1 on Windows after tool calls with large output

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?

The Claude Code CLI process crashes with exit code 1 approximately 9–18 seconds after tool calls (PowerShell, git log) that produce large output. The session shows "Claude Code process blocked" and the conversation stops.

What Should Happen?

The Claude Code session should continue normally after running PowerShell tool calls, regardless of the output size.

Error Messages/Logs

errorClass: 'process_exited_nonzero', exitCode: 1
at vq.getProcessExitError → ChildProcess._handle.onexit
CycleHealth: unhealthy cycle (18s, hadFirstResponse=true, reason=system_error)
MaxListenersExceededWarning accumulating across session (memory leak in event listeners)

Steps to Reproduce

1. Open Claude Code desktop app on Windows 11
2. Start a session in a git repository with 10 MCP servers active
3. Ask Claude to run a PowerShell command that produces large output (e.g. git log with many commits)
4. Claude starts responding normally
5. After 9–18 seconds the session crashes with "Claude Code process exited with code 1"
6. Reproduces consistently on version 1.37937.3.0

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

Claude 1.37937.3 (28dcf5) 2026-08-26T19:52:45.000Z

Claude Code Version

2.1.240 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Claude Code version: 1.37937.3.0 (Windows desktop app)
• OS: Windows 11 Enterprise 10.0.26100
• PowerShell ExecutionPolicy: RemoteSigned (CurrentUser), Bypass (Process)
• MCP servers active: 10 (sdk-type)
• Workaround found: redirecting command output to a temp file (> temp.txt) reduces crash frequency
• The internal Linux VM (cowork_vm_node) starts and connects correctly — crash is isolated to the Windows-side CLI process
• Restarting the app between heavy sessions temporarily mitigates the issue