[BUG] Silent graceful exit during Write/Bash operations on Windows (NPM installation)

Additional info:

Node.js version: v22.19.0

Related Windows silent exit issues:

• #21831 — Silent exit when clearing .next cache (file system error trigger)
• #22226 — Silent crash on large paste input (input size trigger)

All three issues share the same symptom (silent exit, no error message, exit code 0) but different triggers. This suggests a common underlying issue in Windows error handling or async operation management.

Debug log from crashed session attached:

https://gist.github.com/renatoacairo/040469e1978acf655edef14b1d9386d9

Key observation (lines 387-409):

• Write operation completes successfully (line 395: "File written atomically")
• PostToolUse hooks complete (line 400)
• LSP Diagnostics check (line 402)
• New API request preparation begins (lines 403-407)
• Last entry (line 408): [lspRecommendation] Looking for LSP plugins for .py
• Process exits with status 0 — no error logged

The log shows normal operation right up until the sudden exit. Something in the LSP recommendation lookup or subsequent API request handling triggers process.exit(0) without logging an error.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/20782
2. https://github.com/anthropics/claude-code/issues/21831
3. https://github.com/anthropics/claude-code/issues/20759

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is NOT a duplicate of #20782, #21831, or #20759.

Those issues all have identifiable errors in their logs:

• #20782: Tool mcp__plugin_playwright_playwright__browser_install not found (MCP error)
• #21831: SyntaxError: Unexpected token in .jsonl files (corrupted session files)
• #20759: Same JSON parsing errors as #21831

All three are from the same author, same project, with the same corrupted session files causing parse errors.

This issue is fundamentally different:

| Evidence | Other issues | This issue |
|----------|-------------|------------|
| Error logs | Have stack traces | None |
| Debug log | Shows errors | Shows normal operation → sudden exit |
| Root cause | Visible (corrupted files, MCP) | Unknown - no error logged |
| Diagnostic depth | Feedback submission | Process Monitor, crash dump analysis, debug logs |

The entire point of this bug report is that there is no error. The process calls process.exit(0) during normal operation without logging anything. This is proven by:

1. Exit code 0 (not a crash)
2. No crash dump generated despite dump collection being configured
3. Debug log showing clean operation until mid-API-request sudden stop
4. Process Monitor confirming graceful shutdown sequence

Closing this as a duplicate of issues that have identifiable errors would lose the investigation into why Claude Code silently exits without any error during normal Write operations.

New evidence: Multi-tab crash pattern (2026-02-03)

Just experienced a crash affecting 2 out of 4 open tabs simultaneously, with the other 2 surviving. This provides new diagnostic data.

Crash details

| Tab | Project | State at crash | Outcome |
|-----|---------|----------------|---------|
| 1 | igum | Mid-Update (editing tools\evals\checks.py) | CRASHED |
| 2 | claude-code-backup | Permission prompt (waiting for user input on git commit) | CRASHED |
| 3 | breshowzinho-automator | Idle | Survived |
| 4 | igum | Idle | Survived |

What this rules out

• Not project-specific — Two different projects crashed
• Not MCP-related — Same project (igum) had one tab crash and one survive
• Not Windows Terminal crash — That would kill all 4 tabs (parent process)

Pattern identified

Active/transitioning tabs crash. Long-idle tabs survive.

The crashed tabs were either:

1. Actively processing a tool result (mid-Update)
2. In a permission prompt state (post-response, waiting for input)

The surviving tabs had been idle for some time with no active API connection or internal state processing.

Additional crash (same day)

A separate tab crashed right after Claude finished responding — the response was fully rendered, waiting for my input. Last visible output:

● Good catches. Let me address both:
  [... detailed response about CI path filters and Haiku vs Sonnet ...]
  Want me to update the workflow with the path filters?

This is consistent with the debug log findings: crashes occur in the post-tool-completion transition (after PostToolUse hook completed, while LSP/API initialization runs).

Refined hypothesis

The exit isn't triggered by Write/Bash operations themselves, but by the transition state after tool completion — specifically during LSP diagnostics, API client creation, or OAuth token checks (as shown in the debug log). Tabs that are fully idle have exited this vulnerable state; tabs actively processing or just-finished remain in it.

Update: WSL/Ubuntu stability finding

After switching from native Windows (PowerShell) to WSL/Ubuntu, no crashes have occurred even during heavy coding sessions with multiple Write/Edit/Bash operations.

Environment comparison

| Factor | Native Windows (crashes) | WSL/Ubuntu (stable) |
|--------|--------------------------|---------------------|
| Shell | PowerShell | Bash |
| File system | NTFS | ext4 (through WSL2) |
| Node.js build | Windows | Linux |
| Terminal | Windows Terminal (native tab) | Windows Terminal (WSL tab) |

Implications

This strongly suggests the issue is Windows-specific, likely related to:

1. Windows file I/O handling (NTFS vs ext4)
2. Node.js Windows build behavior (signal/process handling)
3. PowerShell vs Bash interactions with the Claude Code process
4. Windows-specific code paths in Claude Code

Workaround

For Windows users experiencing this: Running Claude Code in WSL instead of native Windows appears to avoid the crashes entirely.

This doesn't fix the underlying bug but may help other users until it's addressed.

This is possible the same issue I reported today in #30959 which I closed in favor of this.

Any luck with this? I believe my issue #32386 could be the same issue you are experiencing.

This happens like ten times a day - sometimes immediately after you send a message and other times twenty minutes into an agent's work. This is really undermining the promise of agentic workflows.

I've noticed on my case, after agents started crafting data from my Spec-Driven Dev, my RAM usage went up to 96% and terminal froze. A few seconds later, Claude exited to powershell.

In my case the exit does not seem related to RAM usage from what I can tell but my eyes aren't glued to Task Manager so it's possible that there's a sudden and large spike and Claude Code exits. But this issue seems entirely to revolve around unexpected graceful exits.

When memory is under strain I've seen Bun crashes or other non-graceful exits but this seems different and I've even seen it within a moment of submitting my message which seems unlikely Claude would have had time to spike the memory without some serious flaw.

Seems like a different but fun Claude Code exit that occurs due to something specific to the directory:

~~I can no longer use Claude Code on my Windows machine as a result of my issue, which may be distinct from the original issue based on what I'm seeing now. The version has not changed (2.1.69) however it consistently exits within 15 seconds. This sort of issue on Windows really needs attention. It is now a show-stopper for me.~~

~~I tried updating Claude Code to 2.1.79 and I tried Cygwin and Cmd but both exit the same way. Deleted .claude/settings.json but the problem persists.~~

~~claude doctor shows nothing obviously wrong.~~

Edit: My issue here was #36400. I still see this issue (22735) in addition though.

My issue was closed in favor of this one, despite the fact that for me it is happening with the native install, not the NPM installation.

Also I have additional information, when kicked out of Claude Code and back into the terminal, [O[I[O[I[O[ is output into the command line as though it is user input.


@MichaelCharles mine is also native install. Never seen the character string but I'm not in PowerShell.

Another symptom at least in my case is that if I /resume a chat that previously failed, upon resume it immediately exits and kicks me back to the command prompt.

So I had Claude Code work on this issue in my environment and it came up with a workaround that is, so far, working for me. I had it summarize it's findings which I've edited and copy/pasted below.

---

Root Cause Analysis & Workaround

Finding

Claude Code registers multiple process.on("SIGINT") handlers. The first one registered (in the main entry function, VLY in minified code) calls process.exit(0) directly with no logging:

// Handler 1 — registered first, in main entry point
process.on("SIGINT", () => {
  if (process.argv.includes("-p") || process.argv.includes("--print")) return;
  process.exit(0);  // immediate exit, no logging
});

A second handler registered later during initialization does the right thing — logs a shutdown signal and performs graceful cleanup:

// Handler 2 — registered later, during init
process.on("SIGINT", () => {
  o8("info", "shutdown_signal", { signal: "SIGINT" });
  kq(0);  // graceful shutdown
});

Since Node.js calls listeners in registration order and process.exit() is synchronous, Handler 1 kills the process before Handler 2 ever runs. This explains:

• Exit code 0 — explicit process.exit(0)
• No error or shutdown log — Handler 1 has no logging
• No crash dump — it's a clean exit

Debug logs from crashed sessions confirm this: they end abruptly with no shutdown_signal entry, which would be present if Handler 2 had run.

Something on Windows is delivering SIGINT to the process during normal operation. I didn't determine exactly what, but it's happening during concurrent I/O (post-tool-use hooks, LSP diagnostics, API requests). It's also worth noting that there's an orphan detection mechanism (checking stdout.writable/stdin.readable) that is explicitly skipped on Windows via a process.platform !== "win32" guard.

Resume behavior

This also explains why /resume-ing a crashed session immediately crashes again — resuming replays the conversation through the same code paths and I/O patterns, recreating the conditions that trigger the spurious SIGINT.

Workaround

I patched the npm-installed cli.js to make Handler 1 a no-op, deferring to Handler 2 for graceful shutdown:

mkdir -p ~/.claude-patched && cd ~/.claude-patched
npm init -y && npm install @anthropic-ai/claude-code

sed -i 's/process\.on("SIGINT",()=>{if(process\.argv\.includes("-p")||process\.argv\.includes("--print"))return;process\.exit(0)})/process.on("SIGINT",()=>{if(process.argv.includes("-p")||process.argv.includes("--print"))return;\/\*patched:noop,defer to graceful handler\*\/})/' \
  node_modules/@anthropic-ai/claude-code/cli.js

# Run with:
node node_modules/@anthropic-ai/claude-code/cli.js

Suggested fix

The SIGINT handler in the main entry function (VLY) should either be removed entirely or changed to use the graceful shutdown path (kq(0)) instead of process.exit(0). The handler registered during initialization already handles SIGINT properly.

I've been using Claude Code heavily since creating the patched version I described in the comment above, and I'm no longer having this issue. This does seem to be something that can be resolved by updating cli.js.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.