Follow Discord
Sweep 22 Sep 2026 · 17:19Z Build v2.1.280 501 read Stable v2.1.267 Latest v2.1.280 Next v2.1.280 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.265 ·

Hook messages during session start/resume can now be deferred and released later

SessionStart hook transcript messages can now be held back and inserted into the transcript only when explicitly released

TierUnder the hoodhow much it should matter to you
Useful3my rating, 1 to 5
Signal2worth watching, 1 to 5
AreaHookswhat it touches
KindInternal Changesin v2.1.265,
Group of 3 Under the hood No documentation found

SessionStart hook transcript messages can now be held back and inserted into the transcript only when explicitly released

What

  • The main session controller gained deferHookMessages/releasePendingHookMessages methods, wired into the REPL as deferHookMessages/releaseDeferredHookMessages props, letting a pending hook set's transcript messages be held back instead of inserted immediately, until explicitly released.
  • Before running a new turn (when starting fresh rather than resuming a concurrent query), the agent now awaits any pending/deferred hook set via awaitPendingHooks(), so the turn doesn't start until hooks have resolved (the wait is skipped only if the abort signal actually fires).
  • On session resume, the mechanism for landing SessionStart-type hook messages into the transcript was reworked: instead of a single pending-promise plus a "landed" flag, there is now a _pendingHookSet object with deferHookMessages, awaitStartupHooks, releasePendingHookMessages, and abort support, tied to session id checks so stale hook results for a since-replaced session get discarded.

Why This makes hook-driven transcript messages around session start and resume more reliable: turns wait for pending hooks instead of racing them, hook messages can be staged and released at the right moment, and results from a stale, already-replaced session no longer leak into the current one.

Read from
Names in the bundledeferHookMessagesreleasePendingHookMessages

See this entry in the whole of v2.1.265 →

Feedback