Agent Session Recovery and Terminal Evidence

Short answer

Session recovery needs more than a transcript. A durable agent host must answer at least three independent questions before it offers retry or continuation:

1. Liveness: is work for this session still executing somewhere?
2. Provenance: did the apparent unfinished tail come from a real user prompt, a system-injected notification, a scheduler, a tool or another internal source?
3. Finality: is there already trustworthy terminal evidence that the operation completed, failed or was interrupted?

Treating those as one question creates dangerous failure modes. A persisted system notification can look like an unanswered user message after projection; a healthy background turn can look resumable if the host only tracks foreground prompt state; and an append-only terminal ledger can permanently preserve a wrong completion classification if recovery logic stamps a result without attributable evidence.

Qwen Code PR #12007, merged on 18 September 2026 as ff38a9c430bdfbbfa03896c806c78778ee6fc24e, is a useful current example. It fixes all three boundaries in one recovery path while leaving two provenance-related limitations explicit. The change is post-v0.24.0 current-main behavior, not part of Qwen Code v0.24.0 and not a UHP or ACP wire-protocol change.

The recovery stack

A robust recovery implementation benefits from separating these records and decisions instead of deriving everything from one projected chat history:

Surface	What it should establish	What it cannot establish by itself
Persisted transcript/history	What content was recorded and in what order	Whether the last entry represents live user intent, internal injection or settled execution
Provenance metadata	Who or what produced a record	Whether the producing turn is still active
Active-turn ownership	Whether foreground, notification, cron or other automatic work is currently executing	Whether old persisted work settled correctly
Recovery classifier	Whether persisted evidence looks clean, interrupted or resumable	A terminal fact unless its inputs preserve the required provenance/finality evidence
Terminal ledger/snapshot	Durable settled outcome for an execution identifier	Whether a still-live turn may safely be superseded
Admission policy	Whether retry/continue may start now	Historical truth about what happened before admission

The key design rule is do not collapse history, provenance, liveness and finality into one heuristic.

Qwen’s failure case: a system notification looked like an orphaned prompt

Qwen records a background notification before its automatic turn runs. That is useful for durability, but it creates a subtle recovery shape when the notification is persisted and the automatic turn never answers it: the history ends in a user-role entry that has no model response.

In the affected projection, the source record’s subtype: 'notification' and provenance: 'system' were not preserved in the Content representation consumed by recovery. The tail could therefore resemble a real unanswered user prompt and be classified as interrupted_prompt with canContinue: true.

PR #12007 makes the classifier ignore the narrow trailing shape used by cold system-injected <task-notification> entries before it classifies the underlying turn. The fix is intentionally conservative: it does not turn every user-role notification-looking string into system provenance, and the upstream review records cases where a genuine interrupted prompt must still remain recoverable.

This exposes a general architectural requirement: a lossy projection should not silently become the authority for provenance-sensitive recovery decisions. If a host projects rich records into a simpler message type, it should either carry the provenance alongside that projection or explicitly bound the heuristics used when provenance is absent.

“Continue” is an execution admission decision

The second Qwen bug was not only a misleading banner. Notification and cron turns use their own streaming loops and do not necessarily install the ordinary foreground pendingPrompt state. Checking only that foreground marker could therefore say canContinue: true while automatic work was still running.

That matters because accepting a continuation enters the normal prompt-admission path. In Qwen, normal user input has priority and aborts the notification/cron controllers. A false recovery offer could therefore terminate healthy automatic work.

PR #12007 changes Session.getRecoveryStatus() to gate continuation on the broader active-turn predicate rather than pendingPrompt alone.

The reusable invariant is:

A recovery UI must not offer an action that admission would use to supersede work the recovery classifier failed to notice.

In systems with multiple execution classes, “is a prompt pending?” is weaker than “does this session currently have an authoritative turn owner?” Background notifications, scheduled jobs, goal continuations, settling prompts and history mutations may all need to participate in that ownership test.

Terminal evidence must fail closed

Qwen’s daemon keeps an append-only prompt terminal ledger. Recovery reconciliation uses persisted history to decide whether an unresolved prompt should receive a terminal entry such as completed or interrupted.

That makes false positives especially costly: once an append-only ledger records a wrong terminal, later loads can treat the incorrect classification as durable evidence.

PR #12007 therefore aligns the ledger with the same classifiable tail used by recovery, excludes system-provenance records from evidence attribution, and prevents a completed stamp when the remaining visible write is user-role without the required attributable completion evidence.

A useful general rule is:

When recovery cannot prove completion, prefer unknown/interrupted evidence over fabricating completion.

That does not mean every ambiguous session should be retried automatically. A fail-closed terminal classifier and a conservative admission policy are separate controls: the first avoids inventing history; the second decides whether another execution may safely begin.

All recovery consumers must use the same evidence boundary

A recovery classifier is rarely consumed by one UI. Qwen’s PR documents affected paths beyond the Web Shell banner, including non-interactive continuation, --continue-interrupted, TUI /resume and OpenTUI session switching.

That breadth matters. Fixing only the visual banner would leave machine-driven or headless paths capable of acting on stale recovery state. In the pre-fix path described upstream, some continuation surfaces could re-submit a persisted <task-notification>...</task-notification> envelope as retry input even though it was not a real user prompt.

The general consistency requirement is:

• normalize the classifiable history tail once;
• reuse that boundary for interruption detection and terminal reconciliation;
• gate every continuation/retry surface on the same active-turn ownership rule;
• preserve the distinction between “show a notice,” “offer continuation” and “automatically execute.”

Recovery semantics are part of the control plane, not merely presentation state.

Verification boundary and known limitations

The Qwen PR reports integration-level verification through the same history projection and recovery layers used by the application. Its recorded post-fix suites include 561 relevant core tests, 1,019 tests in the CLI Session.test.ts file and 38 prompt-terminal-ledger tests. The PR is explicit that no live qwen serve + browser reproduction was performed for the Web Shell banner, so those numbers are implementation/integration evidence rather than full end-user runtime certification.

Two provenance-related gaps remain documented upstream and tracked in Qwen issue #12042:

1. a failed live notification turn with no distinguishing reminder part can still be shape-identical to a cold persisted notification and can therefore be classified as clean; and
2. a genuine user prompt whose entire text is exactly the notification-envelope shape can still be treated as clean by the recovery banner path even though the terminal ledger now fails closed.

Both limitations point to the same deeper fix: preserve authoritative record provenance through the history projection, or provide another durable discriminator, rather than relying indefinitely on content shape.

This is why recovery documentation should state not only what a heuristic fixes but which ambiguous shapes remain unresolved.

Relation to process-death workflow recovery

Loop engineering documents a related but different Qwen pattern from PR #12159: checkpoint ownership, durable journal evidence and settled workflow history after process death. That design answers “who owned this unfinished workflow and how do we truthfully convert abandoned intent into history?”

The recovery boundary here answers a lower-level question: “given persisted session content and possibly live automatic work, what does the tail mean, and is another turn allowed to start?”

The two patterns compose:

Durable workflow/session state
        │
        ├── ownership/liveness proof
        ├── author/source provenance
        ├── interruption classifier
        └── terminal evidence
                 │
                 ▼
        retry / continue / refuse / report

Persistence without ownership can double-run work. Ownership without provenance can misclassify internal records as user intent. Provenance without terminal evidence can lose or fabricate outcomes.

Relation to UHP and ACP

This page describes harness/host recovery architecture. It does not add a UHP task state or an ACP session method.

• UHP standardizes the external product/server/harness execution boundary. A UHP implementation may sit in front of a harness with sophisticated internal recovery, but UHP conformance does not certify the harness’s private recovery classifier or notification provenance model.
• ACP standardizes client↔agent session interaction. Qwen exposes recovery through its own host and ACP-related integration paths, but PR #12007 does not revise the ACP v1 schema or make a new ACP v2 semantic rule.
• Harness internals still own how background notifications, cron turns, transcript projections, terminal ledgers and retry admission are represented unless an external protocol explicitly standardizes them.

See UHP vs ACP, Lifecycle, Qwen Code and Loop engineering for the surrounding boundaries.

Practical review checklist

When evaluating an agent host’s session-recovery design, verify:

1. Does provenance survive persistence and projection? User, system, scheduler and tool records should not become indistinguishable accidentally.
2. What counts as an active turn? Include automatic/background execution, not only an RPC prompt handle.
3. Who owns continuation admission? A UI hint should not bypass the same liveness checks used by the execution path.
4. Is terminal evidence durable and attributable? Do not stamp completion from message shape alone.
5. Do all consumers share one classifier? Web, TUI, headless and API paths should not disagree about the same session tail.
6. Can retry replay state-changing work? Recovery should not silently duplicate an operation because presentation state was wrong.
7. What ambiguity remains? Document cases where provenance was lost and the system still relies on heuristics.
8. What was actually tested? Separate unit/integration evidence from live daemon/browser/runtime validation.
9. Is the behavior version-bounded? Distinguish stable release behavior from post-release current-main changes.
10. Is a host feature being mistaken for a protocol rule? Keep UHP/ACP semantics separate from implementation recovery policy.

Primary sources

• Qwen Code PR #12007 — session recovery and notification classification
• Qwen merge commit ff38a9c4
• Qwen issue #12042 — remaining recovery/provenance gaps
• Qwen Code v0.24.0