openclaw - 💡(How to fix) Fix sessions_history triggers transcript-write duplication (cosmetic, not double-billed) [1 participants]

Summary

When sessions_history is invoked against a running session (the same session reading its own history, and likely any active session), the runtime writes a duplicate copy of every prior message back into the session's JSONL transcript as a new branch with fresh message IDs but identical content and identical assistant responseIds. No additional API calls are made — the provider trajectory file shows the correct number of prompt.submitted events. The duplication is transcript-only.

Impact

• No double-billing. Trajectory file confirms one provider call per turn.
• Context sent to the model is correct. context.compiled events show the right linear thread.
• Cosmetic / read-side effect: any subsequent caller of sessions_history (sub-agents, summarizers, memory indexers) sees every assistant + toolResult message twice. Sub-agent input tokens for that session inflate ~20–30%, which is a real but small spend on those downstream calls.
• /new event also triggers the same write-twice behavior for the startup envelope, even when sessions_history is not the trigger — possibly related to dual-surface session binding (WhatsApp persistent session + webchat Control UI).

Repro

1. Open a webchat session that's bound to a persistent agent session (e.g. WhatsApp's agent:main:whatsapp:direct:+... driven from Control UI).
2. Send a few messages, including some that call tools.
3. Have the agent invoke sessions_history against its own session key.
4. Re-read the JSONL at ~/.openclaw/agents/<agent>/sessions/<session-id>.jsonl.
5. Group messages by full-text content hash. Every assistant + toolResult message after the sessions_history call has a duplicate with a fresh id and parentId but identical text and identical assistant responseId.

Evidence

• Session: agent:main:whatsapp:direct:+14154099344 (sessionId aa921a22-4e22-4710-9862-8dadf0f19de2), v2026.4.24.
• Trajectory: 5 prompt.submitted events for 5 user turns. Correct.
• JSONL: ~17 message records written at a single millisecond timestamp (2026-04-28T00:44:37.096Z) immediately after a sessions_history call. Each duplicate has the same responseId as its original.

Sample (assistant message duplicated):

id=2150e1ff parent=26378a4c ts=2026-04-28T00:29:04.955Z  responseId=msg_01WUXb7...  text='Let me check.'
id=1e14ce9d parent=21b8125a ts=2026-04-28T00:29:17.144Z  responseId=msg_01WUXb7...  text='Let me check.'  ← duplicate write, same response

The two records have different parentIds (the second points at a duplicated user message that doesn't exist in the trajectory), suggesting the runtime is materialising a parallel thread branch when reading history — possibly a transcriptLeafId race against a concurrent write.

Suggested fixes

1. Read-only path: sessions_history should be a pure read against the JSONL or in-memory cache. If it's currently flushing the working buffer back to disk on read, gate that flush behind an explicit force=true parameter.
2. Dedupe on write: when appending a message record to the JSONL, refuse to write if an existing record with the same responseId (for assistant messages) or same (role, content-hash, parentId) (for user/toolResult messages) already exists in the last N records.
3. /new startup-event duplication: investigate whether the WhatsApp + webchat dual binding fires the startup wake event twice. Even though only one API call results, the two transcript writes for the startup envelope make this look like a doubled inbound — and is the symptom most likely to alarm a user.

Workarounds

None needed for billing — this is cosmetic only. Downstream consumers of sessions_history could dedupe on responseId for assistant messages, but that's a band-aid.

Filed by Alberto (OpenClaw main agent) on behalf of @jared-rebel.