Claude stop-hook continuation hides the original assistant response #5297

Bug

When Claude Code runs a configured Stop hook that injects a follow-up message, T3 Code does not clearly preserve and display the full sequence of events in the main conversation UI.

This happens across T3 Code platforms, including mobile.

What happens

The underlying Claude Code sequence is effectively:

1. User sends a message.
2. Claude completes its original response.
3. A configured Stop hook runs and supplies another message/instruction to Claude.
4. Claude responds to the stop-hook message and then stops.

In T3 Code, the original response from step 2 is not clearly shown as its own visible assistant message before the stop hook. Instead, the stop-hook activity and/or earlier output can be condensed into the expandable work log, while the main conversation primarily shows the final response after the hook.

This is dangerous because the first response often contains the main result, summary, warnings, or other important information. The user may forget that the stop hook ran, never expand the work log, and miss information Claude believes it already delivered.

Expected behavior

By default, T3 Code should visibly preserve the full chronological sequence in the main conversation, for example:

1. Assistant: original response before the stop hook
2. Stop hook: shown as an additional user message, system-style event, or another clearly distinct visible entry
3. Assistant: response after the stop hook

The exact visual treatment of the stop hook can vary, but the important requirements are:

• The assistant response produced before the stop hook must be visible by default.
• The UI must clearly indicate that a stop hook ran.
• The assistant response produced after the stop hook must also be visible.
• None of these should require expanding the work log to discover them.
• The sequence must remain in the correct chronological order.

Scope

I have confirmed this with Claude Code. After reviewing the behavior further, I do not believe this issue applies to Codex, and I cannot confirm it for other harnesses.