Summary

• Problem: Issue [Bug]: gateway restart continuationMessage can be accepted but not queued after coalesced restart #86742 (refresh of [Bug]: gateway restart continuationMessage is silently dropped when restart coalesces with an in-flight restart #74424) reports that gateway tool action: "restart" with continuationMessage returns success (mode: "emit", coalesced: true) while the continuation is silently never persisted nor delivered after the restart, because the SIGUSR1 restart was already in flight or already scheduled. Two prior attempts (fix(gateway/restart): write sentinel with continuationMessage on coalesced restart #74443 by hclsys, Fix restart continuations after explicit restarts #73812 by VACInc) were closed without merging; the issue creator explicitly notes that aisle-research-bot flagged fix(gateway/restart): write sentinel with continuationMessage on coalesced restart #74443 as a Medium security finding ("Cross-session continuation overwrite when coalescing gateway restart requests", CWE-200) because a naive global rewrite of restart-sentinel.json could overwrite or misroute another session's continuation. The accepted resolutions the issue creator names are "queue the continuation for the correct pending restart" OR "an explicit non-queued result"; fix(gateway): report unqueued restart continuations #83370 (stainlu, currently ready for maintainer look) covers the explicit-non-queued half via continuationQueued: false reporting; the cross-session overwrite hole on the silent-overwrite Path B (updatePendingRestartEmitHooks) remains.
• Root Cause: src/infra/restart.ts exposes two coalesced-restart paths from scheduleGatewaySigusr1Restart. Path A (hasUnconsumedRestartSignal) is correctly hooks-less — SIGUSR1 already fired and the caller cannot opt in. Path B (pendingRestartTimer || pendingRestartPreparing) calls updatePendingRestartEmitHooks(opts?.emitHooks) which unconditionally overwrites the existing pending emit hooks. The emit hooks own writing the restart-sentinel.json payload (containing the caller's sessionKey, deliveryContext, threadId, continuation) — so a second session's coalesced restart silently replaces the first session's continuation and routes the post-restart continuation back to the wrong session. This is the CWE-200 hole aisle-research-bot identified on fix(gateway/restart): write sentinel with continuationMessage on coalesced restart #74443.
• Fix: Add a session-routing guard to updatePendingRestartEmitHooks so it only accepts new hooks when the new caller's sessionKey matches the pending restart's sessionKey. Threading sessionKey?: string through the scheduleGatewaySigusr1Restart opts and remembering it as pendingRestartSessionKey module state. Add emitHooksQueued: boolean to the ScheduledRestart return shape so callers can detect that their hooks were rejected (matches the field name fix(gateway): report unqueued restart continuations #83370 chose for the same purpose). Wire the gateway tool to pass agentSessionKey and surface continuationQueued: scheduled.emitHooksQueued in the tool response whenever the caller supplied a continuation.
• What changed:
  • src/infra/restart.ts — new pendingRestartSessionKey module state; scheduleGatewaySigusr1Restart opts gain sessionKey?: string; ScheduledRestart gains emitHooksQueued: boolean; updatePendingRestartEmitHooks becomes session-guarded and returns whether the slot was claimed; the Path B coalesced branch threads that result back into the response and logs a restart continuation dropped warning when the guard rejects new hooks. Path A continues to return emitHooksQueued: false because the hooks cannot run for the already-emitted cycle. clearPendingScheduledRestart, the fresh-schedule and skipDeferral paths reset pendingRestartSessionKey alongside pendingRestartEmitHooks. emitPreparedGatewayRestart keeps pendingRestartSessionKey alive across the await beforeEmit() window and only clears it after the chained-hook loop exits — without this, a coalesced different-session caller could slip past the guard during the in-flight preparation window (ClawSweeper P1 review point on initial PR head 8f9cec097c6c, addressed in latest head).
  • src/agents/tools/gateway-tool.ts — pass sessionKey to scheduleGatewaySigusr1Restart and report continuationQueued: scheduled.emitHooksQueued in the tool result when the caller supplied a continuation.
  • src/auto-reply/reply/commands-session.ts — handleRestartCommand now also threads sentinelPayload.sessionKey into scheduleGatewaySigusr1Restart (sibling cross-session guard ClawSweeper P1 review identified — the chat /restart also writes a session-scoped sentinel with continuation, and previously bypassed the new guard by omitting the scheduler sessionKey opt).
  • src/infra/infra-runtime.test.ts — three new tests pin the session-guard semantics: different sessions → second caller observes emitHooksQueued: false and its hooks are not invoked; same session → debounce/replace behavior preserved; different session coalescing during in-flight beforeEmit preparation → guard still holds (the in-flight preparation race the ClawSweeper P1 review asked for).
  • src/agents/tools/gateway-tool.test.ts — existing mock fixture upgraded to the full ScheduledRestart shape (was a partial { scheduled, delayMs }); new regression test pins continuationQueued: false propagation when the coalesced restart belongs to another session.
  • src/auto-reply/reply/commands-session-restart.test.ts — new regression test asserts handleRestartCommand passes sessionKey to the scheduler so the sibling /restart path is covered by the same cross-session guard.
• What did NOT change (scope boundary):
  • restart-sentinel.json schema (RestartSentinelPayload) is unchanged — same single-slot continuation + sessionKey shape; the fix is in the scheduler, not the sentinel.
  • Path A behavior (in-flight SIGUSR1 already emitted) is unchanged — the new caller's hooks still cannot run for the current cycle, only the explicit reporting via emitHooksQueued: false is added.
  • Legacy callers that pass no sessionKey (existing behavior) continue to chain/overwrite as before — the guard only fires when both sides identify a session.
  • #83370 (stainlu) is complementary: its continuationQueued surfacing in the tool response was the explicit-non-queued half of the issue creator's OR clause; this PR adds the queued-for-the-correct-restart half by rejecting cross-session overwrites at the scheduler level.
  • Config surface unchanged (no schema, defaults, doctor migrations, or docs/reference/config edits).
  • Plugin surface unchanged (no plugin SDK, manifest, extensions/api.ts / runtime-api.ts, registry, or loader edits).
  • Session store / sessions.json untouched (relevant given the June SQLite migration).
  • pi-embedded-runner untouched.

Reproduction

1. Configure a workflow where multiple Discord/Slack/Feishu sessions can each call gateway tool action: "restart" with continuationMessage near each other (e.g. a deploy script plus an agent-driven plugin install both restarting the gateway).
2. Session A issues gateway.restart with continuation A. The scheduler stores pendingRestartEmitHooks whose beforeEmit writes restart-sentinel.json with sessionKey: A and continuation A.
3. Before the restart timer fires, session B issues gateway.restart with continuation B.
4. Before this PR: updatePendingRestartEmitHooks(B's hooks) replaces A's hooks. The restart fires; the sentinel is written by B's beforeEmit with sessionKey: B and continuation B. After restart, the gateway dispatches continuation B as if A had asked for it (or simply drops A's continuation depending on routing) — A's promised reply is silently lost (this is the CWE-200 hole). Both tool responses look successful.
5. After this PR: the same sequence keeps A's pendingRestartEmitHooks in place; B's coalesced call returns coalesced: true, emitHooksQueued: false, continuationQueued: false so the agent that issued B knows the continuation was not queued. The gateway log records restart continuation dropped: another session owns the pending restart. A's continuation still fires after restart as promised.

Real behavior proof

Behavior addressed (#86742): cross-session coalesced restarts no longer silently overwrite the existing pending continuation. Same-session debounce/replace is preserved. Legacy callers (no sessionKey) keep the old chain behavior. The gateway.restart tool response now surfaces continuationQueued: false when the caller's continuation could not take ownership of the pending restart slot.

Real environment tested (Linux, Node 22, real-component tsx harness driving production scheduleGatewaySigusr1Restart end-to-end): tsx-resolved import of production scheduleGatewaySigusr1Restart + __testing.resetSigusr1State. A real SIGUSR1 listener is registered so the scheduler runs in emit mode. Each scenario invokes the production scheduler twice with combinations of sessionKey and inspects the returned coalesced / emitHooksQueued fields. No mocks of the scheduler itself.

Exact steps or command run after this patch:

1. node_modules/.bin/tsx /tmp/qmd86742/repro.mts (real-component session-routing-guard sweep)
2. node scripts/run-vitest.mjs src/infra/infra-runtime.test.ts src/agents/tools/gateway-tool.test.ts
3. 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

Evidence after fix (verbatim real-component harness output, ANSI stripped):

================ #86742 cross-session continuation guard ================

Drives production scheduleGatewaySigusr1Restart with two callers from
different sessionKeys and verifies the second caller's emit hooks are
rejected (rather than overwriting the first session's continuation).

--- Scenario A: session-A schedules, session-B coalesces (DIFFERENT session) ---
[restart] request coalesced (already scheduled) reason=session-B-restart pendingReason=session-A-restart delayMs=60000 actor=<unknown>
[restart] continuation dropped: another session owns the pending restart (callerSessionKey=agent:main:session-B pendingSessionKey=agent:main:session-A)
  first.coalesced=false first.emitHooksQueued=true
  second.coalesced=true second.emitHooksQueued=false
  >>> OK: session-A owns slot, session-B explicitly reported as not-queued

--- Scenario B: same session debounces (replace hooks) ---
[restart] request coalesced (already scheduled) reason=second pendingReason=first delayMs=60000 actor=<unknown>
  same1.emitHooksQueued=true same2.coalesced=true same2.emitHooksQueued=true
  >>> OK: same session can debounce/replace its own hooks

--- Scenario C: legacy callers without sessionKey still chain ---
[restart] request coalesced (already scheduled) reason=legacy-second pendingReason=legacy-first delayMs=60000 actor=<unknown>
  legacy1.emitHooksQueued=true legacy2.coalesced=true legacy2.emitHooksQueued=true
  >>> OK: legacy callers (no sessionKey) preserve current overwrite behavior

--- Scenario E: cross-session race DURING beforeEmit await (in-flight preparation) ---
[restart] request coalesced (already scheduled) reason=session-B-during-prep pendingReason=unspecified delayMs=0 actor=<unknown>
[restart] continuation dropped: another session owns the pending restart (callerSessionKey=agent:main:session-B pendingSessionKey=agent:main:session-A)
  e1.emitHooksQueued=true e2.coalesced=true e2.emitHooksQueued=false
  session-B beforeEmit ran during prep window: false
  >>> OK: in-flight preparation owner survived; session-B rejected

--- Scenario D: existing has sessionKey, new caller doesn't ---
[restart] request coalesced (already scheduled) reason=unspecified pendingReason=unspecified delayMs=60000 actor=<unknown>
  known.emitHooksQueued=true anonymous.coalesced=true anonymous.emitHooksQueued=true
  >>> OK: undefined sessionKey on new caller doesn't trigger guard (legacy compat)

================ VERDICT ================
PASS — session-routing guard works as designed:
  - Different sessions: explicit emitHooksQueued=false (no overwrite, no silent loss)
  - Same session: debounce/replace preserved
  - Legacy callers (no sessionKey): behavior unchanged
  - Mixed undefined: legacy compat (guard only fires when both sides identify session)

Vitest output for the two touched test files:

 RUN  v4.1.7

 Test Files  3 passed (3)
      Tests  45 passed (45)
   Duration  11.18s

Observed result after fix:

• The new Rejects coalesced emit hooks from a different session test confirms session A's beforeEmit runs and session B's does not, while session B observes emitHooksQueued: false synchronously.
• The new Allows same-session coalesced restart to replace its own preparation hook test confirms the existing debounce/replace semantics are intact.
• The new gateway-tool regression test confirms the tool response surfaces continuationQueued: false when the coalesced caller belongs to another session.
• Logs include restart continuation dropped: another session owns the pending restart with both session keys for operator diagnosis.

What was not tested:

• A live multi-session restart race on a real gateway (Discord + Telegram concurrent gateway.restart). The real-component harness drives the production scheduler with two sessionKeys but does not invoke a real channel gateway.restart tool call end-to-end; the gateway-tool branch is covered by mocked-scheduler unit tests instead.
• Interaction with future PRs that may rewrite the sentinel schema to natively support multi-session continuations — this PR is intentionally a scheduler-level guard that keeps the existing single-slot sentinel safe.

Regression tests:

• infra-runtime.test.ts → rejects coalesced emit hooks from a different session and reports emitHooksQueued=false (#86742) + allows same-session coalesced restart to replace its own preparation hook (#86742) + rejects coalesced emit hooks from a different session while preparation is in flight (#86742) (the in-flight beforeEmit race the ClawSweeper P1 review asked for) + the preserved keeps existing preparation hook when a hookless restart coalesces and uses the latest preparation hook when scheduled restarts coalesce tests.
• gateway-tool.test.ts → upgraded full-shape mock plus new reports continuationQueued=false when a coalesced restart belongs to another session (#86742).

Risk / Mitigation

• Risk: A second same-session restart caller might lose a meaningful continuation when same-session debounce replaces hooks. Mitigation: this preserves existing behavior (updatePendingRestartEmitHooks always replaced when caller had hooks pre-fix); the only change is rejecting cross-session overwrites. Same-session callers can choose to inspect emitHooksQueued: true to confirm their hooks installed.
• Risk: Legacy callers without sessionKey continue to chain/overwrite, leaving the CWE-200 hole open for any code path that doesn't identify a session. Mitigation: the two known cross-session callers that write a session-scoped sentinel + continuation are gateway-tool.ts action: "restart" and commands-session.ts handleRestartCommand (chat /restart); this PR updates both to always pass sessionKey. The remaining legacy callers (CLI run-loop's scheduleGatewaySigusr1Restart({ delayMs: 0, reason: "SIGUSR1" })) do not write a sentinel continuation and are restart-only callers, not affected by the overwrite hole.
• Risk: The ScheduledRestart return shape now has a new required field emitHooksQueued. Mitigation: the only production callers reading the return are gateway-tool.ts (this PR), commands-session.ts (calls but does not destructure additional fields), the CLI run-loop (calls but does not destructure additional fields), and config-write-flow.ts (uses ReturnType<typeof scheduleGatewaySigusr1Restart>, type-only). The test mock fixture in gateway-tool.test.ts was upgraded in this PR.
• Risk: Overlap with fix(gateway): report unqueued restart continuations #83370 (stainlu, ready for maintainer look). Mitigation: this PR is intentionally a follow-up, not a replacement. fix(gateway): report unqueued restart continuations #83370 surfaces continuationQueued: false in the tool response when the scheduler reports emitHooksQueued: false. This PR adds the actual scheduler-level session guard plus matching tests for the cross-session path. If fix(gateway): report unqueued restart continuations #83370 lands first, this PR rebases cleanly: the new emitHooksQueued field and the gateway-tool continuationQueued plumbing match.

Change Type (select all)

• Bug fix
• Security hardening

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution

Linked Issue/PR

Refs #86742