When Mattermost agents looked silent, the real culprit was not replyToMode but reply tags in the final message

We were investigating a case where several agents appeared to stop replying in Mattermost DMs. At first glance, it looked like a gateway issue, a model-side failure, or a transient delivery problem. The actual root cause was much more mundane: the assistant's final message still contained [[reply_to_current]], and OpenClaw tried to send that message as a thread reply.

In this Mattermost environment, thread replies had already been disabled. That meant the send operation failed with HTTP 400, but from the user's perspective the symptom was simply: the agent looked silent. No crash, no timeout, no obvious red error in the UI. Just silence.

Why this was a trap

The misleading part was that replyToMode: off was already configured. It would be natural to assume that thread replies were impossible after that. But configuration was not enough. If the model still emitted [[reply_to_current]] or [[reply_to:<id>]] inside the final message body, the downstream sender treated the payload as a thread reply anyway.

In other words, the effective payload mattered more than the configuration value. Looking only at settings was not sufficient. We had to inspect three things together:

• the final assistant output
• Mattermost channel constraints
• server-side logs

The visible symptoms

The symptoms were noisy and easy to misread:

• users saw an agent that appeared unresponsive
• logs showed thread_replies_disabled
• delivery failed with HTTP 400 even though the agent itself did not crash
• unrelated auth and model inconsistencies created extra noise during debugging

This is exactly the kind of incident where the visible symptom pulls you in the wrong direction. "The agent is silent" sounds like a model or infrastructure problem. In reality, the message body was accidentally asking for a thread reply in an environment where thread replies were forbidden.

What actually fixed it

The effective mitigation was a four-part cleanup:

1. explicitly document in AGENTS.md that Mattermost responses must never output [[reply_to_current]] or [[reply_to:<id>]]
2. reset the affected sessions so old conversational habits would not keep leaking the same pattern
3. align leftover model settings in heartbeat and related configs with the current model
4. repair missing auth-profiles.json symlinks found on some agents

Those other fixes improved overall health, but the main issue was the reply tag itself. Without removing that pattern, the "silent agent" symptom kept coming back.

Operational takeaway

If you ever see Mattermost agents that "sometimes disappear" or "go silent only in one environment," check these first:

• whether the logs contain thread_replies_disabled
• whether the final assistant output still includes reply tags
• whether the actual sent payload matches the intended configuration

This incident was a good reminder that configuration is not the whole truth. The final payload wins. And when the UI only shows silence, logs plus payload inspection will usually get you to the answer faster than staring at the settings screen.