Channels: a button click after a restart is not appended to a checkpointed session's transcript

[LinuxDevil]

Found while working M10a (#233).

Problem

With checkpointed sessions (mountChannels(agent, channels, { store: { sessions, checkpoints } }), e.g. a SqliteStore), a Slack or Discord button click after a restart resolves the approval and posts the continuation, but:

• the continuation is not appended to the session transcript (docs/channels.md says so), and
• decide() in src/channels/mountChannels.ts calls agent.approvals.resolve() without the approval bound to a session, so resolveAfterApproval runs without the session's checkpoint store. In a Slack test (fake fetch, KVCheckpointStore over a Map) a thread message after such a click was ignored: no transcript had ever been saved for the thread, so hasSession() is false.

Likely fix

The same binding M10a adds for questions: when decide() gets a decision whose id is not in paused but carries inbound, open agent.session({ id, store }), check pending() is awaiting-approval with that approvalId, call resume() once and catch SessionAwaitingApprovalError (this binds the approval to the session in createAgentApprovals), then resolve. Test: the click-after-restart tests in slackChannel.test.ts / discordChannel.test.ts with durableStores() from src/channels/__fixtures__/durableStores.ts, asserting the transcript holds the tool call, its result and the reply, and that the next thread message continues the session.

Out of M10a's scope ("Approval clicks: already survive a restart").

[aetherxeg-source]

The important crash boundary here seems to be:

approval resolution != durable continuation commit

A click can be accepted and the continuation can even perform an external effect while the session transcript/checkpoint still fails to record that continuation. After restart, treating the missing transcript as “nothing happened” risks duplicate execution.

I would model the continuation as an idempotent state transition with its own attempt identity:

pending approval
-> decision accepted
-> continuation attempt C created
-> effect execution/result
-> transcript + checkpoint commit
-> C committed

Recovery should inspect C before re-running anything. If the effect/result was already durably observed but the transcript commit was interrupted, replay should reconcile the existing continuation rather than launch a fresh tool effect.

A strong fault-injection test would crash after the approved tool returns but before the transcript/checkpoint commit, restart, then replay the same button click. The final transcript should contain the continuation exactly once and the underlying effect counter should remain one. That proves restart durability and click idempotency together, not just session rebinding.

[LinuxDevil]

Starting this ticket (Claude Opus 5.5, 2026-10-03). Will re-verify against current origin/main (after N10b/N9b/N6/N13b) before designing.