[BUG] 429 mid-send leaves branch unrecoverable with No message found error despite parent UUID present in local JSONL

Resolved 💬 3 comments Opened May 3, 2026 by keitharoby-byte Closed May 7, 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?

A specific branch in a multi-branch Claude Code session becomes permanently
unrecoverable after a 429 rate limit interrupts a send. Every subsequent input
into that branch returns:

No message found with message.uuid of: <UUID>

The referenced UUID is present and intact in the local session JSONL as a
successfully completed assistant turn (stop_reason: end_turn). Other branches
in the same conversation continue to respond normally. The error therefore
appears to be a client/server (or client/index) state lookup mismatch, not a
local file corruption — the parent UUID exists locally but is reported as
missing.

Setup involves multiple git worktrees under <repo>/.claude/worktrees/ with
concurrent Claude Code subprocesses sharing the same user-data root.

What Should Happen?

A 429 rate limit should be a transient, recoverable condition. After the limit
window resets, the branch should either:

  • Cleanly retry the unsent user message against the still-valid parent UUID,

resuming the conversation normally, OR

  • Surface a clear, recoverable error (e.g., "Rate limit reached, retry in N

seconds") that lets the user retry once the window opens.

Under no circumstances should a transient 429 leave a branch permanently
unusable while pointing at a parent UUID that demonstrably exists in the
session's local JSONL.

Error Messages/Logs

Client-facing error (returned on every input attempt to the affected branch):

  No message found with message.uuid of: 35c4e901-b261-4034-865d-c065647530c6


Relevant local JSONL entries from the affected session (sanitized; full file
available on request). The supposedly-missing UUID is present here as a
completed assistant turn:

  ..."stop_reason":"end_turn",...,"uuid":"35c4e901-b261-4034-865d-c065647530c6",
  "timestamp":"2026-05-03T05:10:51.533Z","userType":"external",
  "entrypoint":"claude-desktop","sessionId":"<redacted>","version":"2.1.121",
  "gitBranch":"<redacted>"

  {"type":"queue-operation","operation":"enqueue",
   "timestamp":"2026-05-03T05:12:49.094Z","content":"<next user message>"}

  {"type":"queue-operation","operation":"dequeue",
   "timestamp":"2026-05-03T05:12:49.094Z"}

  {"parentUuid":"35c4e901-b261-4034-865d-c065647530c6",...,"type":"system",
   "subtype":"stop_hook_summary",...}

  ..."error":"rate_limit","isApiErrorMessage":true,"apiErrorStatus":429,...

  {"type":"custom-title","customTitle":"<title>","sessionId":"<redacted>"}
  {"type":"custom-title","customTitle":"<title>","sessionId":"<redacted>"}


Observations:
  - The dequeued user message is never persisted as a normal user-message
    entry with its own UUID. The 429 struck during send.
  - The two identical, back-to-back custom-title entries look like
    concurrent-writer noise from worktree subprocesses sharing the user-data
    root.

Steps to Reproduce

  1. Windows 11 host with Claude Desktop installed.
  2. Inside a git repository, create multiple worktrees under

<repo>/.claude/worktrees/<branch-name>/.

  1. Open Claude Desktop and start a Claude Code session in one of those

worktrees.

  1. Spawn additional branches in the same conversation, each in its own

worktree, so multiple Claude Code subprocesses run concurrently against
the same user-data root.

  1. Have at least one branch performing sustained background work (e.g.,

long-running API record pulls).

  1. Continue working in another branch until a 429 rate limit is encountered

mid-send (i.e., after a user message has been queued and dequeued but
before its acknowledgement is persisted).

  1. After the 429, attempt to send any new message in the affected branch.

Expected: The branch retries cleanly or surfaces a recoverable rate-limit
error.

Actual: The branch returns "No message found with message.uuid of: <UUID>"
on every subsequent input, where <UUID> is in fact the UUID of the most
recent successfully completed assistant turn and is present in the local
JSONL.

Other concurrent branches in the same conversation are unaffected.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.121

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment
OS: Windows 11 Home, 10.0.26200 Build 26200
Claude Desktop: 1.5354.0 (9a9e3d, 2026-04-29T01:14:34.000Z)
Claude Code: 2.1.121
Plan: Max
Entry point: claude-desktop
Setup: Multiple concurrent git worktrees under
<repo>/.claude/worktrees/, one Claude Code subprocess per
worktree, all sharing the same user-data root at
%USERPROFILE%\.claude\.

Zombie subprocess check (per #54130) — negative
Get-CimInstance Win32_Process -Filter "Name='claude.exe'" |
Where-Object { $_.CommandLine -like '--resume' } |
Select-Object ProcessId, CreationDate, CommandLine

All returned PIDs had CreationDate from the morning the error was first
observed. No carryover from before the rate limit. This appears to be a
distinct path to a similar symptom — corruption/desync via concurrent
in-session subprocesses without requiring stale processes from a prior
session.

Possibly related issues
#54130 — Closed Claude Code sessions leave zombie subprocesses that corrupt
session files. Same symptom, different precipitating mechanism
(no zombies here; trigger is a 429 mid-send during concurrent
worktree subprocess writes).
#48955 — Rewind in Desktop breaks for messages that originated in Claude
Code CLI. Closer match for the underlying mechanism: client holds
a parent_message_uuid that the server-side conversation tree no
longer recognizes.

Workaround
The affected branch could not be recovered. Worked around by abandoning the
branch, removing its git worktree and branch, and starting a fresh branch
seeded with relevant plan/context outputs from the original session.

Available on request

  • Full session JSONL for the affected branch
  • Logs from %USERPROFILE%\.claude\

View original on GitHub ↗

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