openclaw - 💡(How to fix) Fix [Bug]: Mattermost "Ghost" Responses — Delivery Mirror Sessions Intercept Responses, Main Session Reference Invalidated [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In Mattermost group chats, assistant responses are captured in separate "delivery mirror" sessions instead of being delivered to the channel. The main session's reference becomes invalidated between turns, causing sessions.resolve to fail with INVALID_REQUEST: No session found: current. The user sees the assistant "typing" but no message appears in the channel.

Root Cause Analysis

What Happens

1. Main session (e.g., 54a620f6) starts normally and processes user messages
2. Assistant generates responses and calls message(action=send) successfully — tool returns ok: true
3. Delivery mirror session (e.g., f5ee5ef7) is created to capture the response
4. The response is written to the mirror session with model=delivery-mirror / provider=openclaw
5. The main session's reference becomes invalidated between turns
6. Subsequent sessions.resolve("current") calls fail because the connection IDs have rotated
7. Messages appear to "ghost" — typing indicator shows but no message reaches the channel

Session File Evidence

Main session (54a620f6-7b3c-48db-9da4-159bca7c77d9.jsonl):

• Shows successful tool calls including message(action=send) returning ok: true
• 29 assistant messages recorded in this session
• Session status: running, delivery context intact

Delivery mirror session (f5ee5ef7-210e-461d-8153-22db0f38bd6b.jsonl):

• Created at 07:44:56 UTC (10:44 EET)
• Contains ONLY assistant responses (4 messages)
• All messages have model=delivery-mirror and provider=openclaw
• No user messages — this is a response capture session only
• Messages in mirror session match the "ghosted" messages that didn't appear in channel

Timeline:

10:32 — Main session starts (54a620f6)
10:33 — First successful response
10:42 — First ghost (9-min gap)
10:44 — Delivery mirror session created (f5ee5ef7)
10:51 — Second ghost
10:52 — Third ghost
10:59 — Fourth ghost

Key Finding

The delivery mirror session mechanism is intercepting responses that should go to the main session's channel delivery pipeline. The main session's connection reference is being invalidated/rotated between turns, causing sessions.resolve("current") to fail with different connection IDs each time.

Workaround

Gateway restart clears the stale session references and temporarily restores normal delivery. The issue reoccurs after some time (typically 5-15 minutes of active conversation).

Steps to reproduce

1. Start a conversation in a Mattermost group chat channel
2. Assistant responds successfully once or twice
3. After ~5-10 minutes, responses stop appearing in the channel
4. Assistant shows "typing" indicator but no message is delivered
5. Console shows sessions.resolve errors with rotating connection IDs

Expected behavior

Assistant responses should be delivered to the Mattermost channel via the main session's delivery context, without creating separate delivery mirror sessions that intercept the responses.

Actual behavior

Responses are captured in delivery mirror sessions with model=delivery-mirror, the main session's reference is invalidated between turns, and messages fail to reach the channel despite message(action=send) returning success.

OpenClaw version

2026.5.4

Operating system

EL10

Install method

npm

Model

qwen3.6:27b

Provider / routing chain

openclaw -> llama.cpp

Additional provider/model setup details

No response

Logs, screenshots, and evidence

11:00:01 [ws] ⇄ res ✓ sessions.list 102ms conn=ed497702…876a id=48a2260e…ecc3
11:00:01 [ws] ⇄ res ✗ sessions.resolve 2ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=9d8e41bd…d02b id=8db66466…80d9
11:00:02 [ws] ⇄ res ✗ sessions.resolve 2ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=79bca671…001d id=7b2cd53a…ac36


Note: `sessions.list` succeeds but `sessions.resolve` for "current" fails immediately after, with different connection IDs each attempt.

Impact and severity

Affected: Mattermost users

Additional information

• Issue occurs in Mattermost group chats specifically
• sessions.list succeeds but sessions.resolve("current") fails
• Connection IDs rotate between failed resolve attempts
• The message tool reports success (ok: true) but messages don't appear in channel
• Issue frequency: ~3-4 ghost events per 10-minute window once it starts