Best possible solution:

Update the scheduler so coalesced restarts can update effective timeout state, keep the automatic-delivery override, share one explicit timeout constant, add focused coalescing coverage, and add the required changelog entry.

Do we have a high-confidence way to reproduce the issue?

Yes. The source-level reproduction is to set gateway.reload.deferralTimeoutMs to 0, schedule a no-timeout restart that waits on a nonzero pre-restart pending count, then coalesce an explicit restart with deferralTimeoutMs and observe that the old pending/preparing wait still controls emission.

Is this the best way to solve the issue?

No as submitted. The automatic source-delivery override is the right narrow fix, but the timeout policy must live in pending/preparing restart state rather than only in the first scheduled call's captured opts.

Full review comments:

• [P1] Propagate deferral timeouts through coalesced restarts — src/infra/restart.ts:739-746
  The new timeout is read from the opts captured by the first scheduled restart. If a later explicit restart with deferralTimeoutMs coalesces onto an already-pending or preparing restart that had no timeout, the pending timer or active deferral poll can still wait indefinitely when runtime config disables the timeout.
  Confidence: 0.91
• [P3] Share the explicit restart timeout constant — src/agents/tools/gateway-tool.ts:24-25
  The branch defines the same 30_000 timeout in both explicit restart call paths. Export one named constant from the restart module and import it in the gateway tool and chat command paths so the two guarantees cannot drift.
  Confidence: 0.82
• [P3] Add the required changelog entry — CHANGELOG.md:33-35
  This is a user-facing fix for restart continuation delivery and explicit restart behavior, but the branch does not update CHANGELOG.md. Add a single-line entry under the active Fixes section with appropriate contributor credit.
  Confidence: 0.84

Overall correctness: patch is incorrect
Overall confidence: 0.91

Acceptance criteria:

• pnpm exec oxfmt --check --threads=1 src/infra/restart.ts src/infra/infra-runtime.test.ts src/agents/tools/gateway-tool.ts src/agents/tools/gateway-tool.test.ts src/auto-reply/reply/commands-session.ts src/auto-reply/reply/commands-session-restart.test.ts src/gateway/server-restart-sentinel.ts src/gateway/server-restart-sentinel.test.ts CHANGELOG.md
• pnpm test src/infra/infra-runtime.test.ts src/agents/tools/gateway-tool.test.ts src/auto-reply/reply/commands-session-restart.test.ts src/gateway/server-restart-sentinel.test.ts
• pnpm check:changed in Testbox before handoff if runtime/test files remain changed

What I checked:

• Current main lacks restart-continuation delivery override: The restart-continuation dispatch call does not pass replyOptions.sourceReplyDeliveryMode, so continuation turns inherit the normal source-reply policy. (src/gateway/server-restart-sentinel.ts:265, 3980eaa1c22e)
• Group and channel replies default to message-tool-only: resolveSourceReplyDeliveryMode defaults group/channel chat types to message_tool_only unless an explicit requested mode or config selects automatic delivery. (src/auto-reply/reply/source-reply-delivery-mode.ts:28, 3980eaa1c22e)
• Current main uses only config-level restart deferral timeout: scheduleGatewaySigusr1Restart has no per-request deferralTimeoutMs option and passes cfg.gateway.reload.deferralTimeoutMs into deferGatewayRestartUntilIdle when the scheduled timer fires. (src/infra/restart.ts:777, 3980eaa1c22e)
• PR timeout state is not propagated on coalescing: The provided PR diff adds deferralTimeoutMs and reads it from the scheduled call's opts, while the existing coalesced branch still only updates emit hooks; a later explicit restart can therefore leave the old timeout state in force. (src/infra/restart.ts:739, ba9a6ec64c8c)
• Duplicate explicit restart timeout constants: The PR defines EXPLICIT_RESTART_DEFERRAL_TIMEOUT_MS separately in the gateway tool path and the chat /restart path, which can drift across the two explicit restart surfaces. (src/agents/tools/gateway-tool.ts:24, ba9a6ec64c8c)
• No active changelog entry for this user-facing fix: The active 2026.5.2 Fixes section exists, but this PR does not add an entry for restart continuation visibility or explicit restart timeout behavior. (CHANGELOG.md:33, 3980eaa1c22e)

Likely related people:

• fuller-stack-dev: Authored the merged fix(gateway): durably hand off restart continuations #70780 durable restart-continuation handoff work that current restart-sentinel continuation behavior builds on. (role: introduced adjacent behavior; confidence: medium; commits: f7550b13366e; files: src/gateway/server-restart-sentinel.ts, src/infra/session-delivery-queue.storage.test.ts, src/infra/session-delivery-queue.recovery.test.ts)
• steipete: The current local main history/blame points the central restart and gateway continuation files at commit 051171b while preserving the current implementation shape under review. (role: recent maintainer; confidence: low; commits: 051171ba8f2d; files: src/infra/restart.ts, src/gateway/server-restart-sentinel.ts, src/agents/tools/gateway-tool.ts)

Remaining risk / open question:

• Related [Bug]: gateway restart continuationMessage is silently dropped when restart coalesces with an in-flight restart #74424 remains open for continuation loss when an already-in-flight restart skips the explicit restart caller's emit hooks; this PR should not be treated as closing that broader path unless it is intentionally covered.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 3980eaa1c22e.

1. src/infra/restart.ts, line 694-711 (link)

   deferralTimeoutMs silently dropped in coalesced path

   When an explicit restart (with deferralTimeoutMs: 30_000) is coalesced into an already-pending restart that was scheduled without a deferral timeout (e.g. an automatic background reload), the else branch updates emitHooks via updatePendingRestartEmitHooks but never updates the timeout. The pending setTimeout closure still references the original opts with no deferralTimeoutMs, so maxWaitMs resolves to undefined and the deferral poll runs indefinitely — the same bug this PR is fixing.

   To close the gap, consider storing deferralTimeoutMs as module-level state (alongside pendingRestartEmitHooks) and reading it from that state inside the setTimeout callback, rather than from a captured closure, so a coalesced call can override it.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/infra/restart.ts
   Line: 694-711
   
   Comment:
   **`deferralTimeoutMs` silently dropped in coalesced path**
   
   When an explicit restart (with `deferralTimeoutMs: 30_000`) is coalesced into an already-pending restart that was scheduled *without* a deferral timeout (e.g. an automatic background reload), the `else` branch updates `emitHooks` via `updatePendingRestartEmitHooks` but never updates the timeout. The pending `setTimeout` closure still references the original `opts` with no `deferralTimeoutMs`, so `maxWaitMs` resolves to `undefined` and the deferral poll runs indefinitely — the same bug this PR is fixing.
   
   To close the gap, consider storing `deferralTimeoutMs` as module-level state (alongside `pendingRestartEmitHooks`) and reading it from that state inside the `setTimeout` callback, rather than from a captured closure, so a coalesced call can override it.
   
   How can I resolve this? If you propose a fix, please make it concise.