### Root cause analysis

The current runtime appears to have **two separate user-turn paths** for the same `webchat` input:

#### 1) Early webchat transcript update path

`/root/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/chat-DznnoAn8.js`

- `emitUserTranscriptUpdate()` at `2369-2394`
- calls `emitSessionTranscriptUpdate({ message: buildChatSendTranscriptMessage(...) })`
- `buildChatSendTranscriptMessage(...)` at `1263-1270` produces a plain:
  - `role: "user"`
  - `content: params.message`

#### 2) Main reply/transcript path with inbound metadata

`/root/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/get-reply-CSQ5BMwG.js`

- `buildInboundUserContextPrefix(...)` at `1820`
- inbound user context is assembled into prompt/transcript body around `2231-2242`
- `transcriptCommandBody` is passed onward at `2455-2456` and `2533-2534`

Then runner path forwards transcript prompt:

`/root/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/agent-runner.runtime-CbAg9IpO.js`

- CLI path: `732`
- embedded path: `831`
- run dispatch: `3070`

#### 3) Transcript update broadcast does not sanitize the visible message

`/root/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/server.impl-CtLS1ywt.js`

- `createTranscriptUpdateBroadcastHandler(...)` at `9229-9253`
- broadcasts `update.message` via `session.message`
- does **not** call `stripInboundMetadata(...)` / `stripEnvelopeFromMessage(...)`

#### 4) There is already an explicit contract that this metadata must never be displayed

`/root/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/strip-inbound-meta-DaDVfj8b.js`

Header comment says OpenClaw-injected inbound metadata blocks are AI-facing only and:

> must never surface in user-visible chat history

The sentinel list includes:

- `Conversation info (untrusted metadata):`
- `Sender (untrusted metadata):`

### Interpretation

This strongly suggests a regression where `webchat` now exposes both:

1. the early plain user transcript update
2. a second transcript/broadcast path carrying inbound metadata

So this is not just an external duplicate submit. It is an internal duplication / consumer-sanitization failure.

### Proposed fix

#### Minimal safe mitigation

Sanitize transcript-broadcast user messages before they are sent to Control UI in:

- `createTranscriptUpdateBroadcastHandler(...)`

using the same stripping path already intended for display surfaces, e.g. `stripInboundMetadata(...)` / `stripEnvelopeFromMessage(...)`.

#### Proper fix

Ensure `webchat` produces only **one canonical user-turn representation** per input.

Either:

1. suppress the early `emitUserTranscriptUpdate()` path for normal `webchat` user turns, or
2. suppress the later duplicate transcript-visible user entry when it represents the same logical turn, or
3. add stable dedupe/idempotency across transcript update broadcast for the same webchat user turn.

### Related issues

- #72671 — earlier report with similar symptom, but closed
- #72227 — optimistic `You` vs `openclaw-control-ui` duplicate, closed
- #69208 — umbrella: duplicate transcript / replay / context assembly across channels
- #71992 — related Control UI duplicate regression on assistant side

### Impact and severity

User-visible duplicate messages in Control UI, plus visible leakage of internal inbound metadata.

Also likely increases confusion during transcript/history/debugging and may indicate broader duplicate persistence / duplicate broadcast behavior.

### Additional information

If useful, I can provide a smaller patch proposal focused specifically on `createTranscriptUpdateBroadcastHandler(...)` as a stopgap mitigation.