Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: approval flow is impractical / self-defeating after recent change [1 pull requests, 4 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#58616•Fetched 2026-04-08 02:00:10
View on GitHub
Comments
4
Participants
3
Timeline
8
Reactions
2
Author
allen-ksqallen-ksq
Participants
allen-ksqallen-ksqnkondratyk93nkondratyk93vincentkocvincentkoc
Timeline (top)
commented ×3labeled ×2closed ×1cross-referenced ×1

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.

Root Cause

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

PR fix notes

PR #58792: fix(exec): resolve remote approval regressions

Description (problem / solution / changelog)

Fixes #58710 Fixes #58722 Fixes #58739 Fixes #58752 Fixes #58662 Fixes #46573 Fixes #58769 Addresses #58715 Addresses #58616 Addresses #58691 Addresses #49266 Addresses #43279 Addresses #46846 Addresses #46848 Addresses #42574

Summary

This PR fixes the 2026.3.31 exec-approval regression cluster at the shared policy/runtime seams instead of stacking more per-channel workarounds on top.

Root causes addressed:

  • src/agents/bash-tools.exec.ts inherited ask from exec-approvals.json but not security, so security:"full" + ask:"off" in exec-approvals.json could still collapse back to allowlist and fail remote exec.
  • shared approval availability could report a chat surface as approval-capable even when native delivery was not actually enabled.
  • Slack and Discord runtime handlers drifted from the shared approver-resolution logic and could disagree with inferred approver config from allowFrom / defaultTo.
  • isolated cron runs inherited stricter approval policy with no interactive approval surface, then fell into a dead-end denial path.
  • allow-always persisted only as an allowlist-mode implementation detail, so ask:"always" kept re-prompting and remote channels effectively treated allow-always like allow-once.
  • shell-wrapper paths that intentionally fail static allowlist analysis had no durable trust representation, so repeated node allow-always approvals could still degrade back into repeated prompts.

What changed

  • make gateway exec inherit both security and ask defaults from exec-approvals.json when tool policy is unset
  • make shared native approval availability require both approvers and native delivery enablement
  • make Slack handler use the canonical request matcher instead of a local partial check
  • make Discord handler use resolved approvers everywhere, including inferred approvers
  • resolve isolated cron no-route approval dead-ends from the effective host fallback policy when trusted automation is allowed
  • make openclaw doctor warn when tools.exec is broader than ~/.openclaw/exec-approvals.json, so stricter host-policy conflicts become explicit instead of silently clamping
  • persist allow-always as durable user-approved trust and honor it on future gateway and node-host exec calls
  • keep static allowlist entries from silently bypassing ask:"always", so the durable-trust fix does not weaken explicit policy
  • persist exact-command durable trust for shell-wrapper paths that cannot safely materialize an executable allowlist entry, so repeated node allow-always approvals actually stick without requiring a restart
  • when Windows cannot build an allowlist execution plan, require explicit approval instead of hard-dead-ending the exec path
  • add regression coverage for the policy-inheritance, inferred-approver, cron/headless, durable-trust, and shell-wrapper reuse paths
  • add changelog entries

Verification

  • pnpm test -- src/agents/bash-tools.exec.approval-id.test.ts src/plugin-sdk/approval-delivery-helpers.test.ts extensions/slack/src/monitor/exec-approvals.test.ts extensions/discord/src/monitor/exec-approvals.test.ts extensions/slack/src/exec-approvals.test.ts extensions/discord/src/exec-approvals.test.ts
  • pnpm test -- src/node-host/invoke-system-run.test.ts src/infra/exec-approvals-allow-always.test.ts src/agents/bash-tools.exec.approval-id.test.ts src/infra/exec-approvals-policy.test.ts src/node-host/exec-policy.test.ts
  • pnpm check
  • pnpm build

Notes

  • This still does not add Windows allowlist-plan reconstruction. The Windows path becomes usable again because preapproved full/off policy from exec-approvals.json now actually takes effect on remote exec, unsupported allowlist-plan cases fall back to explicit approval instead of a hard dead end, and durable exact-command trust covers repeated shell-wrapper reruns that cannot safely persist an executable allowlist entry.

Changed files

  • CHANGELOG.md (modified, +3/-0)
  • extensions/discord/src/exec-approvals.test.ts (modified, +24/-12)
  • extensions/discord/src/exec-approvals.ts (modified, +15/-13)
  • extensions/discord/src/monitor/exec-approvals.test.ts (modified, +46/-3)
  • extensions/discord/src/monitor/exec-approvals.ts (modified, +8/-4)
  • extensions/slack/src/config-ui-hints.ts (modified, +1/-1)
  • extensions/slack/src/exec-approvals.test.ts (modified, +20/-13)
  • extensions/slack/src/exec-approvals.ts (modified, +14/-6)
  • extensions/slack/src/monitor/exec-approvals.test.ts (modified, +41/-2)
  • extensions/slack/src/monitor/exec-approvals.ts (modified, +10/-15)
  • src/agents/bash-tools.exec-host-gateway.test.ts (added, +124/-0)
  • src/agents/bash-tools.exec-host-gateway.ts (modified, +78/-5)
  • src/agents/bash-tools.exec-host-node.ts (modified, +143/-100)
  • src/agents/bash-tools.exec-host-shared.ts (modified, +36/-0)
  • src/agents/bash-tools.exec-types.ts (modified, +1/-0)
  • src/agents/bash-tools.exec.approval-id.test.ts (modified, +288/-1)
  • src/agents/bash-tools.exec.ts (modified, +12/-3)
  • src/agents/pi-tools.ts (modified, +1/-0)
  • src/commands/doctor-security.test.ts (modified, +166/-0)
  • src/commands/doctor-security.ts (modified, +148/-0)
  • src/config/bundled-channel-config-metadata.generated.ts (modified, +1/-1)
  • src/config/types.discord.ts (modified, +1/-1)
  • src/config/types.slack.ts (modified, +1/-1)
  • src/infra/exec-approvals-allowlist.ts (modified, +37/-4)
  • src/infra/exec-approvals-policy.test.ts (modified, +81/-0)
  • src/infra/exec-approvals-store.test.ts (modified, +61/-0)
  • src/infra/exec-approvals.ts (modified, +103/-8)
  • src/node-host/exec-policy.test.ts (modified, +14/-0)
  • src/node-host/exec-policy.ts (modified, +14/-0)
  • src/node-host/invoke-system-run-allowlist.ts (modified, +3/-0)
  • src/node-host/invoke-system-run.test.ts (modified, +57/-0)
  • src/node-host/invoke-system-run.ts (modified, +47/-31)
  • src/plugin-sdk/approval-delivery-helpers.test.ts (modified, +7/-0)
  • src/plugin-sdk/approval-delivery-helpers.ts (modified, +2/-1)
RAW_BUFFERClick to expand / collapse

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

extent analysis

TL;DR

Implement a trust tier system with durable scoped trust to reduce constant approval prompts and reserve approvals for genuinely risky actions.

Guidance

  • Identify and categorize actions by risk level to determine which actions should require approval and which can be trusted.
  • Develop a trust tier system that allows users to establish durable trust for low-risk actions, reducing the need for constant approvals.
  • Improve the approval prompt flow to make it easier for users to understand and reduce approval fatigue.
  • Consider implementing a routing system that clearly indicates when approvals are required and when they are not.

Example

A possible implementation could involve creating a configuration file that defines trust tiers and scoped trust settings, allowing users to customize their approval experience.

Notes

The current implementation may require significant changes to the approval flow and trust model, and may involve trade-offs between security and usability.

Recommendation

Apply a workaround by implementing a trust tier system with durable scoped trust, as this approach addresses the core issue of constant approval prompts and approval fatigue, and can help strike a better balance between security and usability.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

see above

#api#ssr#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: approval flow is impractical / self-defeating after recent change [1 pull requests, 4 comments, 3 participants]