Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: exec security defaults to allowlist mode after update — no migration path for existing operator setups [1 comments, 2 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#59003•Fetched 2026-04-08 02:30:08
View on GitHub
Comments
1
Participants
2
Timeline
8
Reactions
1
Author
fwendsfwends
Participants
fwendsfwendssteipetesteipete
Timeline (top)
cross-referenced ×5closed ×1commented ×1locked ×1

After updating to 2026.4.1, exec commands fail with "allowlist miss" in existing single-operator setups. The security model silently changed from permissive to allowlist as the default, with no migration, no warning, and no clear way to opt out.

Setting tools.exec.ask = "off" has no effect because ask and security are orthogonal — ask=off only controls whether a prompt appears, but if security=allowlist and the allowlist is empty, exec is still blocked. This is not documented and not obvious.

The only working combination is security=full + ask=off in exec-approvals.json, but this file and its valid values are not documented anywhere in the config system.

Error Message

  1. Gets "allowlist miss" error — blocked
  2. Set tools.exec.security = "none" — validation error, "none" is not valid

Root Cause

Setting tools.exec.ask = "off" has no effect because ask and security are orthogonal — ask=off only controls whether a prompt appears, but if security=allowlist and the allowlist is empty, exec is still blocked. This is not documented and not obvious.

RAW_BUFFERClick to expand / collapse

Bug type

Regression / breaking change without migration path

Summary

After updating to 2026.4.1, exec commands fail with "allowlist miss" in existing single-operator setups. The security model silently changed from permissive to allowlist as the default, with no migration, no warning, and no clear way to opt out.

Setting tools.exec.ask = "off" has no effect because ask and security are orthogonal — ask=off only controls whether a prompt appears, but if security=allowlist and the allowlist is empty, exec is still blocked. This is not documented and not obvious.

The only working combination is security=full + ask=off in exec-approvals.json, but this file and its valid values are not documented anywhere in the config system.

Steps to reproduce

  1. Existing single-operator local gateway setup, exec was working before update
  2. Update to 2026.4.1
  3. Agent attempts any exec command
  4. Gets "allowlist miss" error — blocked
  5. Set tools.exec.ask = "off" — still blocked
  6. Set tools.exec.security = "none" — validation error, "none" is not valid
  7. Set exec-approvals.json defaults ask: "off", security: "none" — "none" silently invalid, falls back to allowlist, still blocked
  8. Only fix: manually set security: "full" in exec-approvals.json for both defaults and agents["*"]

Why this is bad

  • tools.exec.ask and tools.exec.security are not clearly documented as separate axes
  • exec-approvals.json is not documented — its location, format, and valid values are unknown to operators
  • Valid values for security (deny, allowlist, full) are not exposed in openclaw config set help
  • "none" is silently treated as invalid and falls back to allowlist instead of erroring
  • Single-operator private setups have no reason to need an allowlist — there should be a clear operator or private mode that disables all approval friction

Time lost

2+ hours across exec approval popup issues and allowlist blocking. A working setup was completely locked down by the update with no recovery path visible to the user.

Environment

  • Version: 2026.4.1
  • Platform: macOS, single-user LaunchAgent gateway
  • Agent: local operator, no untrusted input

extent analysis

TL;DR

To fix the "allowlist miss" error after updating to 2026.4.1, manually set security: "full" in exec-approvals.json for both defaults and agents["*"].

Guidance

  • The issue is caused by a silent change in the security model from permissive to allowlist as the default, so updating the exec-approvals.json file is necessary.
  • Verify that tools.exec.ask is set to "off" to ensure that the prompt does not appear, but note that this does not affect the allowlist block.
  • Check the exec-approvals.json file location and format, as it is not documented in the config system.
  • Be aware that setting security to "none" will silently fall back to allowlist, so use "full" instead.

Example

No code snippet is provided as the issue does not require a code change, but rather a configuration update.

Notes

The provided solution assumes a single-operator private setup where the allowlist is not necessary. In other environments, additional configuration may be required.

Recommendation

Apply the workaround by setting security: "full" in exec-approvals.json, as this is the only known working combination to resolve the "allowlist miss" error. This is recommended because the default security model change was not properly documented or announced, and this workaround provides a clear path to recover from the update.

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…
#request error#file not found#serialization error#model compatibility#GPU setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING