When Mattermost Agents Looked Silent, the Real Cause Was thread_replies_disabled

While operating OpenClaw agents on Mattermost, we hit an incident where several agents across multiple nodes appeared to be completely silent in direct messages. The obvious suspects were connectivity issues, model failures, or expired credentials. None of those turned out to be the root cause.

The real problem was more subtle: thread replies were disabled on the Mattermost server, but the agent output still contained [[reply_to_current]]. OpenClaw therefore tried to post the response as a thread reply, and Mattermost rejected it with an HTTP 400 error. From the user side, it looked like the agent never answered. Internally, the reply existed but failed during delivery.

What the logs actually said

The key error was:

thread_replies_disabled: replying to threads is disabled on this server

That immediately reframed the incident. The issue was not that the LLM failed to generate a response. The issue was that the delivery mode conflicted with the server policy.

The most annoying part was that setting channels.mattermost.replyToMode to off was not always enough to fix it. Some sessions were effectively contaminated by historical context: the agent had learned to emit [[reply_to_current]] directly in the final text. In that state, changing the config alone could not fully prevent the failure.

The four changes that actually fixed it

We stabilized the system by treating it as a multi-layer problem and fixing all four layers together:

1. Explicitly updated the agent instructions
   
   We added a hard rule: on Mattermost, never output [[reply_to_current]] or [[reply_to:<id>]].

2. Reset the affected sessions
   
   After backup, the sessions that had learned the bad reply habit were removed so the behavior would not keep resurfacing.

3. Aligned the heartbeat model
   
   We replaced lingering older settings with openai-codex/gpt-5.4 to remove one more variable.

4. Repaired fallback authentication references
   
   Missing auth-profiles.json symlinks were restored so fallback execution would not fail for a different reason later.

What this incident taught us

This was a good reminder that “the agent is silent” does not necessarily mean “the agent is offline.” In practice, three layers were interacting at once:

• Mattermost server restrictions
• model output habits
• session history and behavioral residue

When those layers overlap, the visible symptom is simple, but the fix is not. In this case, changing one config value was not enough. The correct fix was to repair rules, sessions, model alignment, and auth references together.

If you run OpenClaw or similar agents on Mattermost, thread_replies_disabled should be one of the first things you check whenever agents appear silent. Delivery-path errors can look exactly like inference failures from the outside.