Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After editing ~/.openclaw/exec-approvals.json to set security: full and ask: off at both the defaults level and per-agent level (main and *), isolated cron sessions still prompt for exec approval after gateway restarts. The running gateway appears to hold stale exec policy state that doesn't match the file on disk.
Steps to reproduce
- Edit
~/.openclaw/exec-approvals.json:
- Set
defaults.security to "full"
- Set
defaults.ask to "off"
- Set
agents.main.security to "full"
- Set
agents.main.ask to "off"
- Set
agents.*.security to "full"
- Set
agents.*.ask to "off"
- Restart gateway (
openclaw gateway restart)
- Trigger an isolated cron job that uses exec (e.g., a cron with
sessionTarget: isolated)
- The cron session's exec approval prompt shows
Security: allowlist instead of full
Expected behavior
After gateway restart, all sessions (including isolated cron sessions) should read exec policy from exec-approvals.json and honor security: full / ask: off.
- Gateway restart should re-read
exec-approvals.json and apply settings to ALL session types, including isolated cron sessions
- Consider supporting an
exec.defaults key in openclaw.json for persistent config that survives updates
- If
security: full is set, heredoc execution should also be allowed without prompting
Actual behavior
- The main session (webchat) partially works — simple commands pass but heredocs still prompt regardless of
security: full
- Isolated cron sessions show
Security: allowlist in the approval prompt UI, ignoring the file on disk entirely
- The only workaround is clicking "Always allow" on each approval prompt manually
OpenClaw version
OpenClaw version: v2026.3.31
Operating system
OS: macOS 15 (arm64), Mac Studio M3 Ultra
Install method
npm global
Model
Anthropic/claude-opus-4.6
Provider / routing chain
openclaw
Additional provider/model setup details
No response
Logs, screenshots, and evidence
1. Gateway restart should re-read `exec-approvals.json` and apply settings to ALL session types, including isolated cron sessions
2. Consider supporting an `exec.defaults` key in `openclaw.json` for persistent config that survives updates
3. If `security: full` is set, heredoc execution should also be allowed without prompting
Impact and severity
Affected users/systems/channels: Any OpenClaw deployment running cron-based automation with exec commands. Specifically affects isolated cron sessions (the primary mechanism for overnight builds, content pipelines, and monitoring scripts). Gateway host exec in the main session is also partially affected (heredocs always prompt). All channels that depend on cron output are downstream casualties (Telegram notifications, content publishing, build pipelines).
Severity: Blocks workflow. Cron jobs that require exec stall silently overnight waiting for approval prompts that no human is awake to click. Builds don't ship, content doesn't generate, monitoring doesn't run. The operator has to manually re-run everything the next morning after discovering the failure. In our case, this has consumed 7+ hours of debugging across three incidents (March 17, March 31, April 1) and repeatedly broken a 20+ job overnight automation fleet.
Frequency: Always, after every gateway restart or OpenClaw update. The exec-approvals.json file on disk is consistently ignored by isolated cron sessions. The issue has reproduced on three separate OpenClaw versions (v2026.3.17, v2026.3.28, v2026.3.31). It is not intermittent — it is 100% reproducible.
Consequence: Failed overnight builds (Nemo/Nemotron build pipeline stalls), missed content generation (blog posts, social media, SEO pipelines don't fire), silent monitoring gaps (cloudflared health checks, security audits don't execute), and significant operator time spent diagnosing and re-applying the same fix after every update. There is currently no permanent fix — the only workaround is manually clicking "Always allow" on each prompt after every restart, which defeats the purpose of unattended automation.
Additional information
- This has been a recurring issue across multiple updates (first hit on v2026.3.17, again on v2026.3.28, and now v2026.3.31)
- Each OpenClaw update appears to reset or re-initialize exec state independent of the approvals JSON file
- Adding an
exec key to openclaw.json (the gateway config) was rejected with Unrecognized key: "exec" — so there's no persistent config-level way to set this
- Heredoc execution (
python3 << 'EOF') always prompts regardless of any setting, including security: full — this appears to be hardcoded in the gateway binary from the Feb 2026 security hardening commit (2b63592)
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After editing
~/.openclaw/exec-approvals.jsonto setsecurity: fullandask: offat both thedefaultslevel and per-agent level (mainand*), isolated cron sessions still prompt for exec approval after gateway restarts. The running gateway appears to hold stale exec policy state that doesn't match the file on disk.Steps to reproduce
~/.openclaw/exec-approvals.json:defaults.securityto"full"defaults.askto"off"agents.main.securityto"full"agents.main.askto"off"agents.*.securityto"full"agents.*.askto"off"openclaw gateway restart)sessionTarget: isolated)Security: allowlistinstead offullExpected behavior
After gateway restart, all sessions (including isolated cron sessions) should read exec policy from
exec-approvals.jsonand honorsecurity: full/ask: off.exec-approvals.jsonand apply settings to ALL session types, including isolated cron sessionsexec.defaultskey inopenclaw.jsonfor persistent config that survives updatessecurity: fullis set, heredoc execution should also be allowed without promptingActual behavior
security: fullSecurity: allowlistin the approval prompt UI, ignoring the file on disk entirelyOpenClaw version
OpenClaw version: v2026.3.31
Operating system
OS: macOS 15 (arm64), Mac Studio M3 Ultra
Install method
npm global
Model
Anthropic/claude-opus-4.6
Provider / routing chain
openclaw
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
Affected users/systems/channels: Any OpenClaw deployment running cron-based automation with exec commands. Specifically affects isolated cron sessions (the primary mechanism for overnight builds, content pipelines, and monitoring scripts). Gateway host exec in the main session is also partially affected (heredocs always prompt). All channels that depend on cron output are downstream casualties (Telegram notifications, content publishing, build pipelines).
Severity: Blocks workflow. Cron jobs that require exec stall silently overnight waiting for approval prompts that no human is awake to click. Builds don't ship, content doesn't generate, monitoring doesn't run. The operator has to manually re-run everything the next morning after discovering the failure. In our case, this has consumed 7+ hours of debugging across three incidents (March 17, March 31, April 1) and repeatedly broken a 20+ job overnight automation fleet.
Frequency: Always, after every gateway restart or OpenClaw update. The exec-approvals.json file on disk is consistently ignored by isolated cron sessions. The issue has reproduced on three separate OpenClaw versions (v2026.3.17, v2026.3.28, v2026.3.31). It is not intermittent — it is 100% reproducible.
Consequence: Failed overnight builds (Nemo/Nemotron build pipeline stalls), missed content generation (blog posts, social media, SEO pipelines don't fire), silent monitoring gaps (cloudflared health checks, security audits don't execute), and significant operator time spent diagnosing and re-applying the same fix after every update. There is currently no permanent fix — the only workaround is manually clicking "Always allow" on each prompt after every restart, which defeats the purpose of unattended automation.
Additional information
execkey toopenclaw.json(the gateway config) was rejected withUnrecognized key: "exec"— so there's no persistent config-level way to set thispython3 << 'EOF') always prompts regardless of any setting, includingsecurity: full— this appears to be hardcoded in the gateway binary from the Feb 2026 security hardening commit (2b63592)