Queued human messages are misclassified as tool output and ignored

Summary

Claude Code surfaces human input submitted during a tool call as a distinct
attachment.type: "queued_command" record immediately after the next
tool_result. The model repeatedly treated that genuine input as if it were text
inside the tool output and explicitly refused to act on it, including a request to
pause.

Environment

• Claude Code 2.1.275
• macOS
• Interactive CLI session

Observed transcript sequence

For each affected message the JSONL contained:

1. queue-operation / enqueue with the human text
2. the current tool result
3. queue-operation / remove with reason: "absorbed_mid_turn"
4. a separate attachment.type: "queued_command" record with

origin.kind: "human", parented to the tool-result UUID

The rendered reminder correctly said that the user sent a new message while the
assistant was working and that Claude Code surfaces it alongside the next tool
result. Despite that, the assistant said the text was part of file-read or command
output and ignored it. This reproduced four times in one session. The same text,
resent as an ordinary post-turn user message, was accepted immediately.

One ignored queued message asked the assistant to pause at a good stopping point;
the assistant instead ran another tool before the user interrupted again.

Expected behavior

queued_command attachments with human origin should be treated as genuine user
input regardless of their adjacency or parent relationship to a tool result. A
pause/stop instruction should be honored promptly.

Notes

The terminal delivery layer only typed the text and pressed Enter. It did not edit
the transcript or append content to tool output. Claude Code itself produced the
queue-operation and queued-command records, so the ambiguity appears to be in how
the queued attachment is presented to or interpreted by the model.