OpenClaw landed a P1 Browser Talk fix tonight in PR #133493, titled fix(talk): preserve provider conversation order in browser transcripts. The change addresses a failure mode in realtime voice sessions where transcripts could appear or save in the wrong order.
The root problem was timing. OpenAI could finish an assistant answer before asynchronous user transcription completed. In overlapping turns, assistant items could also merge into one visible reply. A timer-based workaround was not reliable because a longer spoken utterance can easily outlast a fixed one-second delay.
What OpenClaw Does Now
Provider item creation now reserves capacity and a flush barrier in the existing bounded serial transcript queue. Instead of relying on completion order, OpenClaw uses predecessor links and exact provider item identity to assign conversation order.
That lets the UI stream assistant deltas immediately while still placing late user text beside the correct answer once transcription settles. Failed or empty transcription, plus empty canceled answers, also settle their identities without inventing text.
The PR keeps this work inside the existing queue owner. There is no new durable format, storage schema, retention policy, Gateway protocol, configuration flag, or second buffering system.
Why This Matters
Voice mode only works if the transcript remains trustworthy. A user should be able to review a Browser Talk session and see what was said in the order it was said, even when provider callbacks arrive out of order.
This fix matters most for natural speech, where a user may ask a longer question while the assistant starts generating quickly. Without identity-aware ordering, the saved history can mis-associate a user utterance with the wrong assistant answer. That is not just visual polish; it affects recall, debugging, and future context.
Proof From The Merge
The PR reports failure-first coverage for five owner scenarios. Four additional cases reproduced lost early items during awaited SDP setup, and an empty canceled assistant item reproduced a blocked later question. All passed after the repair.
The merged evidence includes:
- 157 tests across nine owner and sibling suites.
- 11 actual Chromium Browser Talk start-stop and ordering cases.
- UI typecheck coverage.
- A committed-mode Codex autoreview through P2 with no scoped actionable findings.
- Authenticated live proof using a temporary built Gateway, actual Chromium WebRTC, and an existing OpenAI OAuth profile.
In the live proof, two offline synthetic spoken requests asked for "glacier" and "lantern." The first assistant final arrived before its user ASR final, but the visible positions, transcript RPCs, and closed chat history still preserved user/glacier, assistant/glacier, user/lantern, assistant/lantern.
The Operator Takeaway
This is a meaningful reliability improvement for anyone testing OpenClaw as a voice-first personal agent. Browser Talk can now tolerate provider event timing without scrambling the conversation record.
The broader pattern is also worth noting. OpenClaw did not patch this with a bigger delay. It repaired ownership and identity at the transcript queue boundary, which is the right layer for a bug where event arrival order and conversation order are different things.