fix: Claude Stop-hook continuations no longer hide the answer#27747

Approvability

Verdict: Approved at 8bcf140

Macroscope's review found this PR approvable — Claude Stop-hook continuations now show a notice and keep the preceding answer visible on web and mobile. The change is narrowly scoped to timeline presentation and does not alter hook execution or continuation behavior.

^{You can add or adjust custom eligibility rules. Learn more.}

Explain Change →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 4f0b74e
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 3d2fe12c-a9c0-42e1-90d3-576da3f2837c

External image Commits

Reviewing files that changed from the base of the PR and between decb42631d944e208e13509b1ddcce3743dad3bb and ae45985a9d6f92eb245aa041a4b257c97e7b4794.

External image Files selected for processing: 4

• apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts
• apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts
• apps/web/src/components/chat/MessagesTimeline.logic.test.ts
• packages/contracts/src/orchestrationV2.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Verified in a real dev environment

verified the stop-hook visibility fix at exact head 8bcf140e039e30796632c38853e8dcfaaff39188 on a linux boat vm using the real web app, repository playwright, and /usr/bin/google-chrome. no source changes were needed.

• installed and ran github/main (7195b69954) in its own worktree first. a real claude haiku 5.5 turn ran pwd, answered the multiplication question, then continued after a project stop hook blocked once. after completion, only the hook acknowledgement was visible. expanding the work fold revealed the original answer.
• stopped main, installed the exact pr head, and ran it with isolated app state. the same project, prompt, hook, provider and model kept the original answer, hook notice, and acknowledgement visible after completion. an existing-thread follow-up streamed and completed without a reload, keeping both answers visible.
• expanded and collapsed the work fold: tool and reasoning entries still fold while the answer stays visible. expanded the hook notice and saw the real hook reason. reloaded the thread and confirmed the persisted result.
• a real no-hook claude turn completed with its normal answer and no hook notice. real codex gpt-6.1-sol turns created and inspected the project hook through the app.
• blacksmith ran the three changed test files: 260 adapter, 90 web timeline, and 43 mobile feed tests passed, 393 total. existing github ci is green.

found a separate limitation: the first response in a newly created thread did not display until a reload. this occurred for codex and claude, with and without the hook. i reproduced it on the pr parent 32ecd71726 with a real no-hook claude turn: the server had the completed answer while the client showed only the prompt. existing-thread live updates worked on the pr. this predates the visibility fix and was left outside its scope.

before, main:

main folds the original answer and leaves only the hook acknowledgement

after, exact pr head:

pr keeps the answer, stop hook notice, and acknowledgement visible

real app fold and hook detail interactions

read-only command transcript of persisted real provider results

Not verified

native electron, ios and android clients; relay or tunnel connections; live /goal handling; multiple hooks in one run. those need additional client or scenario runs. mobile folding, multiple-hook folding and goal exclusion were covered by the passing existing tests, not by native-client evidence. claude used the vm proxy rather than a direct subscription login. fresh-thread live updates remain broken as described above.

Live SDK capture for #5297, checked against head 8bcf140e03. The Stop hook returned only hookSpecificOutput.additionalContext. The capture shows that this head does not detect the continuation on that path.

Setup: one run of apps/server/scripts/record-claude-agent-sdk-replay-fixture.ts with @anthropic-ai/claude-agent-sdk 0.3.276, Claude Code 2.1.317 and claude-sonnet-4-6, using the adapter's default query options (includeHookEvents is not set). It ran in a throwaway project with an isolated config dir, so no user hooks were loaded. The project's .claude/settings.json Stop command hook printed {"hookSpecificOutput":{"hookEventName":"Stop","additionalContext":"Reply with exactly: STOP_HOOK_REPLY"}} on the first stop only.

Frames between the answer and the reply:

• There is no type:"user" frame: no isSynthetic, no parent_tool_use_id, no Stop hook feedback:\n prefix. There is also no stop_hook_summary frame.
• The hook text appears nowhere in the stream.
• So the new branch in ClaudeAdapterV2.ts never matches. When the capture is replayed through ClaudeReplayFixtures.integration.test.ts, the run completes with ["STOP_HOOK_ANSWER", "STOP_HOOK_REPLY"] and no notification between them. The web and mobile fold changes key on that notification, so they never trigger.

Scope: this covers only the additionalContext path. I did not capture a decision: "block" / reason Stop hook, so I'm not claiming anything about the synthetic-user-frame shape the unit tests use. That shape may be correct for block-style hooks; the existing /goal detection relies on it too.

On this capture, the only signal is the second assistant message arriving without a new prompt, after a requesting status. Making that reliable would probably need includeHookEvents: true (hook_response frames). I haven't captured that shape yet, so I'm not proposing a fix here. A follow-up run with that option would settle it.

I have a test-only patch ready (recorder scenario, sanitized fixture, failing replay regression). I haven't pushed it here because it would turn CI red without a fix.

— Claude Opus 5.5 via Claude Code, on behalf of @elliotdrel

The additionalContext-only gap from the live capture now has a proposed correction at https://github.com/AppLoidx/t3code/pull/1 (731ba917db), targeting this PR's branch. A second real SDK capture with includeHookEvents enabled records an additionalContext Stop response, a block response plus synthetic user feedback, and a plain stop. The adapter uses the explicit successful Stop hook_response output for additionalContext and retains the existing user-frame path for blocks, avoiding duplicate block notices.

The captured replay passes after the change and fails with the original adapter. Independent source review found one output-discriminator gap, now fixed: hookSpecificOutput must explicitly name Stop. Missing/wrong discriminator regressions failed before and pass with the guard. Eleven focused hook/goal/replay tests and targeted lint/typecheck pass at the corrected head. Full-suite validation remains limited: 15 tests fail both with the correction and original adapter on the same machine; those suites are not passing evidence. The fork follow-up has no reported hosted checks. The author incorporated the corrected contribution at upstream head 7cc33d2f045c01d278d642d239e8adc0b956c54c, whose merge parents include 731ba917db. New-head CI still requires repository authorization; prior-head passes do not establish the updated result.

Thanks @ElliotDrel. Merged your follow-up (AppLoidx/t3code#1) into this branch; head is now 7cc33d2f04.

What it adds:

• includeHookEvents: true, so a Stop hook that only returns hookSpecificOutput.additionalContext now shows the continuation notice (read from the successful Stop hook_response).
• Blocking hooks keep the existing synthetic user-frame path, so there is still one notice per block.
• Hook output must name hookEventName: "Stop".
• Live replay fixture claude_stop_hook_continuation plus adapter tests.

I checked that the extra hook frames are not treated as turn-start or root-turn frames, so they cannot open a turn. CI will rerun on the new head.

Confirmed the merge ancestry includes the final 731ba917db discriminator guard and regression cases. I updated #5297 coverage and the earlier follow-up status to reflect incorporation. The remaining action-required workflows have no executed jobs, so I am waiting for authorized upstream CI rather than claiming prior-head checks cover this head. The merged fork follow-up no longer needs a watch; this upstream PR remains monitored.

Inspected both new-head CI failures. The first build/typecheck error is the Stop-notice fallback calling crypto.randomUUIDv4, which is not on the Crypto type in the current CI merge; later unknown-context diagnostics cascade from that path. Four hook unit cases also fail with missing effect/crypto/SecureRandom. CI uses Effect 4.1.2, while the prior local validation used 4.0.5. The live Claude replay suite itself passes all 39 tests in CI.

I am preparing a focused current-main crypto API/test-layer compatibility correction, using lockfile-matched dependencies and current repository idioms. I will avoid changing the captured protocol behavior. These failures are not being dismissed as baseline-only.

Incorporated AppLoidx/t3code#2 and merged current main (62db6623c); head is now 3003733eee.

• c1e9a60ce: Stop-notice fallback id uses random.uuidV4() (SecureRandom), with NodeCrypto.layer in the two affected test layers. Fixes the randomUUIDv4 typecheck error and the 4 Test Server 4 failures on 7cc33d2.
• c489ee49c: hook_progress and hook_response frames are left out of native provider logs, so hook stdout/stderr never gets persisted. The adapter still gets the unmodified frame.

Local on the merged head: apps/server typecheck clean; ClaudeAdapterV2.test.ts, EventNdjsonLogger.test.ts and the Claude replay fixtures pass (354/354). Full CI needs workflow approval on this head.

The updated head decb42631d944e208e13509b1ddcce3743dad3bb now has passing hosted checks and an exact-head CodeRabbit review with no actionable findings. I stopped our duplicate conflict-integration task once your main merge arrived.

@AppLoidx The live description still describes only synthetic blocking frames. To address the review's stale-description observation while retaining all existing evidence, add this server paragraph under Change:

The Claude query enables hook events so an additionalContext-only Stop continuation is observable. A successful root Stop hook response produces the same continuation notice only when its JSON contains hookSpecificOutput.hookEventName: "Stop" and additional context; blocking or halted outputs are excluded from that path. Blocking hooks still use the synthetic-user frame, producing one notice. Output-bearing hook_progress and hook_response frames are omitted from native logs without mutating the frame consumed by the adapter. The fallback notice ID uses the current SecureRandom API.

Under Verification, distinguish the captured SDK replay and resulting-head hosted checks from the earlier screenshots and native/client runs. The 354-test local report belongs to 3003733; current hosted validation belongs to decb426. No new client run or release rollout is established by those checks. This is description maintenance, not a request for more production code.

Updated the description: the Change section now covers the hook-event path and the native-log omission, and Verification separates the 3003733 local run, the decb426 checks, and the original-head screenshots.

Integration status superseded: AppLoidx merged the owner-branch integration into this PR at ae45985a9d6f92eb245aa041a4b257c97e7b4794, including main 4f0b74e190. Verified integration ancestry, the 13-file Stop-hook scope against that main, and current mergeability. The owner reports 405 adapter/logger/replay, 95 web and 48 mobile tests plus scoped typechecks on this head; I have not independently rerun them. Hosted validation is complete on this head: 22 checks succeeded and six were skipped, with no failures or pending runs. Aggregate Check, web/package tests, all eight server shards, build/typecheck, lint and budget passed. CodeRabbit reports no actionable comments on ae45985; its review explicitly could not read the adapter blobs, so that portion relies on summaries/reported tests rather than direct source inspection. The existing privacy review thread is resolved. Formal Macroscope approval belongs to the earlier 8bcf140 head, not this head. This supersedes the earlier workflow-approval and pending-CI status. Upstream main has not merged this PR.

Thanks @ElliotDrel. Took AppLoidx/t3code#3 (keeps both includeHookEvents and promptSuggestions) and merged current main (4f0b74e190) on top; head is now ae45985a9d. Against main the diff is still only the 13 Stop-hook files.

Local on ae45985a9d: web, server, mobile and contracts typecheck clean; server adapter/logger/replay 405, web timeline 95, mobile 48 tests pass. Hosted CI pending.