[BUG] Claude Desktop Windows leaves orphaned renderer processes after quit, preventing restart

Status Closed — not planned
Maintainer reply None cached
Activity 11 comments · opened Dec 26, 2025 · closed Mar 6, 2026

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?

Environment

  • Platform: Claude Desktop (Windows native application)
  • Claude Desktop version: 1.0.2339 (1782e2)
  • Build date: 2025-12-16T19:35:52.000Z
  • Operating System: Windows 11 [adjust if different]
  • Architecture: x64

Bug Description

Claude Desktop on Windows fails to properly terminate child processes when quitting the application. After quit, the parent process terminates but 6+ child "Claude" renderer processes remain running as orphans. This prevents the application from restarting - subsequent launch attempts result in immediate silent shutdown without any error message.

What Should Happen?

Expected Behavior

  • All Claude processes (parent + child renderer processes) should terminate cleanly on quit
  • Application should restart successfully without manual intervention
  • Standard Electron app lifecycle cleanup should handle all child processes

Error Messages/Logs

No error messages are displayed. But in the Windows task manager the following situation can be observed:

## Actual Behavior

- Parent Claude process (main, ~333 MB) terminates successfully
- 6+ child renderer processes remain as orphans with varying memory footprints:
  - Process 1: 181.5 MB
  - Process 2: 67.9 MB  
  - Process 3: 52.5 MB
  - Process 4: 16.4 MB
  - Process 5: 10.3 MB
  - Process 6: 4.6 MB
- All orphaned processes show:
  - 0% CPU usage
  - 0 MB/s Disk I/O
  - 0 MBit/s Network
  - Status: Running (but inactive)
- Restart fails silently until orphaned processes are manually killed
- No error logs or user-facing error messages

Steps to Reproduce

  1. Launch Claude Desktop normally
  2. Use the application (normal conversation, any features)
  3. Quit Claude Desktop via File menu → Quit, OR
  4. Open Task Manager (Ctrl+Shift+Esc)
  5. Observe: Multiple "Claude" processes still running (6+ instances) despite main window closed
  6. Attempt to restart Claude Desktop
  7. Application launches briefly then immediately shuts down without error message

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.0.2339 (1782e2) 2025-12-16T19:35:52.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Workaround

Manual process termination required before each restart:

PowerShell:

Get-Process -Name "Claude" | Stop-Process -Force

Command Prompt:

taskkill /F /IM Claude.exe

Task Manager:

  1. Select all Claude processes individually
  2. End Task for each process
  3. Only then can Claude Desktop restart successfully

Analysis

This appears to be an Electron app lifecycle bug where:

  1. The quit handler successfully terminates the main/parent process
  2. Child renderer processes (one per window/webview) are not properly signaled to terminate
  3. Process cleanup hooks are either missing or failing for renderer processes
  4. No mutex/lock file prevents launching when orphaned processes exist

Related Issues

  • Similar to #14951 (Claude Desktop macOS requires quitting twice - zombie state issue)
  • Related to #8865 (Windows background process cleanup, but for Claude Code CLI)
  • Pattern suggests cross-platform Electron cleanup problem affecting both macOS and Windows

Impact

Severity: High - Breaks normal application lifecycle

User Impact:

  • Users must manually kill processes via Task Manager after every quit
  • No clear indication to users why restart fails
  • Significant friction in normal usage workflow
  • Accumulating orphaned processes can consume system memory over time

Suggested Fix

Electron app should implement proper process cleanup:

  1. Register quit event handlers for all child processes
  2. Implement app.quit() with proper app.on('will-quit') cleanup
  3. Force terminate orphaned renderers if graceful shutdown fails
  4. Add process mutex to prevent launch when existing processes detected
  5. Provide user feedback if launch blocked by existing processes

Additional Context

  • Issue occurs consistently after every quit, regardless of usage patterns
  • No MCP servers or extensions were active during testing
  • Clean Windows installation with no known conflicts
  • Workaround confirms issue is purely process cleanup related

View original on GitHub ↗

11 Comments

github-actions[bot] · 8 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/15368
  2. https://github.com/anthropics/claude-code/issues/14951
  3. https://github.com/anthropics/claude-code/issues/8865

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

stephaneberle9 · 8 months ago

This is NOT a duplicate of the flagged issues:

  • #15368: macOS issue (different platform)
  • #14951: macOS Claude Desktop quit bug - similar symptom, different OS
  • #8865: Claude Code CLI on Windows - different product

This is the first report of Windows Claude Desktop leaving orphaned renderer processes after quit. Issue #14951 demonstrates this is a cross-platform Electron lifecycle bug affecting both macOS (zombie state) and Windows (orphaned processes).

The Windows-specific behavior (6+ orphaned renderers preventing restart) is distinct from the macOS behavior (zombie state requiring double-quit via Dock menu).

Requesting this remain open as the Windows-specific instance of this Electron cleanup bug.

github-actions[bot] · 7 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

tedfay · 7 months ago

Still occurring. Win 11 and desktop app. Both of current version. Tried resetting ap, rebooting, etc. Could also be the cause of persistent issues with Claude interfacing with Chrome. It rarely works on my PC.

running the batch mode. it does kill the processes and relaunch.

stephaneberle9 · 7 months ago

Same at my end, even though I've not stopped updating Claude Desktop to newer versions in the hope that this would help.

stephaneberle9 · 7 months ago

After having upgraded to Claude 1.1.1520 (48ced7) 2026-01-30T03:29:40.000Z this morning, the problem seems to be gone now. That's really great! Hopefully, it won't come back with any future updates.

tedfay · 6 months ago

Unfortunately I am still seeing the issue.

-= updated claude

  • exited
  • killed all the running ones in Task Manager
  • relaunched.

then rebooted.

Now just 8 running (used to be 9)

On Sat, Jan 31, 2026, at 2:06 AM, Stephan Eberle wrote:

stephaneberle9 left a comment (anthropics/claude-code#15423) <https://github.com/anthropics/claude-code/issues/15423#issuecomment-3827848460> After having upgraded to Claude 1.1.1520 (48ced7) 2026-01-30T03:29:40.000Z this morning, the problem seems to be gone now. That's really great! Hopefully, it won't come back with any future updates. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/15423#issuecomment-3827848460>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5XXMZG6NOIBHKBH7USEVYD4JRO7RAVCNFSM6AAAAACQB7KFQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMRXHA2DQNBWGA>. You are receiving this because you are subscribed to this thread.Message ID: @.***>
jcraw62 · 6 months ago

Title: MCP configuration changes not recognized due to orphaned processes persisting after app close
Environment:

Claude Desktop version: 1.1.2128 (208c9a)
Build date: 2026-02-05T17:34:22.000Z
OS: Windows 10

Description:
Claude Desktop spawns multiple processes that persist after closing the application window. These orphaned processes appear to prevent the app from recognizing changes made to claude_desktop_config.json, including MCP server configuration updates.
Symptoms:

After closing Claude Desktop, multiple Claude processes remain running in Task Manager
Changes to claude_desktop_config.json are not reflected when relaunching the app
MCP servers that were removed from the config still appear as "connected"
Even deleting the config file entirely and restarting the app still shows the old MCP servers
MCP logs have not updated in hours despite making configuration changes
New MCP server configurations fail to connect

Workaround:
Manually terminating all Claude processes in Task Manager before relaunching allows config changes to be recognized.
Related Issues:

#15423 - Claude Desktop Windows leaves orphaned renderer processes after quit
#15368 - Claude for Desktop not exiting
#8865 - Background tasks are not properly killed on Windows

This appears to be a consequence of the orphaned process issue, but the impact on MCP configuration persistence may not have been documented in those issues.

tedfay · 6 months ago

Noting issue is still occuring 8-10 instances of Claude.

  • fresh install
  • manually terminate on exit of app and relaunch still occurs (incl when rebooting system in between)
  • may also be impacting local MCP services. the connection to Google Chrome is unreliable on this Win 11 machine but works fine on the Mac.

<img width="396" height="378" alt="Image" src="https://github.com/user-attachments/assets/80caeca4-4acd-470e-bb0b-f6d8e69df6c6" />

github-actions[bot] · 5 months ago

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

github-actions[bot] · 5 months ago

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.