Opus 5.5: instructed verbatim relay of a tool output over ~230 chars is never emitted as text when a tool call follows — the block is generated inside thinking (constant 274 output tokens, no text block on the wire)

Follow-up with three more results, same environment (2.1.280, Opus 5.5, effortLevel: xhigh).

1. Instructions don't reach it. A preamble explaining the mechanism — "these marked blocks are screens for the user, tool output is never shown to them, a marked block must be your next message before any further tool call, check before every tool call" — was tried both at the top of the prompt and as the project CLAUDE.md. Both runs skipped the block identically: thinking → tool_use, 274 output tokens, no text block. Same for three marker wordings, including one forbidding a rehearsal in reasoning.

2. Same shape in a real session. An unrelated interactive session running the same workflow tooling (2.1.280, Opus 5.5) shows 23 marked blocks: every block followed by a gate (turn-ending) rendered; every "display, then continue" block under xhigh was skipped except one (a 36-line list rendered once at 19:25 and the same kind skipped at 19:45). The session ran at medium until 18:58 with no mid-turn display in that window, so effort can't be separated from turn position there.

3. Delivering the block as a tool call works. With SendUserMessage available (via CLAUDE_CODE_PEWTER_OWL_TOOL=true; it is absent for Opus 5.5 by default), and the instruction changed to "deliver the section with SendUserMessage, verbatim", the model called the tool with the full 13-line block, mid-turn, with tool calls following — every time, headless and interactive, and it renders on screen identically to a normal message. A turn that ends on a SendUserMessage call trips the "[Your previous response had no visible output]" nudge, so turn-ending blocks (menus) are still emitted as text, which has always worked.

So the failure is specific to text blocks over ~230 chars followed by a tool call; the same content in a tool input is fine. Two questions on top of the original ones:

• Is relying on CLAUDE_CODE_PEWTER_OWL_TOOL reasonable, or is there a supported way to expose SendUserMessage (or an equivalent verbatim-display tool) in ordinary interactive sessions?
• Could a SendUserMessage call count as visible output for the end-of-turn nudge?

Same on Claude Code 2.1.280, Opus 5.5, Linux (WSL2), provider: LLM gateway (forceLoginGatewayUrl) → Bedrock. Four additions:

1. On gateway/Bedrock not even the summary arrives. Claude Code only upgrades the thinking display to "updates" for first-party requests (2.1.280, minified):

case"connector_text":{if((yc?.type==="adaptive"||yc?.type==="enabled")&&cc&&Oe()==="firstParty"&&ms()&&!X2()&&...){yc={...yc,display:"updates"}, ...}}

With a gateway or Bedrock the display stays "omitted", so the progress-update block is empty and the TUI shows nothing at all, not even the one-line summary.

2. It breaks AskUserQuestion. We write the context for a decision as Markdown, then call AskUserQuestion. When the text goes into the hidden block, the user gets the dialog without the context it asks about. The question field doesn't render Markdown, so the context can't move there either.

3. The signature size shows the lost text. Lost turns have the shape thinking → tool_use (sometimes thinking → thinking → tool_use) with no text block. The signature is about 2000–3200 characters, against about 1000 for an empty reasoning block, and it grows with the length of the lost text (four lost texts: 2556, 2128, 1532, 1096 against a baseline of about 900–1100).

4. Same intent, different channel. Two consecutive tests in one session, both "write long Markdown as a normal reply, then call AskUserQuestion":

• Table and list, 1270 characters: arrived as a text block.
• Three fenced code blocks, similar length: lost (thinking sig 2080 → tool_use).

As reported above, instructions don't pin the channel. The only shape that has never failed for us is text that ends the turn.

Same bug here on Claude Code 2.1.280 with claude-opus-5-5 on macOS 26.3.1, at effort medium, so it isn't only xhigh. The failing turn also contains no text block on the wire, and the lost prose comes back as a summary that the stream tags as narration. Four findings are not yet in this thread.

Exact repro

1. Start Claude Code 2.1.280 with model claude-opus-5-5. The session below ran headless (claude -p --input-format stream-json --output-format stream-json --verbose --include-partial-messages --permission-prompt-tool stdio, entrypoint sdk-cli), driven by a front end that renders the stream.
2. In an existing conversation, ask for this. The actual prompt was a short "try it" after the steps below had been discussed. The equivalent prompt is:

> Run date with Bash. After the result, write one paragraph addressed to me that contains the marker POST-TOOL-MARKER-9B2C, then call AskUserQuestion asking whether I can see that paragraph above the question.

1. The question appears with nothing above it. The paragraph is not shown before the question or after answering it.
2. Check the session .jsonl. The message that follows the date tool result is:

assistant msg_011CfKg6oXqaRbxSwwt7r9QG
  thinking  (67 chars) "Got the current date, now I'll ask the user a follow-up question.\n\n"
  tool_use  AskUserQuestion {"questions":[{"question":"Can you see the paragraph with marker POST-TOOL-MARKER-9B2C above this question?", ...}]}
usage: output_tokens 336, output_tokens_details.thinking_tokens 115

There is no text block, and the marker appears nowhere except inside the question. On the stream-json output, that assistant frame carries "narration_block_indexes":[0]. Claude Code itself classifies the thinking block as a server summary of withheld prose, not as reasoning.

Findings, from 17 marker trials in one session

1. Position matters. Prose at the start of a turn, before any tool call, was shown every time. Prose after any tool result that is followed by another tool call was lost every time. That held for paragraphs of two to five sentences, one or two tool calls first, and single or multi-question dialogs. We did not test one-line notes in this session. The final message of a turn was always shown.
2. An AskUserQuestion answer counts as a tool result. Prose written right after the user answers a question, before the next question, was lost too.
3. It isn't specific to AskUserQuestion. A paragraph written before an ordinary Bash call, with no question at all, was lost the same way. The user confirmed they never saw it. What the screen shows matches the .jsonl exactly, so the loss happens before Claude Code.
4. CLAUDE_CODE_THINKING_DISPLAY_UPDATES=false does not fix it on Opus 5.5. With it set and the session restarted, the same repro still has no text block. The thinking block's summary is simply empty instead of paraphrased. #95764 reports it helping on Opus 5. On 5.5 it only hides the summary.

Workaround that works

Text that ends a turn always arrives. So a pair of hooks can split the turn only when the bug hits:

• A PreToolUse hook on AskUserQuestion reads transcript_path back to the last user or tool_result entry. If there is no non-empty text block, it denies the call and tells the model to end its turn with the context as its final message. It has to poll briefly, up to about 0.3 s in practice, because the pending tool_use lands in the .jsonl asynchronously.
• A Stop hook sees the pending flag, blocks the stop once, and tells the model to ask the question now with no text before it.

Each state is used once, so it can't loop. It recovered the lead-in on every one of 13 hits, at about 6 s and one extra model call each. It adds nothing measurable when the bug doesn't hit.

One caveat from real use: once the model has seen a deny, it sometimes pre-empts the hook by ending its turn with "next I'll ask…" and never asking. The word "hook" or any mention of a later prompt should stay out of the deny text.

_Investigated with Claude Code, from the session's .jsonl and stream-json log._

Human here!

It'd be really great to see this sorted - we've got nearly 100 Anthropic subs at our company and this is hitting us regularly. Great models, but if we can't see what it writes sometimes that's a pretty fundamental flaw.

Happy to provide any more information.

Same here on Claude Code 2.1.281, claude-opus-5-5, effortLevel: medium, macOS.

My workflow has human approval gates. The agent prints a report, then calls AskUserQuestion in the same turn. In one session, three messages written before a tool call never became text blocks, which I confirmed by searching the session JSONL for their content:

• a sign-off report the user was supposed to review before a commit
• two later direct answers to the user's questions

In the TUI the user saw one AskUserQuestion straight after another, with nothing in between. It is intermittent: in the same session, other messages before tool calls did arrive.

The worst effect was that the model believed the report had been shown, and acted as if the gate had passed. It treated an answer to an unrelated question as approval and committed. So beyond the lost text, this breaks human-in-the-loop gates.