Bug type

Behavior bug (incorrect output/state without crash)

Summary

In Control UI Webchat, a single assistant turn is often rendered/stored as two assistant messages (normal model reply + openclaw/delivery-mirror).

Steps to reproduce

1. Run OpenClaw 2026.3.2 on macOS.
2. Onboard/openai-codex OAuth and use main session in Control UI Webchat.
3. Send a normal user message.
4. Observe assistant output in chat history.
5. Check session JSONL.

Observed: one normal assistant message is followed by another assistant message with provider=openclaw, model=delivery-mirror (usage=0), often duplicating text or showing a Reasoning block.

Expected behavior

Exactly one assistant message should be produced and shown per user turn in Webchat.

Actual behavior

Two assistant messages appear for one turn in Webchat. Transcript shows a second assistant entry from openclaw/delivery-mirror immediately after the real model reply.

OpenClaw version

2026.3.2

Operating system

macOS (Darwin 25.3.0, arm64)

Install method

npm global (Gateway LaunchAgent)

Logs, screenshots, and evidence

Evidence from local session JSONL:
- assistant message (provider=openai-codex, model=gpt-5.3-codex)
- immediate assistant message (provider=openclaw, model=delivery-mirror, usage.totalTokens=0)

Also observed in UI as duplicate output. This was repeatedly observed during the same session around 2026-03-04 00:20-01:15 JST.

Impact and severity

Affected: Control UI Webchat users
Severity: Medium-High (confusing UX + transcript pollution)
Frequency: Frequent/intermittent (was repeating for many turns in one session)
Consequence: duplicate visible replies, larger context, potential extra downstream cost/confusion

Additional information

Context:

• Became noticeable after Codex OAuth onboarding timing (not claiming OAuth itself is the root cause).
• Related historical issues include Control UI webchat: duplicate assistant messages rendered on every reply #5964 and delivery-mirror/followup queue duplicate threads.
• Temporary workaround observed: behavior sometimes improves after reconnect/restart, but no reliable permanent config-only fix found.