OpenClaw merged PR #96599, "fix: surface provider authentication failures in channels", a channel behavior fix for one of the most frustrating bot failure modes: a message receives a reaction, but no useful reply ever appears.
The bug involved provider HTTP 401 authentication failures. When a model provider rejected a request for missing or invalid authentication, OpenClaw could treat the error as a generic runner failure that was eligible for no reply in shared channels. The user saw the bot acknowledge the message, but never got the actionable auth warning.
That is bad UX, and it is worse in group channels where the person who sees the stall may not be the person who configured the provider.
From Silence To Guidance
The PR changes how proven invalid-token HTTP 401 failures are classified. Instead of letting that error fall through to a generic no-reply path, OpenClaw now routes it through the existing visible failure path with sanitized authentication guidance.
The key word is sanitized. Provider errors can contain raw details that should not be pasted into a public or semi-public channel. The fix is not to dump the provider response into chat. It is to recognize a known auth failure shape and surface a concise message that tells the operator to retry or re-authenticate.
That keeps the channel useful without leaking unnecessary provider internals.
Why Channel Operators Should Care
Channel agents have a different failure model than local CLI agents. In a terminal, a provider auth error is usually visible to the person running the command. In Slack, Discord, Telegram, WhatsApp, or Microsoft Teams, the user may only see the agent stop responding.
That makes silence expensive. People do not know whether the bot is busy, broken, rate-limited, missing credentials, or waiting on an approval.
PR #96599 narrows one common source of ambiguity. If the provider rejects the request with a recognizable authentication failure, OpenClaw should now explain the auth problem in the channel instead of leaving users with only a reaction.
Test Coverage
The PR reports focused classifier coverage and a larger reply-runner suite covering Slack, Discord, Telegram, WhatsApp, and Microsoft Teams channel and group behavior. That spread matters because the bug lives in shared reply plumbing, not in a single channel adapter.
The change also preserves the existing privacy boundary. The reply path uses existing sanitized authentication copy rather than echoing the original provider text.
Bottom Line
This is a small runtime classification fix with a practical support payoff. A channel bot that silently stalls on provider authentication failure creates confusion for users and extra debugging work for operators.
With PR #96599 merged, OpenClaw should do the more useful thing: acknowledge the problem, keep provider details private, and tell the channel enough for someone to fix the credentials.