Description
Users receive false positive notifications like:
⚠️ 📝 Edit: in ~/.openclaw/workspace/MEMORY.md (702 chars) failed
even when the file was successfully written. This is caused by the warning policy in resolveToolErrorWarningPolicy (src, line ~177016) unconditionally returning showWarning: true for all mutating tool errors, without checking if the error is recoverable.
Root Cause
In pi-embedded-CbCYZxIb.js, the warning policy has two branches:
Non-mutating tools (exec, bash, etc.):
return {
showWarning: !params.hasUserFacingReply && !isRecoverableToolError(params.lastToolError.error),
includeDetails
};
Mutating tools (edit, write, etc.):
return {
showWarning: true, // ← always shows, ignores recoverable errors
includeDetails
};
The non-mutating branch correctly suppresses warnings for recoverable errors. The mutating branch does not.
There is already a recovery wrapper (wrapHostEditToolWithPostWriteRecovery) that catches cases where the edit tool throws but the file was correctly updated. However, this wrapper only handles errors thrown by the underlying tool — it does not prevent lastToolError from being set when other error paths trigger before recovery completes.
Reproduction
- Have frequent edits to workspace files (MEMORY.md, daily memory files, fear_state updates)
- File lock contention or transient I/O timing causes the edit tool to report an error
- The recovery wrapper may or may not catch it depending on timing
- User receives a false positive notification
Proposed Fix
Add recoverable error check to the mutating tool branch, matching the non-mutating behavior:
if (params.lastToolError.mutatingAction ?? isLikelyMutatingToolName(params.lastToolError.toolName)) {
return {
showWarning: !isRecoverableToolError(params.lastToolError.error), // ← add this check
includeDetails
};
}
This is a one-line change that aligns mutating tool warning behavior with non-mutating tools, while still showing genuine failures.
Environment
- OpenClaw version: 2026.3.23-2
- Channel: Telegram
- Platform: Linux (x64)
Description
Users receive false positive notifications like:
even when the file was successfully written. This is caused by the warning policy in
resolveToolErrorWarningPolicy(src, line ~177016) unconditionally returningshowWarning: truefor all mutating tool errors, without checking if the error is recoverable.Root Cause
In
pi-embedded-CbCYZxIb.js, the warning policy has two branches:Non-mutating tools (exec, bash, etc.):
Mutating tools (edit, write, etc.):
The non-mutating branch correctly suppresses warnings for recoverable errors. The mutating branch does not.
There is already a recovery wrapper (
wrapHostEditToolWithPostWriteRecovery) that catches cases where the edit tool throws but the file was correctly updated. However, this wrapper only handles errors thrown by the underlying tool — it does not preventlastToolErrorfrom being set when other error paths trigger before recovery completes.Reproduction
Proposed Fix
Add recoverable error check to the mutating tool branch, matching the non-mutating behavior:
This is a one-line change that aligns mutating tool warning behavior with non-mutating tools, while still showing genuine failures.
Environment