openclaw - 💡(How to fix) Fix enhancement - Telegram bot is not practically usable with per-command exec approvals — need durable approval scopes [2 comments, 3 participants]

Hi. The current exec approval model makes OpenClaw practically unusable through the Telegram bot.

Problem

When the assistant needs exec, approval is requested too often and usually falls back to the Web UI / terminal UI.

In practice the flow becomes:

1. I ask the bot to do something in Telegram
2. it needs exec
3. approval is required again
4. approval must be handled in UI
5. I’m away from the computer
6. the assistant becomes useless

This breaks the core value of a mobile/chat-first assistant.

Additional failure mode

There is another serious issue: when the Telegram bot gets blocked on approval, the workflow does not reliably continue after approval is granted.

In practice, after I approve the action in the UI, the bot often does not resume the original process on its own. It stops, loses execution continuity, or requires additional manual prompting to continue.

So the problem is not only that approvals are too frequent and routed away from Telegram, but also that approval does not reliably restore task continuity.

Control UI usability problem

The fallback UI itself also has a serious usability flaw: long approval requests can become impossible to confirm.

If the approval request contains a long command, the approval panel may not provide usable scrolling to the bottom. In that state, it can be impossible to reach the confirm button at all.

That turns an already frustrating approval flow into a dead end: the bot is blocked, the user is forced into the UI, and the UI may still prevent approval from being completed.

Main issue

Approvals seem too tied to individual shell invocations and exact command shapes.

So even if I already approved one action, the next closely related action often asks again.

From the user side this feels like endless approval spam.

What is needed

OpenClaw needs a more durable approval model, for example:

• approve for the current session/conversation
• approve for the current task/plan
• approve for this agent + channel + host
• approve a bounded capability scope such as read-only local diagnostics
• keep approvals inside Telegram instead of falling back to UI whenever possible
• reliably resume the blocked task after approval is granted
• make long approval dialogs fully scrollable and actionable in the UI

Suggested implementation direction

Instead of approving exact shell strings, classify and approve normalized execution intents, for example by:

• agent
• host
• channel
• risk level
• capability class
• TTL / session scope

Also, small shell variations (&&, pipes, wrappers, helper commands) should not invalidate an approval if the underlying risk class is unchanged.

Blocked tasks should also preserve execution state well enough to continue automatically after approval, instead of forcing the user to restart or manually re-prompt the flow.

The Control UI should also guarantee that approval panels remain scrollable and that confirm/deny actions stay reachable even for very long commands.

Bottom line

The current model may be safe, but for Telegram usage it is too granular, too desktop-dependent, too fragile after approval, and too brittle in the UI itself.

Please add durable approval scopes, reliable post-approval task continuation, and a usable approval UI for long requests. Without that, using OpenClaw through Telegram as a real assistant is not viable.