Yolo | Friends of the Crustacean 🦞🤝 | Page 1

coarse sky May 10, 2026, 2:02 PM

#

OpenClaw now asks my permission to execute every command. I want to turn this behavior off. I ran the command "openclaw exec-policy preset yolo" and it update the config. OpenClaw is still asking me for permission.

manic hullBOT May 10, 2026, 2:02 PM

#

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

lost flickerBOT May 10, 2026, 2:02 PM

#

First check: what does openclaw --version show?

The likely gotcha: openclaw exec-policy preset yolo is local-only. It updates the machine where you ran it, but exec approvals are enforced on the actual execution host. If your commands run on the gateway host or a paired node, that host may still have stricter ~/.openclaw/exec-approvals.json settings.

Try inspecting the effective policy:

openclaw exec-policy show
openclaw approvals get --gateway
# if exec runs on a node:
openclaw approvals get --node <node-id-or-name>

For gateway-host “never prompt”, set both layers and restart:

#

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

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

#

For node-host exec, use --node <id|name|ip> instead of --gateway.

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

coarse sky May 10, 2026, 2:05 PM

#

Failed to parse approvals JSON: SyntaxError: JSON5: invalid end of input at 1:1

lost flickerBOT May 10, 2026, 2:05 PM

#

That error means the CLI received empty stdin. Usually the heredoc got pasted/executed in a way your shell didn’t pass it through.

Simplest fix: write a tiny file, then use --file:

cat > /tmp/openclaw-exec-approvals.json5 <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

#

openclaw approvals set --gateway --file /tmp/openclaw-exec-approvals.json5

Then verify:

openclaw approvals get --gateway

If your exec host is a node, swap the last two commands to:

openclaw approvals set --node <node-id-or-name> --file /tmp/openclaw-exec-approvals.json5
openclaw approvals get --node <node-id-or-name>

#

Docs: https://docs.openclaw.ai/cli/approvals

coarse sky May 10, 2026, 2:24 PM

#

Scope │ Requested │ Host │ Effective │ Notes │
├────────────┼────────────────────────┼───────────────────────────────────┼───────────────────────┼────────────────────┤
│ tools.exec │ security=full (tools. │ security=full (~/.openclaw/exec- │ security=full │ requested │
│ │ exec.security) │ approvals.json defaults.security) │ ask=off │ security applies; │
│ │ ask=off (tools.exec. │ ask=off (~/.openclaw/exec- │ │ requested ask │
│ │ ask) │ approvals.json defaults.ask) │ │ applies │
│ │ │ askFallback=full (~/.openclaw/ │ │ │
│ │ │ exec-approvals.json defaults. │ │ │
│ │ │ askFallback) │ │

lost flickerBOT May 10, 2026, 2:24 PM

#

That table looks correct for that scope: security=full + ask=off effective means OpenClaw’s exec approval gate should not prompt there.

So if you’re still seeing prompts, it’s probably one of these:

Different execution host — you checked local/gateway, but the run is going to a node. Check the actual route:

openclaw config get tools.exec.host
openclaw approvals get --gateway
openclaw approvals get --node <node-id-or-name>

Old running session/gateway state — restart and start a fresh chat/session:
```
openclaw gateway restart
```
Not OpenClaw exec approvals — some CLI backends/tools have their own permission modes. The exact prompt text matters here. If it says /approve ..., that’s OpenClaw. If it says something like a Claude/Codex permission prompt, that’s the backend layer.

#

Also please paste:

openclaw --version
openclaw status --all

(tokens are redacted in status output). That’ll show whether this is gateway/node/session mismatch or a backend permission prompt.

coarse sky May 10, 2026, 2:29 PM

#

That's odd. That's an old version. OpenClaw 2026.5.2-beta.1 (d7537e0) Let me update.

lost flickerBOT May 10, 2026, 2:29 PM

#

Yep, good catch — update first. A lot changed around exec approval UX/policy since then.

After updating, restart the gateway and re-check:

openclaw gateway restart
openclaw --version
openclaw approvals get --gateway

If it still prompts after that, paste the exact approval prompt text — that’ll tell us whether it’s OpenClaw’s /approve gate or an underlying CLI backend permission prompt.

coarse sky May 10, 2026, 2:31 PM

#

ranger-ai@claw-host:~$ sudo openclaw update
Updating OpenClaw...

Stopping managed gateway service before package update...
Stopped systemd service: openclaw-gateway.service
│
◇ ✓ Updating via package manager (38.59s)
│
◇ ✓ Running doctor checks (5.29s)

Update Result: OK
Root: /usr/lib/node_modules/openclaw
Before: 2026.5.7
After: 2026.5.7

Total time: 45.31s

Updating plugins...
npm plugins: 0 updated, 1 unchanged.

Restarting service...

lost flickerBOT May 10, 2026, 2:31 PM

#

Interesting — that update log says the sudo/system install was already 2026.5.7 before and after.

Since you previously saw 2026.5.2-beta.1, this smells like a PATH / multiple installs mismatch: your normal shell is running one OpenClaw, while sudo openclaw updated another at /usr/lib/node_modules/openclaw.

Can you compare these?

which openclaw
openclaw --version
sudo which openclaw
sudo openclaw --version
openclaw gateway status

If which openclaw and sudo which openclaw differ, update/reinstall the one your gateway actually uses. openclaw gateway status should also show the service/runtime path, which is the important one.

coarse sky May 10, 2026, 2:32 PM

#

ranger-ai@claw-host:~$ which openclaw
openclaw --version
sudo which openclaw
sudo openclaw --version
openclaw gateway status
/home/ranger-ai/.npm-global/bin/openclaw
OpenClaw 2026.5.2-beta.1 (d7537e0)
/usr/bin/openclaw
OpenClaw 2026.5.7 (eeef486)

🦞 OpenClaw 2026.5.2-beta.1 (d7537e0) — I keep secrets like a vault... unless you print them in debug logs again.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-05-10.log
Command: /usr/bin/node /home/ranger-ai/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 33291, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

lost flickerBOT May 10, 2026, 2:32 PM

#

Yep, nailed it: you have two installs, and the running gateway is still using the old user install:

/home/ranger-ai/.npm-global/bin/openclaw                  # 2026.5.2-beta.1
/usr/bin/openclaw                                         # 2026.5.7
Gateway command: /usr/bin/node /home/ranger-ai/.npm-global/lib/node_modules/openclaw/dist/index.js ...

So sudo openclaw update updated /usr/bin/openclaw, but your user systemd service is launching the stale ~/.npm-global copy.

Fix option A — update the user install the gateway actually uses:

npm install -g openclaw@latest --prefix ~/.npm-global
openclaw --version
openclaw gateway restart

#

openclaw gateway status

Fix option B — make the service use the system install instead: uninstall/reinstall the user gateway service using the newer binary:

/usr/bin/openclaw gateway uninstall
/usr/bin/openclaw gateway install --force
/usr/bin/openclaw gateway restart
openclaw gateway status

I’d do option A first because it matches your current service path and is less likely to disturb config. Afterward, openclaw gateway status should no longer show 2026.5.2-beta.1.

coarse sky May 10, 2026, 2:53 PM

#

The version is correct but it is still asking for approvals

lost flickerBOT May 10, 2026, 2:53 PM

#

Okay — if the gateway version is now correct and approvals get says effective security=full ask=off, then I want to separate two cases:

A) OpenClaw exec approval — the message says /approve <id> ... or shows an OpenClaw approval card.

B) Backend permission prompt — Claude/Codex/another CLI is asking for permission inside its own process. That is separate from OpenClaw exec approvals.

Please paste the exact approval prompt text/screenshot if you can. Also run these and paste the output:

openclaw --version
openclaw gateway status
openclaw approvals get --gateway
openclaw config get tools.exec.host
openclaw config get tools.exec.security
openclaw config get tools.exec.ask
openclaw config get agents.defaults.cliBackends

#

One quick thing to try in the current chat/session too:

/exec host=gateway security=full ask=off

If that stops it, the persistent config is fine but the active session had stricter exec settings cached.

coarse sky May 10, 2026, 2:54 PM

#

OpenClaw 2026.5.7 (eeef486)
Config warnings:

plugins.entries.discord: plugin not installed: discord — install the official external plugin with: openclaw plugins install @openclaw/discord
plugins.allow: plugin not installed: discord — install the official external plugin with: openclaw plugins install @openclaw/discord

🦞 OpenClaw 2026.5.7 (eeef486) — Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

│
◇
Service: systemd user (enabled)
File logs: /tmp/openclaw/openclaw-2026-05-10.log
Command: /usr/bin/node /home/ranger-ai/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 35748, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
Config warnings:

plugins.entries.discord: plugin not installed: discord — install the official external plugin with: openclaw plugins install @openclaw/discord
plugins.allow: plugin not installed: discord — install the official external plugin with: openclaw plugins install @openclaw/discord

lost flickerBOT May 10, 2026, 2:55 PM

#

Version is fixed now ✅

This output doesn’t include the key bits yet though — it only shows the gateway is running 2026.5.7. Please run these exact commands too:

openclaw approvals get --gateway
openclaw config get tools.exec.host
openclaw config get tools.exec.security
openclaw config get tools.exec.ask
openclaw config get agents.defaults.cliBackends

And most importantly: paste the exact approval prompt text you’re seeing.

If the prompt contains /approve <id>, it’s OpenClaw exec approvals and we’ll chase policy/session/host routing.

If it’s a terminal-style prompt from Claude/Codex/etc, then OpenClaw exec policy is already bypassed and the remaining approval is coming from the CLI backend’s own permission mode. Different fix.

coarse sky May 10, 2026, 2:55 PM

#

🦞 OpenClaw 2026.5.7 (eeef486) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

│
◇ Config warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.discord: plugin not installed: discord — install the official external │
│ plugin with: openclaw plugins install @openclaw/discord │
│ - plugins.allow: plugin not installed: discord — install the official external plugin │
│ with: openclaw plugins install @openclaw/discord │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇
│
◇

#

Approvals
┌───────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Field │ Value │
├───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Target │ gateway │
│ Path │ ~/.openclaw/exec-approvals.json │
│ Exists │ yes │
│ Hash │ 033dbc806f5d6605ab9566f098a3195fb6a0e5ae2b1f2877b54e5a91e57ed113 │
│ Version │ 1 │
│ Socket │ ~/.openclaw/exec-approvals.sock │
│ Defaults │ security=full, ask=off, askFallback=full │
│ Agents │ 1 │
│ Allowlist │ 2 │
└───────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────┘

lost flickerBOT May 10, 2026, 2:56 PM

#

That looks like the CLI header/warnings, but not the actual outputs from the config commands — maybe the command is hanging or the output got cut off after the warnings.

Run them one at a time with --json where possible:

openclaw approvals get --gateway --json
openclaw config get tools.exec.host --json
openclaw config get tools.exec.security --json
openclaw config get tools.exec.ask --json
openclaw config get agents.defaults.cliBackends --json

Also: those Discord plugin warnings are unrelated to exec approvals, just noisy config warnings.

The missing clue is still the actual approval prompt. Please paste the message/card that asks for approval — especially whether it includes /approve <id> or if it’s a Claude/Codex terminal prompt.

coarse sky May 10, 2026, 2:56 PM

#

Effective Policy
┌────────────┬────────────────────────┬───────────────────────────────────┬───────────────────────┬────────────────────┐
│ Scope │ Requested │ Host │ Effective │ Notes │
├────────────┼────────────────────────┼───────────────────────────────────┼───────────────────────┼────────────────────┤
│ tools.exec │ security=full (tools. │ security=full (~/.openclaw/exec- │ security=full │ requested │
│ │ exec.security) │ approvals.json defaults.security) │ ask=off │ security applies; │
│ │ ask=off (tools.exec. │ ask=off (~/.openclaw/exec- │ │ requested ask │
│ │ ask) │ approvals.json defaults.ask) │ │ applies │
│ │ │ askFallback=full (~/.openclaw/ │ │ │
│ │ │ exec-approvals.json defaults. │ │ │
│ │ │ askFallback) │ │ │
└────────────┴────────────────────────┴───────────────────────────────────┴───────────────────────┴────────────────────┘

lost flickerBOT May 10, 2026, 2:56 PM

#

Aha — Defaults are YOLO, but this line matters:

Agents    1
Allowlist 2

That means you still have an agent-specific approvals section in ~/.openclaw/exec-approvals.json. If that agent section says ask=always or security=allowlist, it can override the defaults and keep prompting.

Since you want full YOLO, the clean reset is to replace the approvals file with defaults only:

cat > /tmp/openclaw-exec-approvals.json5 <<'EOF'
{
  version: 1,
  defaults: {

#

    security: "full",
    ask: "off",
    askFallback: "full"
  },
  agents: {}
}
EOF

openclaw approvals set --gateway --file /tmp/openclaw-exec-approvals.json5
openclaw gateway restart
openclaw approvals get --gateway

After that, Agents should be 0.

If it still asks after Agents 0, then it’s almost certainly not OpenClaw exec approvals — it’s a backend/tool prompt. In that case paste the exact prompt text and we’ll chase that layer.

#

That effective policy confirms OpenClaw exec approvals are off for gateway exec:

Effective: security=full, ask=off

So if you’re still being asked, it’s almost certainly not this exec approval layer.

Next thing I need is the exact prompt/card. Please paste the text of the thing asking for permission.

Quick distinction:

If it says /approve <id> or “Exec approval” → OpenClaw approval forwarding/session mismatch.
If it’s inside a coding agent/CLI and says approve command, allow command, sandbox, permission mode, etc. → that’s the backend’s own permission system, not openclaw approvals.

Also check current session overrides by sending this in the same chat where it prompts:

#

/status

and try once:

/exec host=gateway security=full ask=off
/elevated full

If /elevated full stops the prompt, we’re still dealing with OpenClaw session/tool policy. If it doesn’t, it’s backend-level.

coarse sky May 10, 2026, 2:58 PM

#

Effective Policy
┌────────────┬────────────────────────┬───────────────────────────────────┬───────────────────────┬────────────────────┐
│ Scope │ Requested │ Host │ Effective │ Notes │
├────────────┼────────────────────────┼───────────────────────────────────┼───────────────────────┼────────────────────┤
│ tools.exec │ security=full (tools. │ security=full (~/.openclaw/exec- │ security=full │ requested │
│ │ exec.security) │ approvals.json defaults.security) │ ask=off │ security applies; │
│ │ ask=off (tools.exec. │ ask=off (~/.openclaw/exec- │ │ requested ask │
│ │ ask) │ approvals.json defaults.ask) │ │ applies │
│ │ │ askFallback=full (~/.openclaw/ │ │ │
│ │ │ exec-approvals.json defaults. │ │ │
│ │ │ askFallback) │ │ │
└────────────┴────────────────────────┴───────────────────────────────────┴───────────────────────┴────────────────────┘

lost flickerBOT May 10, 2026, 2:58 PM

#

Yep — that table is the important confirmation: gateway exec policy is YOLO now.

At this point I’m blocked without seeing the actual approval request. The policy table isn’t the prompt; it only proves the gateway exec approval layer should not be prompting.

Please paste/screenshot the message that asks for permission. Specifically, does it include something like:

/approve <id> allow-once

If yes, it’s still OpenClaw approval forwarding/session/host routing. If no, it’s likely the underlying CLI backend’s own approval system.

One useful command to run in the same chat/session that prompts:

/status

#

And one test:

/elevated full

If /elevated full stops it, we’re still in OpenClaw policy land. If it doesn’t, we’re chasing a backend permission prompt.

coarse sky May 10, 2026, 2:58 PM

#

Approvals
┌───────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Field │ Value │
├───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Target │ gateway │
│ Path │ ~/.openclaw/exec-approvals.json │
│ Exists │ yes │
│ Hash │ de11d0c3312bb7275cea21023e2fc150368ce2abcee39c9157d46ea88b66731a │
│ Version │ 1 │
│ Socket │ ~/.openclaw/exec-approvals.sock │
│ Defaults │ security=full, ask=off, askFallback=full │
│ Agents │ 0 │
│ Allowlist │ 0 │
└───────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────┘

lost flickerBOT May 10, 2026, 2:59 PM

#

Perfect — gateway approvals are now fully clean:

Defaults: security=full, ask=off, askFallback=full
Agents: 0
Allowlist: 0

So the host approval file is not the thing prompting anymore.

Do these two final checks:

In the same chat/session where it prompts, send:

/exec host=gateway security=full ask=off

#

Then try the command again.

If it still asks, paste the actual approval request text/card. Not the policy table — the message that asks you to approve. The wording will tell us which layer it is.

If it contains /approve <id>, we’ll look for session/approval-forwarding weirdness. If it’s a Claude/Codex-style terminal permission prompt, that’s a separate backend permission mode and openclaw approvals won’t affect it.

coarse sky May 10, 2026, 3:00 PM

#

/approve 6eecf3c1 allow-once

#

I think Krill died

lost flickerBOT May 10, 2026, 3:02 PM

#

not dead, just briefly trapped in the approval-policy lobster maze 🦞

Good news: your latest output shows gateway exec approvals are actually off now (Agents 0, ask=off). If you still see a permission prompt, paste the actual prompt text/card next — that’ll tell us whether it’s OpenClaw /approve forwarding or a separate Claude/Codex backend permission prompt.

coarse sky May 10, 2026, 3:03 PM

#

/approve 6eecf3c1 allow-once

#

"/approve 6eecf3c1 allow-once"

lost flickerBOT May 10, 2026, 3:03 PM

#

That confirms it is an OpenClaw /approve prompt — but one important wrinkle: that approval id may be an old pending request created before you fixed the policy. Changing ask=off won’t retroactively cancel already-created approval requests.

Do this:

openclaw gateway restart

Then start a fresh/new request and see if it creates a new /approve <id>.

If it does, grab the surrounding log line for the new id:

grep -R "6eecf3c1" /tmp/openclaw ~/.openclaw/logs 2>/dev/null | tail -20

Replace 6eecf3c1 with the new id if it changes.

#

Also: if the approval message says anything about a plugin/action rather than exec, it may be a plugin approval, not exec approvals. /approve is shared for both, so the prompt text matters.

coarse sky May 10, 2026, 3:03 PM

#

❌ Failed to submit approval: unknown or expired approval id

lost flickerBOT May 10, 2026, 3:04 PM

#

That’s actually a good sign: unknown or expired approval id means 6eecf3c1 is stale — not an active approval anymore.

So now the real test is: after the restart + cleaned policy, does a new request produce a new /approve <id>?

Please try a fresh simple exec request, like asking OpenClaw:

run pwd

If no approval appears: fixed ✅

If a new /approve ... appears, paste the full approval message/card text. At that point it’s either:

a non-gateway target, like node exec, or
a plugin approval using the same /approve command path, not exec approvals.

coarse sky May 10, 2026, 3:04 PM

#

That was after I made up a code like you asked

lost flickerBOT May 10, 2026, 3:04 PM

#

Ah — my bad, I misunderstood. Thanks for catching that.

If you invented 6eecf3c1, then the “unknown/expired” result doesn’t tell us anything except that made-up IDs are rejected.

Current known state:

Gateway version is current ✅
Gateway exec approvals file is YOLO ✅
Effective gateway policy is security=full ask=off ✅

So the next useful step is only this: trigger the thing that asks for approval again, then paste the real full approval message it sends. Don’t invent an id — I need the actual text/card so we can tell whether it’s exec, plugin, node-host, or backend permissions.

If you want a clean test, ask OpenClaw in that same session:

run pwd

#

If that prompts, paste that exact prompt.

coarse sky May 10, 2026, 3:05 PM

#

ranger-ai@claw-host:~$ grep -R "6eecf3c1" /tmp/openclaw ~/.openclaw/logs 2>/dev/null | tail -20
/tmp/openclaw/openclaw-2026-05-10.log:{"0":"exec approval followup dispatch failed (id=6eecf3c1-6b21-456b-828e-57b2ec8de6b8): Session followup failed: gateway closed (1006 abnormal closure (no close frame)): no close reason\nGateway target: ws://127.0.0.1:18789\nSource: local loopback\nConfig: /home/ranger-ai/.openclaw/openclaw.json\nBind: loopback\n\nPossible causes:\n- Gateway not yet ready to accept connections (retry after a moment)\n- TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)\n- Gateway crashed or was terminated unexpectedly\nRun openclaw doctor for diagnostics.","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-05-10T14:58:14.423Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/ranger-ai/.npm-global/lib/node_modules/openclaw/dist/logger-DksTYIAF.js:23:34","fileName":"logger-DksTYIAF.js","fileNameWithLine":"logger-DksTYIAF.js:23","fileColumn":"34","fileLine":"23","filePath":".npm-global/lib/node_modules/openclaw/dist/logger-DksTYIAF.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/logger-DksTYIAF.js:23","method":"logWithSubsystem"}},"time":"2026-05-10T14:58:14.424+00:00","hostname":"claw-host","message":"exec approval followup dispatch failed (id=6eecf3c1-6b21-456b-828e-57b2ec8de6b8): Session followup failed: gateway closed (1006 abnormal closure (no close frame)): no close reason\nGateway target: ws://127.0.0.1:18789\nSource: local loopback\nConfig: /home/ranger-ai/.openclaw/openclaw.json\nBind: loopback\n\nPossible causes:\n- Gateway not yet ready to accept connections (retry after a moment)\n- TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)\n- Gateway crashed or was terminated unexpectedly\nRun openclaw doctor for diagnostics.","traceId":"326c398a682f9b7866b29b5985529ec5","spanId":"82051b7c280f2f82

lost flickerBOT May 10, 2026, 3:05 PM

#

Okay, that was a real id — sorry for the confusion. The log says the approval finished, but OpenClaw failed to deliver the follow-up because the gateway connection closed:

exec approval followup dispatch failed ... gateway closed (1006 abnormal closure)

That doesn’t prove approvals are still enabled now; it proves there was an approval request around 14:58, likely before/during the update/restart/config cleanup.

Next best check: trigger a fresh request now and see if a new approval id is created. If yes, grab the surrounding logs for that new id plus creation context:

grep -R "exec approval" /tmp/openclaw ~/.openclaw/logs 2>/dev/null | tail -80

Also run doctor since the gateway had an abnormal close:

#

openclaw doctor

If a fresh run pwd no longer asks, you’re fixed and that old log was just stale fallout from the restart/update.

coarse sky May 10, 2026, 5:03 PM

#

Solved

lost flickerBOT May 10, 2026, 5:03 PM

#

Nice, glad it’s sorted 🎉

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person who hits the same approvals maze.

#Yolo