Problem
When messages.suppressToolErrors: true is configured, non-mutating tool errors are correctly suppressed from being forwarded to the user. However, mutating tool errors (exec, write, edit, etc.) always bypass this setting and emit ⚠️ warnings to the chat channel.
This is problematic for assistants that handle errors gracefully in-context — the user sees raw ⚠️ 🛠️ Exec: ... failed: ... messages even though the assistant already retried or handled the failure in the next turn.
Root Cause
In shouldShowToolErrorWarning():
function shouldShowToolErrorWarning(params) {
// Mutating tools always show, regardless of config
if (params.lastToolError.mutatingAction ??
isLikelyMutatingToolName(params.lastToolError.toolName)) return true;
if (params.suppressToolErrors) return false;
return !params.hasUserFacingReply && !isRecoverableToolError(params.lastToolError.error);
}
The mutating check runs first and returns true unconditionally, ignoring suppressToolErrors.
Proposal
Extend suppressToolErrors to accept a string mode:
{
"messages": {
"suppressToolErrors": "all" // true | false | "all"
}
}
false (default): current behavior
true: suppress non-mutating tool errors (current behavior)
"all": suppress ALL tool errors including mutating
This is backward-compatible — existing boolean configs work unchanged.
Use Case
Running an always-on personal assistant via Telegram. The assistant frequently runs shell commands that may fail on first attempt (SSH timeouts, git conflicts, permission issues) but handles errors by retrying or adjusting. The ⚠️ warnings clutter the Telegram chat with raw error output that the assistant has already addressed.
Current config:
{
"tools": {
"exec": {
"notifyOnExit": false,
"notifyOnExitEmptySuccess": false
}
},
"messages": {
"suppressToolErrors": true
}
}
Despite all three settings, exec errors still leak through to the user.
Environment
- OpenClaw 2026.2.15
- Channel: Telegram (DM)
Problem
When
messages.suppressToolErrors: trueis configured, non-mutating tool errors are correctly suppressed from being forwarded to the user. However, mutating tool errors (exec, write, edit, etc.) always bypass this setting and emit⚠️warnings to the chat channel.This is problematic for assistants that handle errors gracefully in-context — the user sees raw
⚠️ 🛠️ Exec: ... failed: ...messages even though the assistant already retried or handled the failure in the next turn.Root Cause
In
shouldShowToolErrorWarning():The mutating check runs first and returns
trueunconditionally, ignoringsuppressToolErrors.Proposal
Extend
suppressToolErrorsto accept a string mode:{ "messages": { "suppressToolErrors": "all" // true | false | "all" } }false(default): current behaviortrue: suppress non-mutating tool errors (current behavior)"all": suppress ALL tool errors including mutatingThis is backward-compatible — existing boolean configs work unchanged.
Use Case
Running an always-on personal assistant via Telegram. The assistant frequently runs shell commands that may fail on first attempt (SSH timeouts, git conflicts, permission issues) but handles errors by retrying or adjusting. The
⚠️warnings clutter the Telegram chat with raw error output that the assistant has already addressed.Current config:
{ "tools": { "exec": { "notifyOnExit": false, "notifyOnExitEmptySuccess": false } }, "messages": { "suppressToolErrors": true } }Despite all three settings, exec errors still leak through to the user.
Environment