{"version":"2.1.268","anchor":"session-resume-reworked-to-compute-session-start-hooks-async","canonical_anchor":"resume-picker-now-forwards-pending-sessionstart-hook-message","heading":"Session resume now carries SessionStart hooks through, including partial-history resume","tier":"notice","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/session-resume-reworked-to-compute-session-start-hooks-async","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Session resume now carries SessionStart hooks through, including partial-history resume\n\nResuming a session now properly forwards its SessionStart hooks, and can resume from just part of the transcript\n\n**What**\n\n- Session resume\/fork no longer passes `hookMessages`\/`hooksPromise` directly to the startup path; instead it returns a `sessionStartHooks` promise wired through a new abortable \"tail\" queue. Resume also gained a `precedingRows` option, letting a caller resume from a subset of prior transcript rows instead of the full session.\n\n- When resuming a session from the picker, the session's recorded `sessionStartHooks` are captured and threaded through as `pendingHookMessages` into the resumed UI state.\n\n- Resumed sessions now propagate this `sessionStartHooks` field into `pendingHookMessages` when reconstructing state, alongside the existing `sessionHooks` field, which was previously missing from the restored-session object.\n\n**Why** This ensures `SessionStart` hooks that fired for a session are correctly carried over when that session is resumed, so hook-driven setup isn't silently lost, and it also enables resuming from a partial transcript.\n\n- Area: Sessions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}