[BUG] Claude desktop app becomes unresponsive after being idle, then fails to relaunch with "another program already using it"

Status Open
Maintainer reply None cached
Activity 2 comments · opened Sep 4, 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
OS: Windows 11 Home Single Language, build 10.0.26200
App version: auto-updated multiple times within a single session (observed in logs: 1.40609.1 -> 1.44121.4 -> 1.46388.1 over 2026-09-03/04)
Summary
After the machine is left idle (screen lock / sleep) for an extended period, the Claude desktop app becomes unresponsive and has to be force-closed. On relaunch, the app sometimes fails to start and shows an error saying another instance is already using it/running, even though no Claude process is actually running. Previously the only fix found was a full Windows restart.

Steps to reproduce
Leave the Claude desktop app open and let the machine sit idle (screen lock or sleep) for several hours (observed overnight, ~9-15 hours).
Wake the machine and try to use the app.
App is unresponsive / has to be killed via Task Manager.
Relaunch Claude - app shows an error that another instance is already running, even though Task Manager shows no Claude.exe/Claude Helper processes.
Previously, only a full OS restart resolved this. A lighter workaround was found: killing any leftover Claude processes and deleting the stale lock file at %APPDATA%\Claude\lockfile also unblocks it without a reboot.
Diagnostic evidence
No crash dump found in %LOCALAPPDATA%\CrashDumps and no "Application Error" event logged in Windows Event Viewer for Claude.exe - so this does not appear to be a hard OS-level crash/fault, but a hang.
%LOCALAPPDATA%\Claude\logs\main.log shows a repeating pattern: immediately after every long idle/sleep gap, background utility processes throw a burst of errors, e.g.:
[info] [UtilityProcess stderr] [5068] Fatal error: [TypeError: fetch failed]
[info] [UtilityProcess stderr] [22440] Fatal error: [TypeError: fetch failed]
One occurrence also logged an auth/session failure right after an idle gap:
[info] [oauth-v2] fresh exchange failed for orgId=... (session_stale_relogin)
%APPDATA%\Claude\lockfile (a 0-byte single-instance lock file) is left behind with a stale timestamp after the app is force-killed, which appears to be the direct cause of the "another program already using it" error on relaunch - the process that held the lock is gone, but the lock file itself was never cleaned up.
Suspected cause
Background utility/network processes (MCP/auth-related) fail to recover cleanly when the OS resumes from sleep or after a long idle period, causing the app to hang. When it's then force-closed, the single-instance lock file isn't released, blocking the next launch.

Workaround
Instead of restarting Windows, this also resolves it:

Get-Process claude* -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item "$env:APPDATA\Claude\lockfile" -Force -ErrorAction SilentlyContinue
Suggested fix directions
Make the single-instance lock file release-safe (e.g. PID-based liveness check instead of pure existence check) so a stale lock from a killed process doesn't block relaunch.
Investigate why background utility processes throw fetch failed right after system resume - likely a network-not-yet-ready race - and make them retry/backoff instead of leaving the app in a hung state.

What Should Happen?

The issue should not occur

Error Messages/Logs

Steps to Reproduce

Leave the Claude desktop app open and let the machine sit idle (screen lock or sleep) for several hours (observed overnight, ~9-15 hours).
Wake the machine and try to use the app.
App is unresponsive / has to be killed via Task Manager.
Relaunch Claude - app shows an error that another instance is already running, even though Task Manager shows no Claude.exe/Claude Helper processes.
Previously, only a full OS restart resolved this. A lighter workaround was found: killing any leftover Claude processes and deleting the stale lock file at %APPDATA%\Claude\lockfile also unblocks it without a reboot.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.46388.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗