claude-code - 💡(How to fix) Fix [BUG] Closed Claude Code sessions leave zombie subprocesses that corrupt session files ("No message found with message.uuid") [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54130Fetched 2026-04-28 06:38:25
View on GitHub
Comments
2
Participants
3
Timeline
6
Reactions
0
Timeline (top)
labeled ×4commented ×2

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.

Error Message

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.

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. After Stop-Process -Force on these two zombies (leaving only the currently-active PID 25084), the error stopped reproducing.

  1. Start a conversation in the desktop app; it hangs due to some other error.

Error Messages/Logs

Claude Code returned an error result: No message found with message.uuid of: d9f3e7a1-f668-43d1-bf91-efba9c4042a6 2. The conversation hangs with an error (in my case, a "No message found with message.uuid" error appeared mid-conversation). 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.

Root Cause

Root cause (investigated)

Fix Action

Fix / Workaround

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.

Current workaround

Code Example

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 ...

---

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

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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

extent analysis

TL;DR

The issue can be mitigated by ensuring that the claude.exe --resume <session-id> subprocess is properly terminated when a conversation window is closed.

Guidance

  • Verify that the subprocess is terminated by checking the Task Manager or using PowerShell command Get-CimInstance Win32_Process -Filter "Name='claude.exe'" after closing a conversation window.
  • Implement per-session file/lock isolation to prevent zombie subprocesses from corrupting other sessions' files.
  • On app startup, detect and clean up orphaned claude-code subprocesses left over from prior runs to prevent accumulation of zombies.
  • Consider adding a mechanism to automatically terminate subprocesses when a conversation window is closed, such as using a timeout or a signal to stop the subprocess.

Example

No code snippet is provided as the issue is related to process management and file locking, which requires a more comprehensive solution.

Notes

The issue seems to be related to the way the claude.exe --resume <session-id> subprocesses are managed, and the lack of proper termination when a conversation window is closed. The provided information suggests that this is a regression, and the previous version worked as expected.

Recommendation

Apply a workaround to ensure proper termination of subprocesses when a conversation window is closed, and consider implementing per-session file/lock isolation to prevent corruption of other sessions' files. This can be done by modifying the app to properly manage the subprocesses and adding mechanisms to detect and clean up orphaned processes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Closed Claude Code sessions leave zombie subprocesses that corrupt session files ("No message found with message.uuid") [2 comments, 3 participants]