claude.exe exits with code 0, zero output on stdout/stderr, for any command

Open 💬 0 comments Opened Jun 29, 2026 by drewwilliamsquant

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?

Every invocation of claude.exe — claude --version, claude --help, claude doctor, and bare claude — exits immediately with code 0 and produces zero output on stdout or stderr, in both Windows Terminal and legacy PowerShell. No error message, no crash dialog, no Windows Event Log entry, no crash dump. Execution time measured at ~19ms via Measure-Command, confirming it exits cleanly rather than hanging (also confirmed via an audible beep test immediately after the call).

Ruled out: corrupted binary (correct file size, 234,930,336 bytes), Mark-of-the-Web block (no Zone.Identifier stream present), Windows Defender (zero detections via Get-MpThreatDetection), npm vs native install (both fail identically, including after a clean npm uninstall/reinstall), terminal host (confirmed running inside real Windows Terminal via $env:WT_SESSION returning a valid GUID), a stale ANTHROPIC_API_KEY environment variable (removed, no change in behavior), Claude Desktop interference (fully terminated via Task Manager before retesting, no change), and missing config (~/.claude folder is created correctly on first run, contains backups/cache/downloads folders and a valid settings.json).

claude --debug --version produces no debug log file at all in ~/.claude/debug/ — the folder is never even created, meaning the failure happens before the debug logger initializes.

A filtered Process Monitor trace (Process Name is claude.exe) shows real activity, not a no-op: hundreds of sequential WriteFile operations at increasing byte offsets against C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxdjjc\LocalCache\Roaming\Claude\IndexedDB\https_claude.ai_0.indexeddb.leveldb\... — a LevelDB store tied to the separately-installed Claude Desktop app's storage — even with Claude Desktop fully closed via Task Manager beforehand. Also several NAME_NOT_FOUND / PATH_NOT_FOUND results against AppData\Roaming\Claude\... paths early in the trace.

Environment: Claude Code 2.1.195 (native installer; also reproduced on npm-installed 2.1.191), Windows 11 build 26100.8655, Node.js v24.18.0 (confirmed working independently via direct console.log test).

What Should Happen?

claude --version should print the installed version string. claude --help should print usage text. claude doctor should print a diagnostic report. None of these should touch IndexedDB/LevelDB storage belonging to a separately installed desktop application, or produce zero output with no error of any kind.

Error Messages/Logs

None produced. No stdout, no stderr, no Windows Event Log entry, no crash dump in %LOCALAPPDATA%\CrashDumps, and no debug log file created even when run with --debug (the ~/.claude/debug/ folder is never created at all).

The only observable evidence comes from a filtered Process Monitor capture (Process Name is claude.exe), which shows real file activity rather than silence:

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxdjjc\LocalCache\Roaming\Claude\IndexedDB\https_claude.ai_0.indexeddb.leveldb\ — hundreds of sequential WriteFile calls at increasing offsets (observed past 1,015,808 bytes) into what appears to be a LevelDB log/blob file

C:\Users\<user>\AppData\Roaming\Claude\... — multiple NAME_NOT_FOUND / PATH_NOT_FOUND results early in the trace

Happy to attach the full Procmon capture (.PML file) if useful for triage.

Steps to Reproduce

  1. Windows 11 (build 26100), Claude Desktop already installed
  2. Install Claude Code via native installer: irm https://claude.ai/install.ps1 | iex
  3. Open a new terminal window (reproduced in both Windows Terminal and legacy Windows PowerShell 5.1)
  4. cd to any directory
  5. Run: claude --version
  6. Observe: process exits with code 0 in ~19ms, zero output printed

Same result for: claude --help, claude doctor, bare claude, and claude -p "say hi"

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.195

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Happy to provide the full Process Monitor capture (.PML file) if useful — it was filtered to Process Name is claude.exe and shows the complete sequence of file operations across a single --version invocation.

One detail that may be relevant: Claude Desktop is also installed on this machine (Claude_1.15962.1.0_x64__pzs8sxrjxdjjc). The IndexedDB/LevelDB write activity observed in the trace is associated with Desktop's storage path, even though Desktop was fully closed via Task Manager before the affected test runs. Not certain if this points to a shared component between the CLI and Desktop installs, or if it's unrelated and the CLI happens to initialize the same Electron/Chromium storage layer independently.

Also worth noting: the original npm install (@anthropic-ai/claude-code@2.1.191) silently failed to run its postinstall script due to an unapproved-scripts warning from npm (allow-scripts), which left the package folder completely empty despite npm reporting a successful install. A clean uninstall, npm cache clean --force, and reinstall fixed that specific issue and populated all expected files — but the resulting binary still exhibits the exact same silent-exit behavior as the native installer's claude.exe. Mentioning this in case it's a separate, worth-fixing issue on its own (npm install succeeding while silently producing a non-functional package).

View original on GitHub ↗