Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
When an agent runs through the Codex app-server / CLI-style provider path, final assistant replies are delivered to chat and briefly appended to the session transcript by the Codex transcript mirror. However, the mirror appends directly to the transcript file and does not appear to update the live session manager's in-memory leaf/branch state. A later inbound user message can then be appended from the stale pre-final leaf, causing the previously mirrored final assistant reply to be omitted from the active transcript branch and, in observed captures, disappear from subsequent transcript snapshots.
The net effect is that later turns can see prior user messages without the assistant replies that were actually sent, so the assistant may treat already-answered messages as still unresolved.
Steps to reproduce
- Configure an agent/session to use the Codex app-server style provider path.
- Send a normal chat message that produces a final assistant reply.
- Inspect the transcript immediately after the reply and confirm the final assistant reply was appended by the Codex transcript mirror.
- Send another message in the same session.
- Inspect the transcript branch/parent chain and subsequent transcript snapshot.
- Compare the second message's parent against the prior final assistant reply's entry.
Expected behavior
A successful final assistant reply should become the live session leaf, or otherwise be integrated into the live session manager state, before later inbound messages are appended. Subsequent messages should parent after the final assistant reply so the active transcript branch remains ordered as user -> assistant -> user.
Actual behavior
In an observed Codex app-server chat session:
- The first final assistant reply was present in one transcript snapshot immediately after it was sent.
- The next user message was parented to the runtime-context entry before that final assistant reply, not to the final assistant reply itself.
- A later transcript snapshot no longer contained the earlier final assistant reply on the active transcript path.
- The next turn therefore saw the earlier user message as unanswered and responded to both the previous message and the newest correction.
This indicates the issue is not simply that final replies fail to persist initially. The more precise failure is that Codex app-server's mirrored transcript append can be overwritten or orphaned because the live session state remains on the stale pre-final leaf.
OpenClaw version
OpenClaw 2026.5.2
Operating system
Ubuntu 26.04 LTS
Install method
npm/global install
Model
openai-codex/gpt-5.5
Provider / routing chain
Codex app-server / CLI-style provider path
Additional provider/model setup details
Observed with a Codex app-server-backed model in a chat session. The behavior appears related to the Codex app-server transcript mirror and session-manager branch synchronization, not to Telegram-specific inbound handling.
Logs, screenshots, and evidence
Sanitized local evidence:
- Source inspection shows the Codex app-server path builds a `messagesSnapshot` containing the user prompt and final assistant reply.
- The Codex app-server runner calls a transcript mirror after the run result is built.
- The transcript mirror appends user/assistant messages directly to the session transcript file with `fs.appendFile` and emits a transcript update event afterward.
- Source inspection did not show that this mirror append updates the live session manager leaf/branch state.
- In a captured session, a transcript snapshot contained a final assistant reply immediately after it was sent.
- The next inbound user message in the same session was parented to the runtime-context entry before that final assistant reply, not to the final assistant reply.
- The next transcript snapshot omitted the earlier final assistant reply while containing the later user message and later assistant reply.
- The same pattern repeated: each final assistant reply was visible in the immediate post-run snapshot, then absent from later active transcript snapshots after a subsequent inbound message.
- No compaction entries occurred in the affected window, so this was not caused by normal compaction pruning.
- This matches the stale-leaf/session-manager synchronization hypothesis better than a simple broadcast-only or compaction-loss explanation.
- Server chat finalization separately broadcasts the buffered assistant text as a final chat payload; that broadcast path does not itself persist the assistant message, so persistence depends on the Codex mirror path being branch-safe.
Impact and severity
High for chat quality on Codex app-server sessions. Multi-message conversations can become confusing because final replies that users saw may not remain in the active persisted transcript branch. This affects next-turn context assembly, session history, compaction, and debugging.
Additional information
A likely fix is to make Codex app-server final reply persistence go through the same live session manager append path as normal assistant messages, or otherwise reload/update the live session manager leaf after the mirror append so subsequent inbound messages parent after the mirrored final assistant reply.
Existing issue #68582 appears related, but this report narrows the mechanism: the final assistant reply can be appended to disk initially, then lost/orphaned because the live session branch continues from a stale pre-final leaf.
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
When an agent runs through the Codex app-server / CLI-style provider path, final assistant replies are delivered to chat and briefly appended to the session transcript by the Codex transcript mirror. However, the mirror appends directly to the transcript file and does not appear to update the live session manager's in-memory leaf/branch state. A later inbound user message can then be appended from the stale pre-final leaf, causing the previously mirrored final assistant reply to be omitted from the active transcript branch and, in observed captures, disappear from subsequent transcript snapshots.
The net effect is that later turns can see prior user messages without the assistant replies that were actually sent, so the assistant may treat already-answered messages as still unresolved.
Steps to reproduce
Expected behavior
A successful final assistant reply should become the live session leaf, or otherwise be integrated into the live session manager state, before later inbound messages are appended. Subsequent messages should parent after the final assistant reply so the active transcript branch remains ordered as user -> assistant -> user.
Actual behavior
In an observed Codex app-server chat session:
This indicates the issue is not simply that final replies fail to persist initially. The more precise failure is that Codex app-server's mirrored transcript append can be overwritten or orphaned because the live session state remains on the stale pre-final leaf.
OpenClaw version
OpenClaw 2026.5.2
Operating system
Ubuntu 26.04 LTS
Install method
npm/global install
Model
openai-codex/gpt-5.5
Provider / routing chain
Codex app-server / CLI-style provider path
Additional provider/model setup details
Observed with a Codex app-server-backed model in a chat session. The behavior appears related to the Codex app-server transcript mirror and session-manager branch synchronization, not to Telegram-specific inbound handling.
Logs, screenshots, and evidence
Impact and severity
High for chat quality on Codex app-server sessions. Multi-message conversations can become confusing because final replies that users saw may not remain in the active persisted transcript branch. This affects next-turn context assembly, session history, compaction, and debugging.
Additional information
A likely fix is to make Codex app-server final reply persistence go through the same live session manager append path as normal assistant messages, or otherwise reload/update the live session manager leaf after the mirror append so subsequent inbound messages parent after the mirrored final assistant reply.
Existing issue #68582 appears related, but this report narrows the mechanism: the final assistant reply can be appended to disk initially, then lost/orphaned because the live session branch continues from a stale pre-final leaf.