[BUG] Queued user messages not persisted to JSONL transcript — recurring unfixed issue

Resolved 💬 3 comments Opened Mar 4, 2026 by Levi-WEI-729 Closed Apr 26, 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?

⚠️ This is a recurring, unfixed bug — previously reported and auto-closed 4 times

This bug has been independently reported by 5+ users across 3 months, but every instance was auto-closed by bots without any human triage or acknowledgment:

| Issue | Title | Filed | Closed by |
|-------|-------|-------|-----------|
| #12912 | Queued prompts occasionally processed without model response and missing from history | 2025-12-02 | bot (stale) |
| #20431 | Queued/pending user input silently lost while agent is working | 2026-01-23 | bot (stale) |
| #26208 | User text messages in continuation sessions are not persisted to JSONL | 2026-02-17 | bot (duplicate → circular ref) |
| #26493 | User message missing from JSONL transcript despite being received by the model | 2026-02-18 | bot (duplicate → circular ref) |

None of these received a single human response. They form a circular duplicate chain with no primary tracking issue.

What's Wrong?

When a user sends a message while the agent is actively processing (tool calls, streaming, etc.), the message text content is:

  1. Received by the model — the assistant's response clearly references the queued message
  2. NOT written to the JSONL transcript file — the message is simply absent from the log
  3. NOT recoverable — it doesn't appear in up-arrow history or the JSONL

This occurs in all interactive modes — both the VSCode Extension and the CLI interactive TUI. Non-interactive modes (claude -p and SDK) are not affected since they don't support queued messages.

What Should Happen?

Every user message that is received and processed by the model must be persisted to the JSONL transcript file, regardless of whether it was queued during active agent processing.

Error Messages/Logs

N/A

Steps to Reproduce

  1. Open Claude Code in any interactive mode (VSCode Extension or CLI claude)
  2. Send a prompt that triggers multiple tool calls (e.g., a multi-file edit)
  3. While the agent is actively running tool calls, type and submit a follow-up message
  4. Wait for the agent to finish and respond (it will acknowledge your queued message)
  5. Check the JSONL transcript file at ~/.claude/projects/<project>/<session-id>.jsonl
  6. Observe: The queued user message is missing from the JSONL, even though the assistant responded to it

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.63

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

Root Cause Hypothesis

The JSONL write path likely has a race condition: when a user message arrives during active agent processing, the message is injected into the conversation context (so the model sees it) but the JSONL serialization step is either skipped or overwritten by the concurrent tool result writes.

Impact

  • Data loss — user input is unrecoverable after the session
  • Audit trail broken — JSONL transcripts are incomplete, making session replay/review unreliable
  • Affects automation workflows — any tool that parses JSONL for session history (hooks, reports, orchestrators) gets an incomplete picture

Additional Information

I'm filing this as a new issue because all 4 prior reports are now locked and cannot receive further comments. I respectfully request that this be triaged by a human rather than auto-closed by the duplicate detection bot.

Running v2.1.63 (not the latest v2.1.66). I reviewed the full CHANGELOG from v2.0.21 to v2.1.66 — no entry mentions a fix for JSONL transcript persistence of queued messages. The only delta between v2.1.63 and v2.1.66 is "Reduced spurious error logging", which is unrelated

View original on GitHub ↗

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