claude-code - 💡(How to fix) Fix Bug: Claude Desktop Windows — "Claude Code process exited with code 1" every session (ref GitHub #39270) [1 comments, 2 participants]

Hi Anthropic Support,

I'm writing to report a critical, reproducible bug in Claude Desktop on Windows that has blocked my work for three days. This appears to match the pattern in open GitHub issue #39270.

Summary

Every message sent in Claude Desktop fails with "Claude Code process exited with code 1" — across every session, every project, every folder, every fresh New Session. The same claude.exe binary works perfectly when invoked directly from a terminal via a .bat launcher, so the binary itself is not broken. The failure is in how Claude Desktop spawns the child process.

Environment

• OS: Windows 10 (Build 19045.2965)
• Claude Desktop: latest version as of 2026-04-24
• Claude Code bundled binary: v2.1.111 (in AppData\Local\Packages\Claude_pzs8sxrjxfjjc...\claude-code\2.1.111\claude.exe)
• Native CLI Claude Code: v2.1.118 (works fine via launch_claude.bat)
• claude doctor output: all green (Currently running: native 2.1.111, Config: OK, Search: OK bundled)
• Project path: E:\Claude Projects (multiple drives in use)

Symptom

1. Open Claude Desktop
2. Enter any project (e.g. financial-analyzer)
3. Click "+ New session" OR open any existing session
4. Type any message — even "hi"
5. Red error appears: "Claude Code process exited with code 1"
6. No response, no stack trace in the UI

Session-level behavior: Opening an old session that previously worked also immediately exits 1. The git diff in the project quietly grows (+10,177 → +10,228 → +10,230) between crashes, suggesting the spawned process writes files before dying.

Key observation — CLI works, Desktop doesn't

Running the exact same bundled binary directly from cmd.exe with a .bat wrapper works 100%:

• Can send messages
• Gets responses
• Can edit files, run audits, produce diffs

Inside the .bat-launched CLI session I successfully ran a 10-problem project audit and applied P1+P2 fixes across 6 files. The only issue in CLI is that Bash and PowerShell tools hit a separate, already-documented tmp-path bug (ENOENT mkdir ' E:\claude-tmp...' with a leading space) — but file edit tools (Glob/Grep/Read/Edit) work fine.

Troubleshooting already attempted (none resolved)

• Full quit and restart of Desktop (Task Manager end-task all Claude processes)
• Windows restart
• Clear cache via Desktop UI (destroyed 3 important session histories with no recoverability — please fix the UX here)
• Rename project's local .claude folder (contents: launch.json 557B, plan.md 1.8KB, settings.local.json 6.9KB — permission whitelist only, no corrupt state visible)
• Test in fresh folder (same failure)
• Verify no memory/ folder anywhere in the repo despite a prior session claiming to have "saved permanent memory" — the session hallucinated the write
• Verify ANTHROPIC_API_KEY is unset in user env
• Verify E:\claude-tmp folder exists (it does, empty subfolder claude inside)
• Re-run claude doctor (all checks pass)

GitHub issue reference

#39270 — same symptom reported on macOS, still Open. Related: #38156, #49514, #8557. The pattern across these issues: the Desktop app passes something different to the spawned process than the CLI launcher does, and the child dies before first response. The unknown-window.log CSP violation noted in #39270 (blocking a-api.anthropic.com) may be a clue worth checking on the Windows build as well.

What I need from you

1. Acknowledgement that this is a known bug with a scheduled fix — even a rough ETA would help me plan
2. If there is a diagnostic log Claude Desktop writes (%APPDATA%\Claude\logs\main.log or similar) that would help your team, please tell me where it is and I'll send the contents
3. A workaround that doesn't require me to abandon the Desktop UI — I've lost three days and three sessions of context already

I'm a paying Claude Pro user, my project uses Claude extensively (1.5M+ tokens, 1,535 messages, 4 active days in the last 30). Willing to share additional diagnostics if your team needs them.

Thank you, Ert