[BUG] Queued mid-turn message re-presented repeatedly after context compaction (delivered once, shown 8×)

Status Fixed / completed
Reported on v2.1.222
Maintainer reply None cached
Activity 1 comment · opened Aug 5, 2026 · closed Aug 5, 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?

Environment

  • Claude Code 2.1.222 (verified latest on npm at filing time), Linux, tmux TUI session
  • Model: claude-fable-5, permission mode auto
  • Very long-running operational session: hours-long turns, many background Bash tasks, multiple context compactions

Setup
Messages are delivered into the TUI programmatically (tmux bracketed paste + Enter) while the agent is mid-turn, landing in the steering queue. The transcript records a queue-operation/enqueue entry immediately with the full content, and a matching remove plus a user entry at consumption. This mechanism is heavily used in our setup and is normally exactly-once.

Bug
One specific message, delivered and consumed once, was re-presented to the model EIGHT times over ~3.5 hours — twice as fresh full user turns and six times as "The user sent a new message while you were working" mid-turn notifications — long after it had been answered.

Forensics (from the session .jsonl)

  • Exactly one delivery by the external sender (the sender's own audit log confirms one delivery of the message's idempotency marker).
  • Transcript queue accounting is balanced: 2 enqueue / 2 remove entries for the marker — yet presentations continued after balance was reached (appearances #3–#8 have no corresponding new enqueue).
  • Re-presentations cluster after long turns and appear correlated with context compaction / conversation-rebuild events.
  • 16+ other messages delivered the same way, in the same session, the same evening: all presented exactly once.

Expected
A consumed queue item is never re-presented.

Actual
The same already-answered message keeps resurfacing as if newly received. Notably, unrelated background-task notifications in the same session explicitly assert "No human input has been received…" while the harness separately replays this stale human message as fresh input.

Impact
Cosmetic-to-risky: an agent without idempotency discipline would re-execute the instruction on each replay — ours happened to be "push to production remotes", which re-run blindly would have been a repeated production action. We mitigate with content markers in delivered messages, but the harness should guarantee exactly-once presentation of queued input.

Workaround
Session restart (claude --resume <id>) is expected to clear the stale queue state; idempotency markers make repeats detectable meanwhile.

What Should Happen?

A message that has been consumed from the steering queue should be presented to the model exactly once. After it is answered, no later event — including context compaction, conversation rebuild, or a long turn — should re-present it as fresh user input.

Error Messages/Logs

Steps to Reproduce

  1. Start a Claude Code session in a tmux pane and give it long-running work (multi-minute turns with background tasks), so the session accumulates context and undergoes auto-compaction. 2. While the agent is mid-turn, deliver a message programmatically into the composer: tmux load-buffer + paste-buffer -p, then send-keys C-m. Include a unique marker string in the text so repeats are identifiable. 3. Observe the transcript JSONL: a queue-operation/enqueue entry appears immediately with the content; a remove plus a user entry appear at consumption. 4. Let the session continue working for several hours with more long turns and further compactions. 5. Observe the same marker being presented again to the model, both as new user turns and as "The user sent a new message while you were working" notifications, with no corresponding new enqueue entry in the transcript. In our session this happened 8 times over ~3.5 hours for one message, while 16+ sibling messages delivered identically were each presented exactly once.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.222 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗