Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Use this version:

Title
Exec approvals have become unusable: constant prompts, expired IDs, and security theater

Body
The current exec approval flow is honestly ridiculous.

After the recent changes, OpenClaw now asks for approval so often that the whole thing has crossed the line from “security feature” into “hostile, impractical product design.”

This is not a case of “slightly annoying but safer.” It is the worst of both worlds:

• the user experience gets dramatically worse
• and the security benefit becomes questionable because users are trained to approve everything just to get on with their lives

That is the core problem here:

If you prompt constantly, people stop evaluating prompts.
They approve whatever pops up, because they already asked the system to do the thing and now the product is blocking them with paperwork.

So what exactly is being achieved here?

Not real security:

• most normal users do not understand the shell commands they are being asked to approve
• even technical users are not going to spend all day reading and validating every approval request
• if the system asks often enough, everyone eventually learns the same behavior: just approve it so it works

That means this design is not just frustrating — it is self-defeating.

It fails on both fronts:

1. Terrible user experience

• constant interruptions
• repeated approval prompts for routine tasks
• expired approval IDs
• confusing flow between Control UI / Telegram / terminal
• unclear whether “Telegram exec approvals enabled” means approvals are reduced, rerouted, or still required constantly
• too much cognitive overhead for normal operation

2. Bad security outcomes

• approval fatigue
• blind approval behavior
• users being conditioned to click/approve without understanding
• security reduced to ritual instead of meaningful protection

And that is what makes this so frustrating:
the product adds a lot of friction, but does not clearly add proportional safety.

If anything, it encourages exactly the wrong habit:
approve first, think never, because otherwise nothing gets done.

That is not a security model. That is security theater with extra steps.

What should happen instead

• approvals should be rare, not constant
• low-risk internal maintenance/read-only commands should not feel like defusing a bomb
• truly sensitive/destructive actions should be the ones that trigger hard friction
• trust tiers and durable scoped trust should exist so people are not re-approving everything forever
• approval prompts should be easy to understand, hard to misroute, and never fail with useless garbage like unknown or expired approval id

Expected behavior
A sane system where:

• approvals are reserved for genuinely risky actions
• routing is obvious
• trust can be established durably
• the user is not forced into approval fatigue

Actual behavior
The system keeps asking for approval for routine actions, creates confusing and expiring prompt flows, and trains users to blindly approve anything that appears after a request.

Bottom line
If the product requires approval for everything, users will approve everything.
At that point, you have damaged usability without actually solving the security problem.

That is why this feels so bad in practice. It is not just annoying. It is fundamentally misdesigned.

Steps to reproduce

just do anything

Expected behavior

see above

Actual behavior

see above

OpenClaw version

2026.03.31

Operating system

macOs

Install method

No response

Model

doesn't matter

Provider / routing chain

openclaw

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response