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:
- Run OpenClaw 2026.5.2 with a messaging-channel auto-reply agent using
openai-codex/gpt-5.5.
- Send several normal conversational questions in one long-lived session, including turns that use tools or runtime/context events.
- After each run completes successfully, compare the run trajectory with the session transcript file.
- In the failing session,
.trajectory.jsonl contained successful trace.artifacts / model.completed data with non-empty assistantTexts for individual user prompts.
- 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.
- Send another later prompt in the same session.
- 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:
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.
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
assistantturn in the active session transcript branch. Later turns then see priorusermessages 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:
openai-codex/gpt-5.5..trajectory.jsonlcontained successfultrace.artifacts/model.completeddata with non-emptyassistantTextsfor individual user prompts..jsonlactive branch contained the user prompt and assistant tool-use/tool-result/runtime entries, but no matching visible assistant text turn for some completed runs.Expected behavior
Every successful run that yields user-visible assistant text should leave the active persisted transcript branch in a state equivalent to:
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 (
8b2a6e5observed locally)Operating system
Ubuntu 25.10, Linux x86_64
Install method
Source checkout / live service build from
openclaw/openclaw, gateway under systemd user serviceModel
openai-codex/gpt-5.5Provider / routing chain
OpenClaw messaging auto-reply -> embedded PI runner ->
openai-codexprovider / Codex ResponsesAdditional 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
Local source-level mitigation that verified the mechanism:
assistantTexts.Validation on the local mitigation:
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:
assistantTextsversion 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.