[BUG] Large session hangs then errors on new turn; last message lost and never persisted

Status Open
Reported on v2.1.209
Maintainer reply None cached
Activity 0 comments · opened Jul 17, 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】
On a large, long-running session, sending a new turn causes the UI to hang on
"loading" and then transition to an error screen. The session becomes unable to
respond from that point on. After restarting Claude Code, the user's last message
is gone — it never reached the server.

【Environment】

  • Claude Code version: 2.1.209
  • entrypoint: claude-desktop (Windows 11 Pro, build 26200)
  • Model: claude-opus-4-8
  • Session ID: 076833d9-e4e7-4055-b32f-e57d16a751a5

(shown in the session-management layer as local_ada18264-deec-4b80-ba51-6664feda7942)

  • Transcript: 1,204 lines / ~3.19 MB / 642 messages

(a large session with several ~70k-token subagent outputs embedded inline)

【Steps to reproduce】

  1. Open a session that has grown large (many embedded subagent investigation results).
  2. Send a short message (e.g. "How's the progress?").
  3. The "loading" state persists and, within a few round-trips, the UI moves to an error screen.
  4. Restart Claude Code and reopen the same session.

【Expected behavior】
The sent message is preserved and a response is returned. Or a clear error reason
is shown (e.g. context-window limit exceeded).

【Actual behavior】

  • Loading → error screen. The error text could not be captured / reproduced.
  • After restart, the last message is gone (it never reached the server).
  • That message is NOT recorded in the transcript body (.jsonl) at all, yet it still

appears as the last message on the session-search/management side — i.e. the
management layer and the transcript body are in an inconsistent state.

【Impact】
A large session effectively becomes unusable to continue, and the user's last input
is silently lost.

【Additional diagnostic notes】

  • Confirmed by inspecting the on-disk transcript: the last user prompt ("How's the

progress?") has 0 occurrences in the .jsonl, while the session-search index still
returns it as the most recent message.

  • The transcript's final persisted lines are TaskCreate results and a pr-link metadata

entry; the failing turn was never committed.

  • Hypothesis: assembling the next turn's request (accumulated context + multiple large

embedded subagent reports) exceeds a size/limit and fails before persistence, leaving
no error detail and dropping the turn.

Related (not duplicates): #61532, #21022, #53328

What Should Happen?

When a message is sent, it should either be delivered and answered, or fail with
a clear, visible error explaining why (e.g. "context window exceeded"). In all cases:

  1. The user's message must be persisted to the transcript (.jsonl) before or at the

moment it is accepted, so it is never silently lost on restart.

  1. The session-search/index layer and the on-disk transcript must stay consistent —

a message should never appear in the session index while being absent from the
transcript body.

  1. A large session should remain usable (or degrade gracefully with a clear warning),

rather than becoming unrecoverable and dropping the last turn with no error detail.

Error Messages/Logs

Steps to Reproduce

  1. Use Claude Code (claude-desktop on Windows 11) until a session grows large —

in my case a session with 642 messages / ~3.19 MB .jsonl, containing several
large (~70k-token) subagent investigation outputs embedded inline.

  1. Send a short new message in that session (e.g. "How's the progress?").
  2. Observe the UI stay in the "loading" state; after a few round-trips it transitions

to an error screen. The error text could not be captured.

  1. From that point the session can no longer produce a response.
  2. Restart Claude Code and reopen the same session.
  3. Observe that the message sent in step 2 is gone — it never reached the server.

Additional confirmation (from inspecting local files):

  • The message from step 2 has 0 occurrences in the on-disk transcript

(~/.claude/projects/<project>/<sessionId>.jsonl).

  • The same message still appears as the most recent message in the

session-search / management layer — i.e. the index and the transcript disagree.

  • The transcript's last persisted entries are prior tool results and a pr-link

metadata line; the failing turn was never committed.

Session ID: 076833d9-e4e7-4055-b32f-e57d16a751a5
Note: intermittent — the exact error screen could not be reproduced on demand.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.209

Platform

Other

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗