openclaw - 💡(How to fix) Fix Read-only shell probe failures are classified as mutating tool errors

Summary

In 2026.5.24-beta.2, failed read-only shell probes can be surfaced to chat users as visible ⚠️ 🛠️ ... failed warnings.

Observed examples are equivalent to:

ls "$HOME/.openclaw/service-env"
sed -n '1,240p' ~/.openclaw/workspace/skills/discord/SKILL.md

These are read-only diagnostic/probe failures. The agent can usually recover, use another path, or explain the actual blocker, so surfacing them as mutating-tool warnings creates noisy false alarms on chat surfaces.

Root Cause

src/agents/tool-mutation.ts classifies exec and bash as mutating unconditionally. Downstream final-payload policy treats mutating tool errors as user-visible unless explicitly acknowledged, so a failed read-only ls, sed, rg, git status, or openclaw status probe can be delivered like a failed side effect.

This is narrower than the broader tool-warning delivery-policy issue: the shell command did not mutate state in the first place.

Expected Behavior

Clearly read-only shell probes should be classified as non-mutating and follow the existing non-mutating suppression path. Real or unknown shell commands should remain fail-closed as mutating.

Actual Behavior

A failed read-only shell probe can produce a chat-visible warning such as:

⚠️ 🛠️ <read-only shell probe> failed

Environment

• OpenClaw 2026.5.24-beta.2
• Linux/systemd beta runtime

Fix Shape

I have a patch that conservatively detects common read-only shell probes for bash/exec and keeps unknown commands classified as mutating. It includes coverage for:

• ls $HOME/.openclaw/service-env
• /bin/bash -lc "sed -n '1,240p' ~/.openclaw/workspace/skills/discord/SKILL.md"
• git -C /tmp/repo status --short
• timeout 20 openclaw status --json --all
• mutating counterexamples like git commit, openclaw update, script execution, and file redirection

Related broader policy issue: #39406.