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

Sorry I can't be more helpful here. I haven't checked this on recent releases, so I can't confirm whether the Stop-hook behavior still reproduces.

For historical context, I filed this on August 3, 2026, when v0.0.31 was the latest stable release. I didn't record my exact build, so that's a date-based reference, not a confirmed installed version.

Still reproduces on t3 v0.1.3-nightly.20261026.3726 (Linux/WSL2, Claude provider, claude-opus-5-5).

Sequence in one run / one provider turn:

1. Claude wrote the full answer (a branch table + notes).
2. The Stop hook failed (yarn typecheck, missing node_modules), so Claude continued in the same turn: 2 commands.
3. Claude ended with a short message about the hook.

After the run settled, only message 3 stayed visible; the answer from step 1 was folded under "Worked for 40s". Both messages are stored as separate assistant_message turn items in statev2.sqlite, so it's the client fold (deriveTurnFolds keeps only the last assistant message per run). #14698 fixes this case.

Another repro: plugin Stop hook returning additionalContext

Not limited to failing or user-written blocking hooks. Here it was a third-party design-lint plugin's Stop hook that returns additionalContext, after a long agent turn.

Environment: T3 Code (Nightly) app on macOS, Claude provider (Agent SDK), Opus.

Session JSONL, one turn (UTC):

UI behaviour:

• The answer rendered, then about 1 s later vanished from the conversation. Only the short post-hook text stayed; the answer was only visible after expanding "Worked for …". To a user who doesn't know to expand it, this looks like data loss.
• Repeated a few minutes later in the same thread (next hook at 01:34:55).
• The visible text replies to the hook's injected instructions, not to the user, so the shown "answer" is misleading, not just incomplete.

Mechanism (at becf853)

• deriveTerminalAssistantMessageIds picks the last assistant message per runId; the continuation shares the run.
• deriveTurnFolds folds earlier assistant text and tool work once nothing is streaming. So an already-rendered final answer gets demoted when a later message lands: the flicker.
• ClaudeAdapterV2.ts recognises /goal Stop-hook feedback, but I found no item emitted for other Stop-hook continuations, so the client has no boundary to respect.

#14698 would stop the hiding, but the continuation would still read as the answer.

Suggestions

• Treat a Stop-hook continuation as a boundary: the last assistant text before it stays a visible final message.
• Show the injection as a compact system row, e.g. "Stop hook (plugin) asked Claude to continue", followed by the continuation as its own assistant message.
• Never demote an already-rendered message into the work log.
• Optional setting: collapse continuations instead of the original.

Additional observation on macOS, 1 November 2026

The options panel remained visible, but the written answer disappeared from the default conversation view.

An inline HTML panel with four options was followed by a substantive written answer. A configured Stop hook then requested a short finish-time update. The continuation produced a brief completion notice.

The screenshot shows the HTML options/explanation panel and that short notice, while the substantive answer is absent. The user expected the actual content, not just the options. This is not a failed option-click report. The options were part of the inline HTML, not T3's native question control.

Saved history contains both assistant messages in the same run:

The blocking Stop-hook feedback occurred between those responses. The original answer remains in stored history. This supports a display or folding problem, but the affected client's expanded work log was not inspected.

Expected: keep the original written answer visible by default alongside the HTML panel. Show the hook feedback and continuation separately.

Version: running T3 server 0.1.7-nightly.20261101.4035, macOS arm64. Exact client build and surface were not independently established. One observed incident; frequency unknown.

The local hook was removed at the user's request and the answer repeated later. T3 source and database records were unchanged.

Screenshot attachment is not yet included because browser upload automation is unavailable.

PR #27747 now contains both incorporated follow-ups and the owner's newer main conflict resolution at decb42631d944e208e13509b1ddcce3743dad3bb. Hosted checks pass on that exact head and CodeRabbit reviewed it without actionable findings. The prior privacy thread is resolved. This remains open upstream; no main merge or release rollout is claimed.

Real SDK capture established the additionalContext-only hook-response path; its guarded detection shares the continuation notice with the existing synthetic-user path for blocking hooks, without duplicate block notices. The captured replay covers both continuations, while web/mobile fold regressions preserve the preceding answer. Output-bearing hook lifecycle frames are omitted from native persistence without altering adapter input.

The owner's 354-test local report applies to earlier head 3003733. Earlier live-client evidence retains its original commit labels; I have not rerun native clients at the newer head. Historical backfill and exit-code-2/SubagentStop variants are not established by this captured path. Keep this issue open until accepted coverage lands on upstream main.