Intelligence
AEW-019

Partial context republication restores an obsolete mandate as active

A maintenance process that rewrites or republishes an agent's own session history changes the active leaf incrementally rather than behind one commit, so an interruption can leave a partially reconstructed historical branch active while a newer task stays physically stored but unreachable. Reported once, in one product's issue tracker, with a deterministic reproduction and an unmerged proposed fix; retained as a candidate.

Status: candidateExecution AuthoritySequence Integrity

Description

Agent runtimes maintain their own session history: compacting it, correcting it, or rewriting entries during recovery. This weakness names a specific way that housekeeping can go wrong. When a rewrite republishes replacement and unchanged entries one at a time, and each individual append durably advances the session's own active branch on its own, there is no point before which the rewrite is not yet real and after which it is. An interruption partway through leaves whatever has been republished so far as the active branch, even though it is neither the branch that was active before the rewrite began nor the branch the rewrite was meant to produce. Nothing about this requires an instruction to arrive from outside the session or from another agent; the session's own maintenance layer makes the substitution on its own. It differs from persistent state carrying an inherited objective across agents (AEW-012), where an instruction copies itself between separate agents through shared memory; here there is one session, one agent, and no instruction travels anywhere. It differs from a sequence of individually authorized actions composing into an unauthorized whole (AEW-010), which concerns the harm accruing across steps an agent chooses to take; here the harm is that a bookkeeping process, not the agent's own chosen trajectory, silently changes which task the agent is even working on. It differs from an approval failing to bind to the action that executes (AEW-005), which concerns a human or machine review step and what runs afterward; no approval is in play here at all. The authority gap is that active branch selection, which task an agent's context makes it believe it is pursuing, is treated as a byproduct of reliability engineering rather than as authority bearing state in its own right, so a maintenance failure can hand a current agent an objective nobody currently authorized without granting, inheriting or approving anything.

The authority gap

The authority to continue an objective is presented by whichever branch a recovery process finds marked active. The authority actually required is confirmation that this branch is the last one that was deliberately and completely published as the session's mandate, which an interrupted, partially republished rewrite does not establish.

Failure conditions

  • A process rewrites, compacts or otherwise republishes an agent's own session or transcript history.
  • The rewrite publishes its replacement entries incrementally, with each individual append independently advancing the session's active branch, rather than behind one all or nothing commit.
  • The process is interrupted after some but not all of the replacement entries have published.
  • Recovery or restart resumes from whichever branch is currently marked active, without checking that it is the last branch that was deliberately and completely published.

Consequences shown by the evidence

  • An agent resumes and continues an obsolete, already superseded task while a newer, authorized task remains physically stored but unreachable from the active branch.
  • A session identifier stays unchanged across the substitution, so nothing about the session's own identity flags that its active task has changed.

Detection signals

  • A context or transcript rewrite publishes replacement entries through a loop of independent appends rather than one wrapped transaction.
  • Restart or recovery logic selects the current leaf or branch without comparing it against the branch that was active immediately before an interruption.
  • Records for a newer task remain present in durable storage but are not reachable by walking the active branch's own parent chain.

Known examples

  • OpenClaw issue 138965, opened and labeled P0 by a maintainer on 5 September 2026, reports that rewriteTranscriptEntriesInSessionManager branches a rewrite from the first replaced entry's parent and then republishes every following entry through independent, durable appendBranchEntry calls with no transaction or other all or nothing boundary around the loop; this record verified that mechanism directly against the affected functions on OpenClaw's current main branch. The issue's own in memory fault injection reproduction lets two appends succeed and throws before the third, leaving only the partially copied historical path active while the physically stored newer task stays unreached; a second probe repeats the result with an assistant message in the old prefix. Separately, the issue reports a read only correlation with a live incident: before an operator authorized restart the persisted record reflected a current task; over a later burst timed at roughly eleven minutes, about 258,000 records with timestamps older than their insertion times were appended; the last records committed before a stalled shutdown was forcibly ended belonged to an unrelated task roughly four weeks older; and after restart, recovery appended to that older tail, with the delivered answer continuing the old task while the session identifier stayed the same. The reporter states plainly that no JavaScript stack captured the caller driving the live replay burst, so this weakness treats the source mechanism as reproduced and the live incident as correlated evidence rather than a proven causal chain to that exact function. Two proposed fixes are open and neither has merged: PR 138984 proposes publishing a prepared rewrite behind one final transaction, with its own review recording several unresolved P1 findings at the time this record checked; PR 139004 proposes a narrower single guard fix that its own review states restores the in memory branch without addressing durable recovery after a restart. Current stable, v2026.9.1, released 3 September 2026, two days before the issue, was confirmed directly against its own release notes to carry neither change.

Recorded instances

No recorded instance yet. The weakness stands on the records below.