openclaw - 💡(How to fix) Fix Repeated approval churn for low-risk local actions is breaking remote-agent usability [3 comments, 3 participants]

Summary

The current approval model creates excessive friction for normal low-risk local actions, especially in remote usage scenarios.

A concrete example:

• user explicitly asks the agent to write a markdown file to Desktop
• the agent requests approval
• user approves
• the same action gets re-prompted again with a new approval code
• the workflow keeps getting interrupted
• in some cases, the only practical way forward seems to be “go back to the host machine and authorize again”

For a local/desktop agent, this is a serious product problem.

This is not just a minor UX annoyance. It undermines the core value of a remote agent.

Why this is a problem

1. It breaks remote usage

If the user is away from the host machine, asking them to come back just to approve a low-risk local file write defeats the purpose of using a remote assistant in the first place.

2. It creates approval churn

Even after explicit approval, the same intent/action can trigger repeated new approval prompts. This makes authorization feel non-sticky and unreliable.

3. It treats low-risk and high-risk actions too similarly

Writing a normal markdown file to Desktop should not have the same interaction burden as:

• destructive file deletion
• privileged system changes
• credential/network modifications
• external side effects

4. It pushes power users away

Users of local/open-source agent systems generally understand there are risks. Many are willing to self-manage and self-repair. What they need is clear scope, auditability, and control — not repeated interruption for routine actions.

Expected behavior

For low-risk local actions (for example writing a normal document to Desktop / Downloads / user-owned folders), the system should support a lower-friction model:

• explicit approval should be reusable within a clear scope
• allow-always should behave like a meaningful persistent authorization, not a one-step illusion
• repeated prompts for the same intent/path/action class should be avoided
• trusted remote channels should be able to authorize low-risk actions without requiring the user to physically return to the host machine

Suggested improvements

1. Risk-tiered authorization

Differentiate clearly between:

• low-risk local file actions
• medium-risk shell/project modifications
• high-risk destructive / privileged / external actions

2. Scoped authorization

Support approval scopes such as:

• this action once
• this session
• this path subtree
• this action class
• this agent/session identity

3. Sticky authorization semantics

If the user chooses allow-always, it should actually be durable within the documented scope.

4. Better explanation in approval UX

Explain:

• why the action is blocked
• the risk tier
• whether approval will persist
• why a repeated approval is happening (if it still does)

5. Remote-first design for trusted channels

If the system supports remote messaging surfaces, it should acknowledge that users may be away from the host machine. Low-risk actions should not require returning to the machine for approval.

Impact

This is not just a security-policy discussion. It directly affects whether the product can be used as a serious daily remote assistant.

If low-risk actions repeatedly trigger approval churn, users will:

• lose trust in the workflow
• avoid using the agent for normal tasks
• disable safeguards entirely
• stop upgrading / fork locally instead

That is a product-retention issue, not just a UX nit.

Short version

Security is important, but security that cannot distinguish between necessary blocking and mechanical blocking will damage normal use.

For a remote-capable local agent, requiring users to repeatedly approve low-risk local actions — or effectively return to the host machine — is the wrong default.