Before opening, please confirm:
Operating System
kernel_version = "5.10.268-277.1095.amzn2int.x86_64" id = "amzn" name = "Amazon Linux" pretty_name = "Amazon Linux 2" version_id = "2" version = "2" variant = "internal"
Kiro Version
version = "2.24.1" hash = "0e0f0e19e4c2ea4c94e552f834baf85de11476fa" date = "2026-09-25T02:19:54.86796Z (2d ago)" variant = "minimal"
Bug Description
kiro-cli streamed a substantive part of the assistant's answer (a multi-section teaching block with headings, tables, and code) tagged as reasoning/thinking content rather than answer content. A downstream client (KiroCrew dashboard) faithfully rendered it inside its collapsible "Reasoning" disclosure, which is hidden/collapsed by default — so the user never saw a deliverable they needed.
During a normal chat turn, the assistant produced a long answer. A trailing section of that answer (an explanatory teaching block that was clearly answer content, not internal reasoning) was streamed such that the consuming client classified it as reasoning and folded it into a collapsed "Reasoning" block. The rest of the same turn's answer rendered normally as visible content.
Steps to Reproduce
Not deterministically reproduced. Observed on a long answer where a trailing explanatory section was misclassified as reasoning while earlier answer content in the same turn rendered normally. Likely tied to how the reasoning→answer boundary is drawn within a single turn.
Expected Behavior
Answer content intended for the user should be streamed as answer content (agent_message_chunk with a normal content type), not as agent_thought_chunk or content.type: "thinking"|"reasoning". Reasoning tokens and final answer tokens should be cleanly separated on the wire.
Conversation ID
No response
Additional Context
Answer content emitted as reasoning/thinking tokens, hiding substantive output in collapsible reasoning UI
Summary
kiro-cli streamed a substantive part of the assistant's answer (a multi-section teaching block with headings, tables, and code) tagged as reasoning/thinking content rather than answer content. A downstream client (KiroCrew dashboard) faithfully rendered it inside its collapsible "Reasoning" disclosure, which is hidden/collapsed by default — so the user never saw a deliverable they needed.
Environment
- kiro-cli version: 2.24.1
- Transport: ACP (agent_message_chunk / agent_thought_chunk)
- Client: KiroCrew dashboard (renders
content.type verbatim, no client-side heuristics)
What happened
During a normal chat turn, the assistant produced a long answer. A trailing section of that answer (an explanatory teaching block that was clearly answer content, not internal reasoning) was streamed such that the consuming client classified it as reasoning and folded it into a collapsed "Reasoning" block. The rest of the same turn's answer rendered normally as visible content.
Expected
Answer content intended for the user should be streamed as answer content (agent_message_chunk with a normal content type), not as agent_thought_chunk or content.type: "thinking"|"reasoning". Reasoning tokens and final answer tokens should be cleanly separated on the wire.
Actual
Part of the final answer was streamed under a reasoning classification, so a reasoning-aware client hid it in a collapsible reasoning region.
Root-cause analysis (from the consuming client's side)
The client's chunk classifier is a pure pass-through of the CLI's stamp — it flags a chunk as reasoning only when:
- the chunk kind is
agent_thought_chunk, OR
- an
agent_message_chunk carries inner content.type in ("thinking", "reasoning").
There is no client-side heuristic that could independently misclassify answer text. That isolates the origin to kiro-cli's chunk labeling: the answer content was emitted under one of the two reasoning signals above.
Impact
Substantive, user-requested output silently disappears into a collapsed reasoning UI. Users can miss deliverables entirely without any indication content was hidden. This affects any reasoning-aware ACP client, not just one dashboard.
Reproduction
Not deterministically reproduced. Observed on a long answer where a trailing explanatory section was misclassified as reasoning while earlier answer content in the same turn rendered normally. Likely tied to how the reasoning→answer boundary is drawn within a single turn.
Evidence caveat
The exact offending ACP frame could not be captured: reasoning frames are client-only and are not persisted, and the gateway stdout had already rotated past the relevant timestamp. The persisted transcript shows the section as normal answer markdown (no reasoning markers), which confirms the misclassification occurred on the wire during streaming, not in stored data.
Suggested fix direction
- Ensure final-answer tokens are never emitted with
content.type: "thinking"|"reasoning" or as agent_thought_chunk.
- Enforce a clear reasoning→answer boundary within a turn so that once answer content begins, subsequent content in that turn is not re-tagged as reasoning.
Before opening, please confirm:
Operating System
kernel_version = "5.10.268-277.1095.amzn2int.x86_64" id = "amzn" name = "Amazon Linux" pretty_name = "Amazon Linux 2" version_id = "2" version = "2" variant = "internal"
Kiro Version
version = "2.24.1" hash = "0e0f0e19e4c2ea4c94e552f834baf85de11476fa" date = "2026-09-25T02:19:54.86796Z (2d ago)" variant = "minimal"
Bug Description
kiro-cli streamed a substantive part of the assistant's answer (a multi-section teaching block with headings, tables, and code) tagged as reasoning/thinking content rather than answer content. A downstream client (KiroCrew dashboard) faithfully rendered it inside its collapsible "Reasoning" disclosure, which is hidden/collapsed by default — so the user never saw a deliverable they needed.
During a normal chat turn, the assistant produced a long answer. A trailing section of that answer (an explanatory teaching block that was clearly answer content, not internal reasoning) was streamed such that the consuming client classified it as reasoning and folded it into a collapsed "Reasoning" block. The rest of the same turn's answer rendered normally as visible content.
Steps to Reproduce
Not deterministically reproduced. Observed on a long answer where a trailing explanatory section was misclassified as reasoning while earlier answer content in the same turn rendered normally. Likely tied to how the reasoning→answer boundary is drawn within a single turn.
Expected Behavior
Answer content intended for the user should be streamed as answer content (agent_message_chunk with a normal content type), not as agent_thought_chunk or content.type: "thinking"|"reasoning". Reasoning tokens and final answer tokens should be cleanly separated on the wire.
Conversation ID
No response
Additional Context
Answer content emitted as reasoning/thinking tokens, hiding substantive output in collapsible reasoning UI
Summary
kiro-cli streamed a substantive part of the assistant's answer (a multi-section teaching block with headings, tables, and code) tagged as reasoning/thinking content rather than answer content. A downstream client (KiroCrew dashboard) faithfully rendered it inside its collapsible "Reasoning" disclosure, which is hidden/collapsed by default — so the user never saw a deliverable they needed.
Environment
content.typeverbatim, no client-side heuristics)What happened
During a normal chat turn, the assistant produced a long answer. A trailing section of that answer (an explanatory teaching block that was clearly answer content, not internal reasoning) was streamed such that the consuming client classified it as reasoning and folded it into a collapsed "Reasoning" block. The rest of the same turn's answer rendered normally as visible content.
Expected
Answer content intended for the user should be streamed as answer content (
agent_message_chunkwith a normal content type), not asagent_thought_chunkorcontent.type: "thinking"|"reasoning". Reasoning tokens and final answer tokens should be cleanly separated on the wire.Actual
Part of the final answer was streamed under a reasoning classification, so a reasoning-aware client hid it in a collapsible reasoning region.
Root-cause analysis (from the consuming client's side)
The client's chunk classifier is a pure pass-through of the CLI's stamp — it flags a chunk as reasoning only when:
agent_thought_chunk, ORagent_message_chunkcarries innercontent.typein("thinking", "reasoning").There is no client-side heuristic that could independently misclassify answer text. That isolates the origin to kiro-cli's chunk labeling: the answer content was emitted under one of the two reasoning signals above.
Impact
Substantive, user-requested output silently disappears into a collapsed reasoning UI. Users can miss deliverables entirely without any indication content was hidden. This affects any reasoning-aware ACP client, not just one dashboard.
Reproduction
Not deterministically reproduced. Observed on a long answer where a trailing explanatory section was misclassified as reasoning while earlier answer content in the same turn rendered normally. Likely tied to how the reasoning→answer boundary is drawn within a single turn.
Evidence caveat
The exact offending ACP frame could not be captured: reasoning frames are client-only and are not persisted, and the gateway stdout had already rotated past the relevant timestamp. The persisted transcript shows the section as normal answer markdown (no reasoning markers), which confirms the misclassification occurred on the wire during streaming, not in stored data.
Suggested fix direction
content.type: "thinking"|"reasoning"or asagent_thought_chunk.