openclaw - ✅(Solved) Fix [Bug]: Update 2026.4.1 broke exec completely for existing setups — full day of work lost [1 pull requests, 5 comments, 5 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#59006Fetched 2026-04-08 02:30:03
View on GitHub
Comments
5
Participants
5
Timeline
19
Reactions
1
Author
Timeline (top)
cross-referenced ×7commented ×5subscribed ×5mentioned ×2

The 2026.4.1 update introduced sandboxing and exec approval changes that completely broke exec for all existing single-operator setups. There was no migration guide, no warning on startup, and no way to opt out using documented config options. A full working day was lost trying to recover.

Error Message

  1. security: "none" in exec-approvals.json silently falls back to allowlist — no error, just broken

Root Cause

  1. Docker sandbox auto-created for all agents with no sandbox config (via agents.defaults.sandbox.mode = "all" set automatically by update)
  2. Sandbox container persists across gateway restarts via ~/.openclaw/sandbox/containers.json — removing it manually doesn't work because the gateway recreates it
  3. tools.exec.ask = "off" does nothingask and security are separate axes, but this is not documented
  4. tools.exec.security = "none" is rejected — not a valid value, but the valid values (deny, allowlist, full) are not shown in help or docs
  5. exec-approvals.json is undocumented — its location, format, purpose, and valid values are unknown to operators
  6. security: "none" in exec-approvals.json silently falls back to allowlist — no error, just broken
  7. tools.exec.host = "gateway" ignored while sandbox container exists — routing config has no effect inside a sandbox session

Fix Action

Fixed

PR fix notes

PR #59112: fix(exec): strip invalid approval policy enums during config normalization

Description (problem / solution / changelog)

Summary

This PR fixes the malformed exec-approvals.json policy-value path from #59006.

When ~/.openclaw/exec-approvals.json contains invalid enum values such as defaults.security: "none", normalizeExecApprovals() was preserving those raw strings in memory. Downstream exec policy resolution assumes normalized values, so those invalid strings could leak into comparisons like minSecurity() / maxAsk() and produce inconsistent behavior instead of cleanly falling back to the documented defaults.

The fix is intentionally narrow:

  • validate security, ask, and askFallback while normalizing the file
  • strip invalid or malformed values to undefined
  • let the existing resolution layer fall back to built-in defaults

What Changed

  • src/infra/exec-approvals.ts
    • added a small policy sanitizer for security, ask, and askFallback
    • non-string values are treated as invalid and stripped instead of reaching the enum normalizers directly
    • kept the rest of normalizeExecApprovals() focused on structural cleanup
  • src/infra/exec-approvals-config.test.ts
    • added focused coverage for invalid defaults values, invalid agent values, non-string malformed values, and downstream fallback behavior

Scope Boundary

This PR does not change:

  • sandbox or host target selection
  • allowlist evaluation logic
  • built-in exec approval defaults
  • approval routing or channel behavior

It only ensures that malformed policy values from exec-approvals.json do not corrupt the in-memory exec approvals config.

Reproduction

  1. Set an invalid approvals policy value in ~/.openclaw/exec-approvals.json, for example:
    {
      "version": 1,
      "defaults": {
        "security": "none"
      },
      "agents": {}
    }
  2. Run exec through a path that loads the approvals file.
  3. Before this fix, the invalid string was preserved and could poison downstream policy comparisons.
  4. After this fix, the invalid value is stripped during normalization and downstream resolution falls back to the intended defaults.

Verification

  • pnpm test -- src/infra/exec-approvals-config.test.ts
  • pnpm build
  • pnpm check

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • Gateway
  • Core
  • Security

Linked Issue/PR

Addresses the malformed exec-approvals.json policy-value path in #59006.

Changed files

  • src/infra/exec-approvals-config.test.ts (modified, +104/-0)
  • src/infra/exec-approvals.ts (modified, +32/-6)

Code Example

// ~/.openclaw/exec-approvals.json
{
  "defaults": { "ask": "off", "security": "full" },
  "agents": { "*": { "ask": "off", "security": "full" } }
}
RAW_BUFFERClick to expand / collapse

Summary

The 2026.4.1 update introduced sandboxing and exec approval changes that completely broke exec for all existing single-operator setups. There was no migration guide, no warning on startup, and no way to opt out using documented config options. A full working day was lost trying to recover.

What broke

  1. Docker sandbox auto-created for all agents with no sandbox config (via agents.defaults.sandbox.mode = "all" set automatically by update)
  2. Sandbox container persists across gateway restarts via ~/.openclaw/sandbox/containers.json — removing it manually doesn't work because the gateway recreates it
  3. tools.exec.ask = "off" does nothingask and security are separate axes, but this is not documented
  4. tools.exec.security = "none" is rejected — not a valid value, but the valid values (deny, allowlist, full) are not shown in help or docs
  5. exec-approvals.json is undocumented — its location, format, purpose, and valid values are unknown to operators
  6. security: "none" in exec-approvals.json silently falls back to allowlist — no error, just broken
  7. tools.exec.host = "gateway" ignored while sandbox container exists — routing config has no effect inside a sandbox session

Impact

  • All cron exec jobs fail silently
  • Agents report "allowlist miss" or "exec denied" on every command
  • Approval popups appear that cannot be permanently dismissed
  • No amount of config changes fixes it without also destroying the sandbox container AND removing its registry entry from containers.json
  • Required 4+ separate GitHub issues and 2+ hours of debugging to partially recover

What was needed (not documented anywhere)

// ~/.openclaw/exec-approvals.json
{
  "defaults": { "ask": "off", "security": "full" },
  "agents": { "*": { "ask": "off", "security": "full" } }
}

Plus manually: docker rm -f openclaw-sbx-agent-main-* AND remove entry from ~/.openclaw/sandbox/containers.json

Request

  • Do not silently enable sandboxing on existing setups during updates
  • Document exec-approvals.json properly with all valid values
  • openclaw doctor --fix should detect broken exec approval state and offer to fix it
  • Add an operator or private mode that disables all approval friction for single-user setups
  • Ship a migration guide when security defaults change between versions

extent analysis

TL;DR

To fix the broken exec issue in single-operator setups after the 2026.4.1 update, manually remove the sandbox container and its registry entry, and configure exec-approvals.json with the correct security settings.

Guidance

  • Manually remove the sandbox container using docker rm -f openclaw-sbx-agent-main-* to prevent it from interfering with exec jobs.
  • Remove the entry from ~/.openclaw/sandbox/containers.json to prevent the gateway from recreating the sandbox container.
  • Configure exec-approvals.json with the correct security settings, such as setting "security": "full" for agents, to allow exec jobs to run without approval prompts.
  • Verify that the exec-approvals.json configuration is correct and that the sandbox container is removed to ensure that exec jobs are working as expected.

Example

// ~/.openclaw/exec-approvals.json
{
  "defaults": { "ask": "off", "security": "full" },
  "agents": { "*": { "ask": "off", "security": "full" } }
}

Notes

The provided solution assumes that the issue is caused by the automatic enabling of sandboxing and the lack of documentation for exec-approvals.json. However, it is possible that other factors may be contributing to the issue, and additional debugging may be necessary.

Recommendation

Apply the workaround by manually removing the sandbox container, configuring exec-approvals.json, and verifying that exec jobs are working as expected. This is because the update introduced significant changes to the security defaults, and a proper migration guide was not provided.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING