Critical: Windows update/restart leaves orphaned helper processes and blocks relaunch with 'another instance is already running'

Summary

After a Claude Code update triggers an application restart on Windows, the app can become impossible to relaunch because it reports that another instance is already running.

The key problem is that the main app is no longer visibly running, but one or more hidden child/helper processes from the previous instance remain alive after the update/restart flow. From the user's perspective, Claude Code is closed, but the next launch is blocked by stale background processes that appear to keep the single-instance lock active.

This has happened repeatedly after new updates and appears to be tied specifically to the update -> restart transition.

Impact

This is a critical workflow blocker:

• Claude Code cannot be reopened after an update until hidden processes are manually killed
• The error is misleading because the main app window is gone and no obvious Claude process is visible
• Typical users will assume the app is broken and may need to reboot the machine
• The issue recurs whenever a new update is installed and the app restarts

Environment

• OS: Windows 11
• Product: Anthropic Claude Code desktop app
• Trigger: installing a new update followed by app restart/relaunch

What happens

After an update is installed, Claude Code restarts or is relaunched. Instead of starting cleanly, it reports that another instance is already running.

However, the main Claude Code app is not actually usable or visible anymore. The only remaining processes are orphaned helper/background processes from the previous instance.

In my case, the stale processes included:

• chrome-native-host.exe
• its cmd.exe wrapper process
• sometimes esbuild.exe running from a .claude/worktrees/... path

These were not obvious from a simple "find the claude.exe process" check, which makes the issue harder to diagnose.

Confirmed process evidence

The stuck state was resolved only after manually terminating leftover processes associated with Claude Code.

Observed stale processes included:

1. chrome-native-host.exe

Example command line:
"C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe" chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ --parent-window=0

1. cmd.exe

Wrapper command line launching the native host:
C:\WINDOWS\system32\cmd.exe /d /s /c ""C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe" chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ --parent-window=0"

1. esbuild.exe

Example command line:
C:\...\repo\.claude\worktrees\<worktree>\node_modules\@esbuild\win32-x64\esbuild.exe --service=... --ping

Once these processes were force-killed, Claude Code could be started normally again.

Steps to reproduce

1. Run Claude Code on Windows
2. Receive/install a new update
3. Allow the app to restart, or close and relaunch after the update
4. Attempt to open Claude Code again
5. Observe error/message indicating another instance is already running
6. Check for obvious main Claude process: often nothing clearly identifiable is running
7. Inspect child/helper processes more deeply: stale background processes remain alive from the previous instance

Expected behavior

After an update/restart:

• Claude Code should fully terminate the previous instance and all helper processes
• Relaunch should succeed immediately
• Background helper processes should not survive in a way that blocks the next launch
• If stale processes are detected, the app should recover automatically instead of refusing to start

Actual behavior

After update/restart:

• the app refuses to launch because it believes another instance is still running
• the visible/main app process is not actually usable
• hidden helper processes from the previous session remain alive
• manual intervention is required to kill the orphaned processes

Why this seems important

This does not look like a normal "user already has the app open" case. It looks like the update/restart path is not cleaning up helper processes correctly, and those orphaned processes are enough to make the next instance think the app is still active.

Because the leftover processes are not always named clearly as the main app, the failure mode is confusing and difficult to self-diagnose.

Workaround

Manual process cleanup in Task Manager / PowerShell:

• terminate chrome-native-host.exe
• terminate its cmd.exe wrapper if still present
• terminate any Claude-related esbuild.exe / worktree helper processes if they remain stuck

After doing that, the app starts normally.

Suggested areas to investigate

• update/restart shutdown path on Windows
• single-instance lock/mutex cleanup
• orphaned native host processes (chrome-native-host.exe)
• orphaned helper/build processes from .claude/worktrees
• whether the app is treating helper child processes as proof that the main app instance is still alive

This appears reproducible across updates and is severe enough that it can leave the product effectively unusable until the user manually cleans up background processes.