Summary

Describe the problem and fix in 2–5 bullets:

• Problem: restart-aborted main-session recovery can auto-replay a synthetic recovery turn into channel-backed sessions.
• Why it matters: channel-backed sessions have external delivery state; hidden replay can re-enter delivery/recovery paths after a restart when manual recovery is safer.
• What changed: channel-backed restart-aborted sessions are marked failed for manual recovery instead of replaying a synthetic recovery turn.
• What did NOT change (scope boundary): restart recovery for non-channel resumable main sessions remains intact; no config, cron, memory, or QMD behavior is changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related Bug: reopen can leave unresolved tail tool calls and relies on local transcript compensation #64530
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: main-session restart recovery treats channel-backed sessions like ordinary resumable local sessions and may enqueue a synthetic hidden agent turn after restart. For externally delivered sessions, that can re-enter channel/session delivery state when the safer behavior is explicit manual recovery.
• Missing detection / guardrail: coverage did not assert that channel-backed restart-aborted sessions avoid synthetic replay.
• Contributing context (if known): externally backed sessions carry channel metadata and delivery context that should not be implicitly retried as hidden local recovery turns.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/agents/main-session-restart-recovery.test.ts
• Scenario the test should lock in: Discord/channel-backed restart-aborted sessions are marked failed for manual recovery and do not enqueue synthetic recovery turns; non-channel restart recovery remains resumable.
• Why this is the smallest reliable guardrail: the behavior is decided in restart recovery before any external channel send is attempted.
• Existing test that already covers this (if any): existing restart-recovery tests cover resumable non-channel behavior; this PR adds channel-backed coverage.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Channel-backed sessions that were interrupted during restart recovery now require manual recovery instead of hidden automatic replay. Non-channel resumable recovery behavior is unchanged.

Diagram (if applicable)

Before:
[channel-backed interrupted session] -> [restart recovery] -> [synthetic hidden agent turn] -> [delivery/session path re-entered]

After:
[channel-backed interrupted session] -> [restart recovery] -> [failed/manual recovery marker]

Non-channel:
[local resumable interrupted session] -> [restart recovery] -> [existing synthetic recovery path]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local gateway / Node runtime
• Model/provider: N/A
• Integration/channel (if any): Discord-backed channel session
• Relevant config (redacted): channel-backed main session with delivery context

Steps

1. Have a channel-backed main session that is restart-aborted.
2. Restart/reopen through main-session recovery.
3. Observe whether recovery enqueues a synthetic hidden agent turn or marks the session for manual recovery.

Expected

• Channel-backed restart-aborted sessions should not auto-replay a synthetic recovery turn.
• Non-channel resumable sessions should keep existing restart recovery behavior.

Actual

• Before this PR, channel-backed sessions could follow the same synthetic recovery path as non-channel sessions.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Verification run locally:

• node scripts/run-vitest.mjs run --config test/vitest/vitest.agents-core.config.ts src/agents/main-session-restart-recovery.test.ts --maxWorkers=1 --reporter dot — 6 passed
• node scripts/run-vitest.mjs run --config test/vitest/vitest.agents-core.config.ts src/agents/session-write-lock.test.ts --maxWorkers=1 --reporter dot — 24 passed
• pnpm exec oxlint src/agents/main-session-restart-recovery.ts src/agents/main-session-restart-recovery.test.ts — 0 warnings/errors

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: channel-backed restart-aborted recovery path; non-channel resumable recovery path; nearby session write-lock tests.
• Edge cases checked: restart-aborted sessions with channel metadata; existing non-channel resumable recovery behavior.
• What you did not verify: full live Discord end-to-end restart recovery in production.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: some channel-backed interrupted sessions that previously attempted automatic recovery will now require manual recovery.
  • Mitigation: this is intentional for externally delivered sessions; non-channel resumable sessions keep automatic recovery.