openclaw - 💡(How to fix) Fix Every user message is processed twice: rewriteSubmittedPromptTranscript branches after agent reply, triggering duplicate run [1 comments, 2 participants]

Bug Summary

Every inbound user message is processed twice by the agent, producing two separate transcript entries and two responses. This affects all channels (webchat, Feishu/Lark, etc.).

The root cause is rewriteSubmittedPromptTranscript in selection-C3otDzGD.js — it creates a new transcript branch after the agent has already replied, and the new branch triggers a second agent run.

Environment

• OpenClaw: 2026.4.24 (cbcfdf6)
• OS: Linux 6.17.0-20-generic (x64)
• Node: v25.8.2
• Channel: all (confirmed webchat + Feishu/Lark)

Reproduction

1. Start any conversation via webchat or Feishu
2. Send a message
3. Observe the agent responds twice

Evidence: Transcript Analysis

Sent one webchat message: 如果你看到我说了两句一样的话你就回复 1

The session transcript (JSONL) shows two user entries with the same parentId, plus two assistant responses:

7786ae32 (assistant: greeting)
  ├── 06981791 (user: WITH Sender metadata)     [16:48:05.620]
  │   └── 68cd74aa (assistant: "1")              [16:48:09.435]  ← 1st run reply
  └── db88661b (user: WITHOUT Sender metadata)   [16:48:09.475]  ← rewrite branch
      └── 14704559 (assistant: "1")              [16:48:09.475]  ← 2nd run reply (DUPLICATE)

Both user entries share parentId: 7786ae32 but have different IDs. The first contains the full envelope with Sender metadata:

Sender (untrusted metadata):
{"label": "openclaw-control-ui", "id": "openclaw-control-ui"}

[Mon 2026-04-27 00:48 GMT+8] 如果你可以看到...

The second contains only the bare message:

[Mon 2026-04-27 00:48 GMT+8] 如果你可以看到...

The agent replied "1" to both, confirming it processed the message twice.

This happens for every message. The same pattern repeats for Feishu messages (Sender = ou_xxx vs bare message).

Root Cause

The Flow

1. getReplyFromConfig in get-reply-CSQ5BMwG.js builds two versions of the user message:

   • effectiveBaseBody = inboundUserContext (with Sender envelope) + baseBodyFinal → used as prompt for the agent
   • transcriptBodyBase = baseBodyFinal only (without Sender envelope) → passed as transcriptPrompt

2. In buildReplyPromptBodies, these become:

   • queuedBody → followupRun.prompt (with Sender)
   • transcriptCommandBody → followupRun.transcriptPrompt (without Sender)

3. The agent runner appends the prompt (with Sender) to the transcript as a user message via sessionManager.appendMessage().

4. The agent runs and produces a response. The response is appended to the transcript.

5. After the agent reply, rewriteSubmittedPromptTranscript is called:

   // selection-C3otDzGD.js ~line 7118
   rewriteSubmittedPromptTranscript({
       sessionManager,
       sessionFile: params.sessionFile,
       previousLeafId: transcriptLeafId,
       submittedPrompt: effectivePrompt,        // WITH Sender metadata
       transcriptPrompt: params.transcriptPrompt // WITHOUT Sender metadata
   });

6. Since submittedPrompt !== transcriptPrompt, it proceeds to rewrite. It calls rewriteTranscriptEntriesInSessionManager which:

   • Calls sessionManager.branch(firstMatchedEntry.parentId) — creates a new branch from the user message's parent
   • Re-appends the user message with the replacement text (without Sender)
   • This creates a new entry in the transcript

7. The new branch has a new user message entry, which is detected as a pending user turn, triggering a second agent run.

Why It's a Branch, Not a Replacement

rewriteTranscriptEntriesInSessionManager (in transcript-rewrite-DEfbMkgI.js) works by:

1. Finding the matching entry in the current branch
2. Calling sessionManager.branch(entry.parentId) to fork from the parent
3. Re-appending all entries from that point, substituting the replacement

This leaves the old branch intact (the one with the Sender metadata + agent reply). The new branch starts from the same parent with the rewritten content.

Why It Triggers a Second Run

After the rewrite, the transcript's leaf points to the new branch. The new branch has a fresh user message (no response yet), so the agent runner picks it up as a new pending turn and runs the agent again.

Impact

• Double token consumption — every message costs 2x tokens
• Duplicate responses — the user sees two replies
• Conversation confusion — the agent's context contains duplicate user messages, degrading response quality
• Compaction bloat — transcripts grow 2x faster, triggering more frequent compactions

Suggested Fix

Option A: Skip the rewrite entirely. Since the Sender metadata is already injected as untrusted context and the agent handles it correctly, the transcript rewrite provides no value while causing duplicates.

Option B: Perform the rewrite before the agent runs, not after. This way the transcript only ever contains one version of the user message.

Option C: Check if the old branch already has an assistant response. If it does, don't branch — the rewrite is too late.

Files Involved