openclaw - 💡(How to fix) Fix Node approvals create too much friction for real maintenance workflows [1 participants]

Summary

Working through exec host=node is currently impractical for real maintenance work because the operator may need to approve command after command, even after already investing time to set up node trust/approvals. This defeats the purpose of using nodes for ongoing remote operations.

What happened

In a real maintenance session on a trusted Linux node (lab-openhand), a simple Orchard update workflow turned into a long series of approvals instead of actual work:

• repeated /approve <id> allow-once prompts for routine follow-up commands
• approvals needed again and again even after prior effort to configure node access for future unattended maintenance
• allow-always / approval handling did not reliably translate into a smooth session-level experience
• commands sometimes failed or had to be retried due to quoting / invocation / sandbox issues, causing even more approval churn
• the operator experience became "approve every 10 seconds" instead of delegating a remote maintenance task

This is especially painful for node-based work that naturally requires multiple dependent steps:

• prechecks
• service stop/start
• health checks
• log inspection
• retries after one failed step
• environment/config discovery

Why this matters

The current node approval UX makes nodes unattractive for exactly the kind of work they should enable:

• remote maintenance
• multi-step operational runbooks
• iterative debugging
• autonomous-but-trusted admin workflows

A user may already have:

• paired the node
• trusted the environment
• explicitly configured approvals in the past

but still gets pulled into a tight approval loop during one live task.

Expected behavior

OpenClaw should offer a smoother trust model for nodes, for example one or more of:

1. session-scoped approval for subsequent exec host=node commands on the same node
2. per-node trust tiers (for example, trusted maintenance node vs untrusted node)
3. batched approval for a multi-step runbook / transaction
4. reliable allow-always semantics that actually reduce approval churn in practice
5. clearer visibility into why a follow-up command still needs approval after prior trust was established

Actual behavior

Even after substantial setup effort, node work still requires frequent manual approvals, making the workflow feel unreliable and unproductive.

Concrete user impact

A user explicitly reported that they had already spent an earlier session carefully setting approvals for all nodes so this would not keep happening, but during real maintenance they still had to approve constantly. Their summary was that working with nodes in the current form is impractical.

Request

Please revisit the node approval UX with real multi-step maintenance flows in mind. The current behavior may be defensible from a security perspective, but the operational ergonomics are poor enough that users avoid or distrust node-based automation.