Human approvals that arrive after a restart: what a deployment cannot do today

[itsklimov]

What we are building

We run DeepSeek Harness server-side: one long-lived runtime process per tenant, many human users behind it. The agent does business work, and that work regularly needs a decision from a person who is not the person in the thread: a budget owner, a data owner, a manager. Those decisions come back in hours or days, and the process restarts on every deploy in between.

This is not the sandbox-escalation case. That one is correctly synchronous and should stay that way. This is about a business decision whose answer is slow by nature.

Everything below was checked against 0.1.5-rc.2 (latest).

What we need

Two properties. The first is the one we are actually asking about.

P1. A resumed transcript should tell the truth about a gated action.

A tool call that was waiting for a human decision did not perform its action. If a resumed session cannot distinguish "was gated, never ran" from "ran, outcome not recorded", then a model reading its own history cannot tell whether a payment was sent or an email went out. That ambiguity is the opposite of what the gate exists to produce.

P1 alone unblocks us. With a truthful transcript we can deliver the late decision ourselves: resume the session, state that the decision arrived, and let the agent proceed.

P2. A deployment should be able to deliver a decision after the asking process is gone.

Ideally without the agent having to re-derive the step. We are not requesting this one. We can see that it implies continuing an interrupted turn, and that is explicitly out of scope today (quoted below). We mention it only so the shape of the need is visible.

What we found

Both human-interaction seams are bounded by the turn, and the turn is bounded by the process.

ctx.userQuestions (@deepseek-ai/dsh-user-questions 0.1.5-rc.2) exposes ask(request): Promise<AskUserQuestionAnswer>, described as the service used "when it needs to pause work and ask the human for a decision".

ask_user_question (@deepseek-ai/dsh-tool-ask-user 0.1.5-rc.2), Known Limitations:

A pending question blocks the tool call until the human answers — the tool declares no timeout-policy budget; cancellation rides the turn's exec.signal only.

approval/request (@deepseek-ai/dsh-user-approval 0.1.5-rc.2) is a waterfall returning Promise<ApprovalOutcome>, Known Limitations:

Requests are valid only inside an open turn — an idle or between-turn caller throws before auditing; a durable out-of-turn approval workflow is deferred.

While a request is pending, this is what exists and where:

Piece	Where it lives	Survives a restart
approval/asked	session log	yes
the unresolved Promise<ApprovalOutcome>	process memory	no
the AbortSignal bounding it	process memory	no
the answerer closure that will settle it	process memory	no
approval/decided	session log, written only at settle	never written

Nothing bounds the wait: @deepseek-ai/dsh-agent-loop 0.1.5-rc.2 lists "No built-in turn budget". ctx.jobs is not an escape either, @deepseek-ai/dsh-jobs 0.1.5-alpha.1:

The contract is in-process — JobStart.run() passes callbacks and exact Agent objects; a durable or cross-process backend must reshape identity, restart, ownership, and observation semantics before it can implement this seam.

And the durable half we would build on is deliberately limited, @deepseek-ai/dsh-session-persistence 0.1.5-rc.2:

Synthetic closers are the only crash story — resume appends interruptedTurnClosers through the write handle; there is no partial-turn resume that continues an interrupted turn instead of closing it.

We read that as a real boundary, which is why P2 is not a request.

What we can do ourselves

We want to be clear about which half is ours, because most of it is.

Routing a question to the right approver, holding it durably, rendering it, surviving a browser reload, and letting a different person answer are all ours. We compose our own terminal answerer and our own surface, and we have to: the shipped Web answerer follows the session's live client scope (dsh-user-approval: "agent-scoped listeners receive only that agent"; dsh-user-questions: "Remote Events route the shipped Web answerer only when the request carries a live Agent scope"), and a delegated approver is not in that scope.

What we have today is an answerer that refuses to wait: it records the request in PostgreSQL with an assignee, returns a terminal outcome immediately, and lets the turn close. A worker resumes the session once a human answers. This works, and we are not blocked. What it costs is that the recorded outcome is not the real one, and the resumed agent has to be told out of band what actually happened, which pollutes the transcript it later reasons over.

What we could not determine

@deepseek-ai/dsh-session/repair exports two recovery codes:

• TOOL_NOT_STARTED, "an assistant tool request that never reached a recorded call start"
• TOOL_OUTCOME_UNKNOWN, "a recorded tool call whose completed outcome was not durably recorded"

@deepseek-ai/dsh-session-checkpoint-policy 0.1.5-rc.2 says "A top-level tool call is flushed before the tool body runs", and dsh-user-approval decides "before a sensitive tool action proceeds". From the published types we could not tell where the gate sits relative to the recorded call start, and therefore which code a gated call receives after a crash.

If a gated call already receives TOOL_NOT_STARTED, then P1 is satisfied today and we would simply like to know that, and how a deployment is meant to read it. If it receives TOOL_OUTCOME_UNKNOWN, then a provably unexecuted action is reported as possibly executed, and that is the gap we are asking about.

Shapes we considered, and are not requesting

Recording these only to show what we weighed, not to prescribe. Each has an objection we can see ourselves.

• A distinct recovery code for a gated call. Smallest thing that would satisfy P1, but it assumes the gate's position in the pipeline, which we could not verify.
• A new terminal ApprovalOutcome meaning "answered later". Rejected on compatibility: ApprovalOutcome is consumed by the tools pipeline and by every composed answerer, and widening it would silently reclassify a new value as a denial in existing plugins.
• A settle-from-another-process API on the approval service. Rejected on layering: it would make the approval service drive the agent lifecycle.
• A harness-owned store of pending requests. Rejected as scope: the harness has no database, and the deployment's answerer already owns this state.
• A deadline that expires an unanswered request. Does not help, we need the answer to eventually land rather than expire, though it is a reasonable separate feature and is raised in Deterministic approval backend ownership before the approval/request waterfall #5236.

We would rather build against whatever shape you consider right than around it.

This is not only our problem

From dsh-plugin-catalog 2026.917.3416 (3727 plugins, snapshot 2026-09-16), plugins touching approvals fall into exactly two families:

• 17 replace the human with rules or a reviewer model (dsh-approval-llm, dsh-auto-approve, dsh-yolo-mode, dsh-approve-for-me, dsh-perm-guard, ...).
• 68 in notify and remote forward the card to Telegram, Feishu, WeChat, Slack, Discord or a phone app so the human answers faster (dsh-im-gateway, dsh-reach, dsh-lark-bridge, ...).
• 0 let a pending request survive a restart.

Both families work around the same limit from opposite sides: the human must answer now, so either remove them or hurry them. Nobody solved it, which suggests it is not solvable from a plugin.

Related and distinct: #5236 asks which answerer owns a request, not how long one may live, and raises the deadline question. #4708 carries a request across a process boundary to an embedding host, but the host long-polls and "the answer releases the tool call, an approved exit_plan_mode continues the same turn", so it remains one live turn in one live process. #5147 reports an agent stuck when the policy changes while an escalation is pending, which is the same in-memory pending state seen from another side.

Questions

• Which recovery code does a call gated on approval receive today? That single answer decides whether P1 is already satisfied.
• If it is not satisfied, is making a resumed transcript distinguish a gated call from an unknown one something you would want in the harness, or something a deployment is expected to reconstruct itself?
• Is "a durable out-of-turn approval workflow is deferred" scoped internally anywhere? If a direction exists, we would rather wait for it than build a shape you would not keep.

Happy to prototype whichever shape you prefer, or to run and report a reproduction if that would help answer the first question.

[gomission]

I traced the dsh-v0.1.5-rc.2 source for your first question. For the standard tools/pre-execute → ask path, recovery does not have an approval-specific branch:

• The loop appends tool/call before calling prepare.
• Preparation awaits the approval gate before dispatch.
• Recovery uses the presence of the recorded call, then selects the error code from that fact alone. approval/asked and approval/decided do not affect that classifier.

The persistence qualification matters: appending is not the same as flushing. The standard top-level tool checkpoint is in tools/execute, after this pre-execute approval wait. If the pending call reaches the durable prefix through another flush while waiting, repair yields TOOL_OUTCOME_UNKNOWN; if the prefix contains only the assistant request, it yields TOOL_NOT_STARTED. So being gated does not itself guarantee the latter. This is a source trace, not a reproduction of your deployment.

A focused P1 test would hold that approval unresolved, explicitly flush the session, kill the process, then assert both the recovered code and a provider invocation count of zero. It would isolate the transcript gap without adding cross-process continuation.

I'm contributing from Mission, where we're testing similar restart boundaries. Your distinction between truthful history and continuing the old turn is useful here; the source trace above is only addressing P1.

[spacexm406-web]

Improve daily

[spacexm406-web]

My team 🔝💯

[send21io]

For the budget-owner case, one approach is to keep the approval out of the runtime entirely. The agent writes a durable request with its own id: amount, payee, reason. The owner approves it in their own tool or wallet, hours later. A signed webhook resumes the right task after any number of restarts, because the state lives in the request, not the process. I'm with send21, which does this for payments: the agent's key can only create the request, and a person signs it. Does the harness let a webhook rehydrate a paused tool call?

send21

[gomission]

@send21io Thanks for sharing the example. I checked the current source at a34ecdad8b775fc819e64e57e45b05d83b8d157d, which now includes V2 signing of the timestamp, delivery ID and raw body, alongside the optional legacy fallback.

Eight local characterization checks passed on Node v22.23.2/macOS arm64 using the unchanged modules and synthetic signatures. V2 rejects changed body bytes or delivery identity, accepts the exact 300-second boundary and rejects 301 seconds, and an invalid V2 header does not fall back to a valid legacy signature. Legacy-only verification remains enabled by default and can be disabled explicitly.

The restart boundary matches your documented limitation: the default store remembers an ID within one process, but two fresh processes each see that same still-valid V2 delivery as unseen. This was direct module execution with a fixed test clock, not an HTTP server or payment-service test. It does not demonstrate a second payment or even a bookkeeping write.

For the recovery comparison, the next useful case would be a synthetic bookkeeping update committed before its acknowledgement is lost, followed by restart and redelivery within the signature window. The observation should be one durable update, not merely one signature acceptance. Persisting a delivery ID and updating the application record also need a defined atomicity/recovery boundary; separate writes can leave a crash window.

Your separation between a notification and a wallet-authorized payment is useful. We are keeping that distinction in Mission's recovery research. No live endpoint, credentials, wallet, payment, persistent adapter or external effect was exercised. AI-assisted independent check; no upstream source changes.

[send21io]

Thanks for running these, and for being precise about what was and wasn't exercised. The 300/301-second boundary and "invalid V2 doesn't fall back to legacy" are exactly the cases we wanted someone outside to check.

You're right about the restart gap. send21 itself dedupes on its side (one pay link is one payment, and retries reuse the same delivery id), but the receiver still needs its own check. The in-memory store is a single-process default; a real deployment should persist the delivery id in the same transaction as the bookkeeping update (insert-if-absent on X-Send21-Delivery, then apply the update, then commit), so a crash before the ack just leads to a redelivery that is a no-op. We'll add that pattern to the example as a durable-store variant, since "one durable update" is the right thing to measure.

If you want to take the next step past synthetic signatures: the hosted service is live, so you could run the same checks against real deliveries. Create a pay link to a wallet you control, pay a small amount, and watch draft.seen / draft.confirmed arrive (with txId), including retries with the same delivery id. The testnet demo at https://send21.io/demo works too if you'd rather not touch mainnet. Happy to help if anything in the docs is unclear: info@send21.io.

[send21io]

Follow-up: the durable-store variant is up at https://github.com/send21io/send21-examples/tree/main/examples/webhook-receiver-sqlite

It inserts the X-Send21-Delivery id (primary key) and applies the bookkeeping update in one SQLite transaction, and only returns 2xx after the commit. The tests run the receiver as a separate process and cover the case you described: commit, lost ack, kill and restart, then redelivery of the same signed V2 delivery inside the window. The result is one ledger row and the order paid once. A crash inside the transaction followed by redelivery also applies exactly once. It needs Node 22.13+ (node:sqlite, no dependencies). If you run your characterization checks against it, we'd be glad to hear what breaks.

[gomission]

@send21io — I ran the unchanged examples/webhook-receiver-sqlite/test/durable.test.js at send21io/send21-examples@b3b50fe7fc4489e1d849fccb8593f88ab04b7168 on macOS / Node 22.23.2: 7 tests passed.

The separate-process controls confirm the boundary we discussed: after commit + lost acknowledgement + kill/restart, redelivery returns duplicate with one ledger row; SIGKILL before commit leaves no delivery/order/ledger state, then redelivery applies once. The in-memory contrast still handles the delivery twice. V2 rejection and late-seen controls also pass.

Reproduce from that revision: cd examples/webhook-receiver-sqlite && node --test test/durable.test.js (Node 22.13+).

This closes my local restart-gap check for the SQLite variant. Limits: synthetic signatures, loopback HTTP and temporary databases; no hosted deliveries, payment, power-loss or external-effect test. The two-connection test is sequential, not a contention test. Your same-database transaction boundary is essential; an external callback needs its own recovery/idempotency design. AI-assisted independent execution; implementation and tests are yours.

[send21io]

@gomission Thanks for running it from a pinned revision and for spelling out the limits. Agreed on the last point: the transaction only covers writes in the same database. Anything outside it, like sending an email or calling another API, should carry its own idempotency key (the X-Send21-Delivery id or the draftId works), so a retry after a crash is a no-op on that side too.

- send21