[BUG] Closed Claude Code sessions leave zombie subprocesses that corrupt session files ("No message found with message.uuid")

Resolved 💬 4 comments Opened Apr 28, 2026 by kunionick-0290 Closed Jun 14, 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?

Summary

Closing a Claude Code conversation window in the desktop app does not always terminate the underlying claude.exe --resume <session-id> subprocess. These zombie processes keep accessing the shared user-data directory, which causes recurring Claude Code returned an error result: No message found with message.uuid of: <UUID> errors in unrelated, currently-active conversations.

Environment

  • OS: Windows 11 Pro 26200
  • Desktop App: Claude 1.4758.0
  • claude-code: 2.1.119
  • Model: claude-opus-4-7 (1M context, effort=high)

Symptom

Over the past 2-3 days, conversations inside the desktop app frequently fail with:

Claude Code returned an error result: No message found with message.uuid of: \<UUID\>

After the error appears, the conversation becomes unresponsive to further input. The only workaround is to start a new session and manually carry over context.

Root cause (investigated)

I inspected running processes with Get-CimInstance Win32_Process -Filter "Name='claude.exe'" and found two zombie claude-code subprocesses still alive from two days earlier:

PID 22064 (started 2026-04-26 12:25:52)
  claude.exe --resume d9b3e7c2-4680-4a49-bf69-1b5ee3b0e95d --effort xhigh ...

PID 22624 (started 2026-04-26 13:37:55)
  claude.exe --resume 4dd04037-ad22-4724-9fb5-57b32d7e240a --effort medium ...

Notable: the session ID d9b3e7c2-... of PID 22064 matches exactly the ID of a previously-hung session whose window I had closed days earlier. So even though the UI showed the session as terminated, the subprocess kept running and presumably kept writing to the shared session JSONL files under C:\Users\DELL\AppData\Roaming\Claude.

After Stop-Process -Force on these two zombies (leaving only the currently-active PID 25084), the error stopped reproducing.

Hypothesis

Multiple claude-code subprocesses concurrently access the same user-data directory and corrupt the message UUID index in the session JSONL files. Windows' stricter file-locking semantics likely make the race more visible than on macOS/Linux.

Expected behavior

  1. Closing a Claude Code conversation window should reliably terminate its subprocess.
  2. Even if a zombie does occur, it should not be able to corrupt other sessions' files (per-session file/lock isolation).
  3. On app startup, detect and clean up orphaned claude-code subprocesses from prior runs.

Reproduction (suspected)

  1. Start a conversation in the desktop app; it hangs due to some other error.
  2. Close the window with the ✕ button. (Task Manager confirms the claude.exe --resume ... subprocess is still alive.)
  3. Open a new conversation and continue working. After some time, "No message found" reappears.
  4. Repeat — zombies accumulate over days.

Current workaround

The user has to periodically open Task Manager / PowerShell, find claude.exe --resume ... subprocesses that don't belong to the active window, and kill them manually. This is impractical; please consider implementing the expected behavior above.

What Should Happen?

  1. Closing a Claude Code conversation window should reliably terminate its claude.exe --resume <session-id> subprocess.
  2. Even if a zombie subprocess does occur, it should not be able to corrupt other sessions' files. Use per-session file/lock isolation.
  3. On app startup, detect and clean up orphaned claude-code subprocesses left over from prior runs.

Error Messages/Logs

Claude Code returned an error result: No message found with message.uuid of: d9f3e7a1-f668-43d1-bf91-efba9c4042a6

Steps to Reproduce

  1. Open a Claude Code conversation in the desktop app.
  2. The conversation hangs with an error (in my case, a "No message found with message.uuid" error appeared mid-conversation).
  3. Close the window using the ✕ button.
  4. Check Task Manager / PowerShell — the claude.exe --resume <session-id> ... subprocess is still running, even though the window is gone.
  5. Open a new conversation and continue working. After some time (sometimes hours, sometimes days), the same "No message found" error reappears in unrelated sessions.
  6. Repeat — zombie subprocesses accumulate. After 2-3 days I had two zombies from a previous day still alive.

To verify on Windows, run in PowerShell:

Get-CimInstance Win32_Process -Filter "Name='claude.exe'" | Where-Object { $_.CommandLine -like 'claude-code--resume*' } | Select-Object ProcessId, CreationDate, CommandLine

If multiple --resume subprocesses appear with old start times that don't match any open window, those are the zombies.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.119 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

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