openclaw - 💡(How to fix) Fix Beta blocker: Mattermost - /new can silently reset session without visible acknowledgement

Bug type

Regression (worked before, now fails)

Beta release blocker

Yes

Summary

In Mattermost direct chat on 2026.5.24-beta.2, /new can reset session state while producing no visible success or failure acknowledgement.

Steps to reproduce

1. Start OpenClaw 2026.5.24-beta.2 with Mattermost enabled.
2. Open a Mattermost direct chat with the bot.
3. Send /new with a leading space so Mattermost does not consume it as a native slash command.
4. Observe that session reset side effects occur in logs, but no visible New session started or failure message is posted in the direct chat.

Expected behavior

/new and /reset are state-changing session commands. After authorization, they should always post a visible acknowledgement in the source Mattermost conversation, such as ✅ New session started., ✅ Session reset., or a visible failure/authorization message. The command should not silently change session state.

Actual behavior

A leading-space /new in a Mattermost direct chat was processed: reset/session side effects occurred and the session-memory hook wrote a new session context. No visible success or failure acknowledgement appeared in Mattermost. Mattermost outbound delivery itself was healthy, as separate restart-complete notices posted to stored Mattermost routes before and after the silent reset. A local workaround that explicitly allowed the reset acknowledgement through source-reply suppression restored visible ✅ New session started. replies in controlled tests.

OpenClaw version

2026.5.24-beta.2 (abb43c9)

Operating system

macOS 26.3.1 (25D2128), arm64

Install method

npm/global CLI package under a macOS launchd gateway

Model

openai/gpt-5.5 (thinking=low, fast=off)

Provider / routing chain

Mattermost direct message -> OpenClaw gateway -> OpenAI provider

Additional provider/model setup details

The issue occurs before a normal model response is required: /new is a session reset/control path. Provider auth prewarm completed successfully during the same runtime window, and Mattermost outbound posting was separately verified by visible restart-complete notices.

Logs, screenshots, and evidence

Runtime:
- OpenClaw 2026.5.24-beta.2 (abb43c9)
- macOS 26.3.1 (25D2128), arm64
- Node v24.12.0
- Effective model: openai/gpt-5.5 (thinking=low, fast=off)

Observed silent reset:
- 2026-05-25T18:39:20.210-04:00 [hooks/session-memory] Session context saved after ` /new`.
- No visible `New session started`, `Session reset`, or failure message appeared in the Mattermost direct chat for that reset.

Mattermost outbound was healthy in the same session:
- 2026-05-25T18:37:31.741-04:00 [gateway] restart-complete notice delivered to 6/6 stored Mattermost routes.
- 2026-05-25T18:44:08.959-04:00 [gateway] restart-complete notice delivered to 6/6 stored Mattermost routes.

Control check after local workaround:
- 2026-05-25T18:46:11.946-04:00 [hooks/session-memory] Session context saved after ` /new`.
- 2026-05-25T18:46:12.631-04:00 [mattermost] delivered reply to user:<redacted>.
- 2026-05-25T18:48:38.085-04:00 [hooks/session-memory] Session context saved after ` /new`.
- 2026-05-25T18:48:38.710-04:00 [mattermost] delivered reply to user:<redacted>.

Code-path evidence from local inspection:
- Direct Mattermost turns can use `sourceReplyDeliveryMode=message_tool_only`.
- That mode suppresses automatic plain source replies.
- The reset command path can complete state-changing session work without a visible acknowledgement unless the reset acknowledgement is explicitly allowed through source-reply suppression.

Impact and severity

Affected: Mattermost direct-chat users using /new or /reset on the beta. Severity: High for chat operations because a state-changing command can silently succeed. Frequency: Reproduced in the observed Mattermost direct-chat reset path before workaround; controlled post-workaround tests visibly acknowledged. Consequence: Users may believe reset failed or that the bot is hung, while session state has actually changed. This makes recovery from broken sessions confusing and can lead to repeated reset attempts.

Additional information

The repro used leading-space /new because Mattermost native slash-command handling otherwise intercepts /new before OpenClaw can process it as a text command. This issue is scoped to OpenClaw receiving and processing the command but not producing a visible acknowledgement.

Temporary local workaround: mark the session reset acknowledgement as explicitly deliverable through source-reply suppression. In the observed code path, Mattermost direct turns can run with sourceReplyDeliveryMode=message_tool_only, which suppresses automatic plain source replies. The workaround tags the /new / reset acknowledgement so that it bypasses that suppression and is delivered back to the source Mattermost conversation. After applying that workaround, controlled /new tests produced visible ✅ New session started. replies again.

Upgrade boundary: last known good pre-upgrade runtime was OpenClaw 2026.5.18 (50a2481). First known bad version is OpenClaw 2026.5.24-beta.2 (abb43c9).