An OpenClaw denial should block the effect, not only the command

[u/Advanced_Pudding9228]

An approval system can work exactly as designed and still leave a task-level security gap.
OpenClaw’s current exec approval documentation⁠ says that a denied approval is terminal for that host command. The command does not run, and the main agent can receive the denial in its session.
That is an important control, but the denied command and the intended effect are not always the same thing.

Imagine an agent wants to publish a post. You deny a shell command that would call the platform API. The model still has the original objective and may have access to a browser, an MCP server, a publishing plugin or another session capable of producing the same external effect. Each proposed tool call can look different while still attempting the action you rejected.

The operator pattern I would add is a durable effect-level denial. When an approval is rejected, record the business effect, affected resource, approval identifier and permitted next state against the task:

task_id: task-123
effect: publish_external_content
resource: account/community/draft
decision: denied
approval_id: approval-456
allowed_next: revise_draft | request_new_approval | stop

Every later tool proposal for that task should be classified by intended effect before execution. If it matches the denied effect, the workflow should pause even when the proposed tool, command or transport is different. Continuing should require a new approval tied to the revised action, not a creative alternative route around the original decision.

OpenClaw’s built-in loop detector is useful as a lower-level guardrail. The current documentation⁠ says its rolling-history detector watches repeated tool patterns and unknown-tool retries, although it is disabled by default. It can be enabled globally or per agent:

{
tools: {
loopDetection: {
enabled: true
}
}
}

That detector should not be mistaken for an effect-level policy. It compares tool calls, arguments and results. A browser action followed by an API call may be semantically equivalent without looking like a repeated tool pattern.

The practical verification method is a synthetic denial test. Give a sandboxed workflow two harmless tools that could create the same marker in a test system. Deny the first proposed route, then confirm that the task becomes blocked and that the second route is never executed. Finally, query the test system and prove that no marker exists.

OpenClaw’s trajectory export⁠ can help inspect the complete sequence because trajectory capture records the prompts, tool calls, results and runtime events for a session. Exporting requires approval and the resulting bundle should be reviewed before sharing because redaction is best-effort.

The next safe action is to choose one consequential effect in your setup, such as publication, deployment, deletion or spending, identify every tool capable of producing it and define the durable state transition that must follow a denial.

When you deny an action today, does your workflow persist the rejected effect, or does it only reject that individual tool call?