Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

A successful embedded agent run can produce visible assistant text in the run trajectory while failing to persist an equivalent visible assistant turn in the active session transcript branch. Later turns then see prior user messages as unanswered and may answer multiple previous questions again before addressing the latest prompt.

This is distinct from a pure channel-delivery problem: the reply text exists in the run artifacts and was visible to the user, but the persisted conversation state does not retain the corresponding visible assistant turn on the branch used for future context assembly.

Steps to reproduce

Observed on a channel-backed auto-reply session using the embedded PI runner and Codex Responses provider:

1. Run OpenClaw 2026.5.2 with a messaging-channel auto-reply agent using openai-codex/gpt-5.5.
2. Send several normal conversational questions in one long-lived session, including turns that use tools or runtime/context events.
3. After each run completes successfully, compare the run trajectory with the session transcript file.
4. In the failing session, .trajectory.jsonl contained successful trace.artifacts / model.completed data with non-empty assistantTexts for individual user prompts.
5. The corresponding session .jsonl active branch contained the user prompt and assistant tool-use/tool-result/runtime entries, but no matching visible assistant text turn for some completed runs.
6. Send another later prompt in the same session.
7. The assembled context can now contain a backlog of consecutive or effectively unanswered user turns, and the assistant may reply with answers to earlier already-answered questions before or instead of the newest prompt.

Expected behavior

Every successful run that yields user-visible assistant text should leave the active persisted transcript branch in a state equivalent to:

user -> assistant-visible-reply -> user -> assistant-visible-reply

Future context assembly should not treat already answered user messages as still unanswered merely because the visible assistant reply was present only in trajectory artifacts or channel delivery state.

Actual behavior

The affected session had successful run artifacts with assistantTexts, but later transcript snapshots omitted the matching visible assistant turns on the active branch. Subsequent model prompts therefore included prior user messages without their replies, and the assistant produced omnibus/stale answers covering earlier questions again.

A separate orphan/queue merge issue can make this worse, but it is not sufficient to explain the whole symptom: even without relying on the channel transcript, the run trajectory had the assistant text and the active transcript branch did not.

OpenClaw version

OpenClaw 2026.5.2 (8b2a6e5 observed locally)

Operating system

Ubuntu 25.10, Linux x86_64

Install method

Source checkout / live service build from openclaw/openclaw, gateway under systemd user service

Model

openai-codex/gpt-5.5

Provider / routing chain

OpenClaw messaging auto-reply -> embedded PI runner -> openai-codex provider / Codex Responses

Additional provider/model setup details

Observed in a WhatsApp-backed CLO-style agent session, but the failing state is in the shared embedded runner transcript/session layer rather than WhatsApp routing. Private channel identifiers, session identifiers, exact user content, and local paths are intentionally omitted.

Logs, screenshots, and evidence

Sanitized evidence shape from the failing session:

trajectory run A:
  finalStatus: success
  trace.artifacts.data.assistantTexts: [<visible answer for user prompt A>]

session transcript active branch after run A:
  user <prompt A>
  assistant <tool_use/runtime entry>
  toolResult <tool result>
  # missing: assistant <visible answer for prompt A>

later session transcript / prompt context:
  user <prompt A>
  user <prompt B>
  user <prompt C>
  ...

later assistant output:
  <answers prompt A, prompt B, prompt C again before addressing latest prompt>

Local source-level mitigation that verified the mechanism:

• After a successful embedded run, inspect extracted visible assistantTexts.
• If there is no equivalent visible assistant message reachable after the prompt leaf on the active transcript branch, append a normal visible assistant message under the session lock.
• Add regression coverage for: no-op when already persisted, append when missing, ignore whitespace-equivalent duplicates, and no-op for missing manager/session path.

Validation on the local mitigation:

pnpm vitest run src/agents/pi-embedded-runner/run/assistant-transcript-repair.test.ts
# 1 file passed, 4 tests passed

pnpm vitest run src/agents/pi-embedded-runner/run/assistant-transcript-repair.test.ts src/agents/pi-embedded-runner/run/attempt.test.ts
# 3 files passed, 266 tests passed

Impact and severity

High for affected channel-backed agents. The user sees the agent answer old questions again, bundle multiple previous answers into a later reply, or appear to ignore the latest message. It also makes transcript/debugging state misleading because the trajectory proves a reply existed while the session branch used for future context does not.

Additional information

Related issues in the same stale-reply/transcript cluster, but not exact duplicates of this failure mode:

• #76875 reports agents prioritizing previous messages after 2026.5.2, but lacks the transcript/trajectory proof point.
• #76888 covers queued/orphaned user-message merge causing stale replies.
• #76968 covers orphaned user repair leaving the persisted transcript out of sync and has PR #76969 open.
• #76886 covers Codex app-server mirrored final replies being lost from the active branch; this report is the embedded PI runner / trajectory assistantTexts version of the same class of invariant failure.

Suggested invariant for the fix: once a run successfully generates visible assistant text, exactly one equivalent visible assistant turn should be present on the active persisted transcript branch before any later user message can be appended under that branch.