Exec errors in latest openclaw

[tribal escarp]

Troubleshooting OpenClaw host exec / approval behavior. I want to know if it is due to a recent update.

Issue:
Scheduled jobs are firing, but some jobs that use exec fail during host command execution.

Observed failures:

1. Earlier error:
   exec denied: allowlist miss

2. After adding host exec approval allowlist entries, the error changed, which suggests the allowlist partially helped:
   commands using ~ were treated literally in a non-shell context instead of expanding to the home directory.

3. Separate issue:
   some harmless local troubleshooting commands also hit exec approval timeout before they could run.

Patterns noticed:

• The issue seems tied to isolated/background scheduled runs using host exec.
• The jobs can reach exec, so tool availability itself does not seem to be the main problem.
• The block appears to happen at the host approval / allowlist layer.
• Multi-line heredoc commands seem more likely to trigger approval friction.
• Non-shell exec contexts do not seem to expand ~.

Questions:

1. For isolated scheduled runs, what is the exact inheritance chain for host exec permissions?
2. Is exec-approvals.json the correct current place to allow trusted recurring host commands for scheduled jobs?
3. Are approvals expected to behave differently for isolated runs vs normal chat runs?
4. Is lack of ~ expansion in non-shell exec contexts expected?
5. What is the recommended safe setup for recurring local automation jobs that need host exec without constant approval issues?

Looking for:

• the correct mental model
• the right config surface to fix it
• the recommended safe pattern for recurring trusted local commands

[gaunt oak]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[broken furnace]

Short version: what you’re seeing is mostly consistent with the current exec approval model, especially for --session isolated cron runs.

1. Inheritance chain for isolated scheduled runs (host exec)
   For a cron isolated run, the gate stack is roughly:

• Job runtime context (cron:<jobId> session, not your normal chat session)
• Tool availability / policy (--tools, tool allowlists, agent policy)
• Requested exec defaults from config (agents.list.<agent>.tools.exec.* → tools.exec.* → tool defaults)
• Per-call exec params (if the model passes security/ask/host)
• Host-local approvals policy (~/.openclaw/exec-approvals.json on the execution host: gateway or node)
• Allowlist analysis + extra hardening rules (heredoc / inline-eval rules can force approval)
• Approval routing + timeout/fallback behavior

So yes: isolated runs can reach exec, then still fail at approval/allowlist layer.

2. Is exec-approvals.json the right place?
   Yes — for trusted recurring host commands, that is the correct host-side source of truth.

But you need both layers aligned:

• OpenClaw requested policy (tools.exec.* / agent exec config)
• Host approvals policy (exec-approvals.json on gateway/node)

Docs: https://docs.openclaw.ai/tools/exec-approvals
CLI: https://docs.openclaw.ai/cli/approvals

3. Do isolated runs behave differently from normal chat runs?
   Yes, practically:

• Isolated cron is headless/background-oriented.
• If approval is required and nobody approves in time, timeout/deny is expected.
• Multi-line/heredoc commands are more likely to require explicit approval in allowlist mode (matches your pattern).

4. ~ not expanding in non-shell/enforced contexts — expected?
   Yes, in allowlist-enforced execution paths, args can be treated as literal/quoted tokens.

That means shell niceties (~, sometimes $VAR, globbing) may not behave like an interactive shell.

Safe fix: use absolute paths (/home/you/...) in recurring automation.

5. Recommended safe pattern for recurring local automation
   Best-practice setup:

• Use a dedicated cron agent (e.g. ops-cron)
• Keep commands simple/stable (avoid heredocs for recurring jobs)
• Put logic in script files; cron calls one wrapper script
• Use absolute paths + explicit workdir
• Allowlist that wrapper/binary path per agent in approvals
• For unattended jobs, use ask: off (or you’ll keep hitting timeouts)

If you want strict mode:

• security: allowlist, ask: off, narrow allowlist

If you fully trust the host and want no friction:

• security: full, ask: off in both config + approvals file

---

If you want, paste these and I can pinpoint whether this is config drift vs version behavior:

• openclaw --version
• openclaw approvals get --gateway
• (if node exec) openclaw approvals get --node <id|name|ip>
• one failing openclaw cron runs --id <jobId> --limit 20 entry

[tribal escarp]

Even my main agent, not just isolated cron sessions, are requiring approval for exec. This never happened with Opus on the last openclaw release, only with GPT 5.4 and after updating to openclaw 4.5. When I asked it to run those commands you requested it said: "Yes, I tested it. exec is still blocked, even for a trivial command (pwd)."

[broken furnace]

Yeah — this new detail is super useful. If even pwd now needs approval, that’s almost certainly policy state, not model capability.

exec gating is runtime/host policy. GPT vs Opus can change which commands get generated (heredoc, ~, etc.), but it should not change whether pwd is allowed.

Most likely after 4.5 you now have one of these active:

1. per-session /exec override persisted (ask=always or security=allowlist)
2. host approvals file tightened (~/.openclaw/exec-approvals.json)
3. approvals route present but unattended, so requests time out

---

Quick reset test (deterministic):

openclaw config get tools.exec.host

openclaw config get tools.exec.security
openclaw config get tools.exec.ask
openclaw approvals get --gateway

Then in chat, run /exec (no args) to see session-level overrides.

If you want “no prompt” baseline again:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

and align host approvals too:

openclaw approvals set --gateway --stdin <<'EOF'
{
version: 1,
defaults: {
security: "full",
ask: "off",
askFallback: "full"
}
}
EOF

---

For safer recurring automation (no approval timeouts), use:

• security=allowlist
• ask=off
• explicit allowlist entries for absolute executable paths
• wrapper scripts + absolute paths (avoid ~ and heredoc in recurring jobs)

That gives deterministic allow/deny without interactive approval stalls.

Refs:
https://docs.openclaw.ai/help/troubleshooting#exec-suddenly-asks-for-approval
https://docs.openclaw.ai/tools/exec-approvals
https://docs.openclaw.ai/cli/approvals

[tribal escarp]

Proposed fix path:

Goal:
Get back to the old “host exec just works” baseline first, then tighten later if needed.

What looks true:

• openclaw.json does not appear to have an explicit tools.exec block
• but ~/.openclaw/exec-approvals.json exists, so exec behavior is no longer on the pure default path
• trivial host exec still asks for approval, which suggests effective approval policy is still being enforced somewhere

Proposed fix:

1. Set explicit gateway exec baseline in config:

• tools.exec.host = "gateway"
• tools.exec.security = "full"
• tools.exec.ask = "off"

2. Reset ~/.openclaw/exec-approvals.json to a simple no-approval baseline:
   {
   "version": 1,
   "defaults": {
   "security": "full",
   "ask": "off",
   "askFallback": "full"
   }
   }

3. Restart gateway

4. Test trivial host exec:

• pwd

5. If that works, re-run one failing cron job

6. Separately fix cron command formatting:

• replace ~ with absolute paths

[broken furnace]

Yep — that fix path is solid. I’d do almost exactly that.
Two important tweaks so it doesn’t look “fixed” but still prompt later:

1. Clear per-agent overrides in approvals too
   If ~/.openclaw/exec-approvals.json has agents.main or agents.* with stricter values, they override defaults.
   So when resetting, make sure you also end up with either no agents block or an empty one.

2. Check session-level /exec override after restart
   A session can still carry stricter exec settings. In chat, run /exec to verify current session defaults.

---

Your baseline reset checklist (good):

• tools.exec.host = "gateway"
• tools.exec.security = "full"
• tools.exec.ask = "off"

• approvals file baseline to full/off/full
• openclaw gateway restart
• test exec: pwd
• retry one failing cron
• replace ~ with absolute paths

Exactly right.

If you want a safer “no-prompt automation” mode after baseline recovery, then tighten to:

• security: "allowlist"
• ask: "off"
• explicit allowlist entries for wrapper scripts / absolute executable paths

That avoids timeout friction in isolated/headless runs.

Docs:

https://docs.openclaw.ai/help/troubleshooting#exec-suddenly-asks-for-approval
https://docs.openclaw.ai/tools/exec-approvals
https://docs.openclaw.ai/cli/approvals

If this fixes it, please mark the solution in-thread so Answer Overflow can index it 🙌

[tribal escarp]

How unsafe is the "full" security mode? It's my own computer and mostly isolated from sensitive content.

[broken furnace]

Short answer: security="full" is high trust / high blast radius.

If combined with ask="off", it means:

• any host command the agent emits can run
• no allowlist gate
• no human checkpoint

So the risk is less about “malicious model,” more about:

• prompt injection from content it reads
• accidental bad commands
• silent data exfil (curl, scp, etc.)
• destructive ops (rm, package/system changes)

---

For your case (“my own mostly isolated machine”):

• Dedicated throwaway automation box / VM + no sensitive creds: risk is often acceptable.

• Daily driver with browser sessions, SSH keys, cloud creds: risk is not low.

---

Practical recommendation:

• For “get it working now”: full + off is fine temporarily.
• For steady-state recurring jobs: better is allowlist + ask=off (no timeout friction, but bounded commands).
• If you keep full, isolate hard:
• dedicated user (no sudo)
• separate host/VM
• minimal secrets in env/home
• tight sender allowlists

Docs: https://docs.openclaw.ai/tools/exec-approvals and https://docs.openclaw.ai/gateway/security

[tribal escarp]

What are most OpenClaw users likely running?

[broken furnace]

If you mean exec security mode: there’s no official telemetry/census published, so nobody can give a precise %.

Practical pattern I see:

1. Solo/personal setups (especially early setup):
   host=gateway, security=full, ask=off
   → least friction, fastest “it just works.”

2. Users after first incidents / prod-ish use:
   move recurring automation to allowlist (often ask=off for cron)
   → deterministic jobs, lower blast radius.

3. Shared/sensitive environments:
   strict allowlists + approvals + stronger isolation.

So your plan (“restore full/off baseline, then tighten”) is exactly how many people do it.