#completely disable allow commands

1 messages · Page 1 of 1 (latest)

inner hillBOT
shell axleBOT
#

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

inner hillBOT
paper scarabBOT
#

Let me verify where the current docs put the approvals stuff, then I’ll give you the exact switch.

#

First, what does openclaw --version print?

If you just want the old “stop asking me allow once / allow always” behavior back, the easiest fix on current builds is:

openclaw exec-policy preset yolo

That’s the local shortcut for “no exec approval prompts”.

If you only want it for the current session, use:

/exec security=full ask=off

or, break-glass style:

#

You found it, the global policy is wide open now. The remaining prompts are coming from per-agent overrides, so I’m checking the exact key/command to clear those cleanly.

#

Yep, that output shows the problem.

preset yolo fixed the global default, but main and mathou still have per-agent exec overrides. Those are what’s forcing allowlist + on-miss.

Run this first:

openclaw config get agents.list --json

Find the indexes for main and mathou, then unset their exec overrides, for example:

openclaw config unset agents.list[0].tools.exec
openclaw config unset agents.list[1].tools.exec
openclaw gateway restart
#

If you want to keep other per-agent exec settings and only remove the approval bits, unset just these instead:

openclaw config unset agents.list[0].tools.exec.security
openclaw config unset agents.list[0].tools.exec.ask
openclaw config unset agents.list[1].tools.exec.security
openclaw config unset agents.list[1].tools.exec.ask
openclaw gateway restart

Then re-check:

openclaw exec-policy show

You want it to stop showing:

#

Nice, that policy is now fully open. I’m just checking one thing before I tell you the last step: whether the remaining buttons could be coming from ACP permissions instead of exec approvals.

#

That output looks good now.

For exec approvals, you’re already in the old no-prompt mode:

  • tools.exec → security=full, ask=off
  • agent:mathou → security=full, ask=off

So you do not need to keep tweaking exec-policy.

If you’re still seeing allow once / allow always, it’s usually one of these:

  1. Old/stale pending approval messages
    Those won’t retroactively disappear.

  2. This chat session has an old /exec session override
    In the same thread, run:

# 
   /exec security=full ask=off

Or just start a fresh thread/session.

  1. It’s an ACP session, not exec approvals
    ACP permissions are separate. If you’re using /acp spawn / Codex / Claude Code / Cursor etc, use:
    /acp permissions approve-all
    Docs: https://docs.openclaw.ai/tools/acp-agents#permission-configuration

So, short version: your exec policy is fixed. If prompts remain, try /exec security=full ask=off in the thread you’re using. If they’re ACP prompts, use /acp permissions approve-all.

If you paste the exact prompt/card you still see, I can tell you which of the two it is immediately.

fierce spire
#

my skills access vanished?

paper scarabBOT
#

I’m checking the skills docs so I don’t guess. The likely causes are skills allowlisting, agent-specific skill overrides, or the skill scan path not loading.

#

Yeah, possibly, but that wouldn’t be from exec-policy itself.

Fastest check:

openclaw skills list --eligible
openclaw skills check --json
openclaw config get agents.defaults.skills --json
openclaw config get agents.list --json

Most common reasons skills “vanish”:

  • agent skill allowlist got set
    agents.defaults.skills or agents.list[].skills hides anything not listed.

  • you switched agent/workspace

#

<workspace>/skills is per-workspace/per-agent.
Shared skills for all agents should live in ~/.openclaw/skills.

  • the skill failed gating
    Missing bin/env/config will make it ineligible. openclaw skills check --json shows exactly why.

  • current session snapshot is stale
    Skills are snapshotted at session start, so try a fresh thread/session after changes.

Docs:

If you paste the output of openclaw skills list --eligible and openclaw skills check --json, I can tell you exactly what disappeared and why.

fierce spire
#

can't paste, too long, but gog is listed but claw says its not exposed to runtime. • le skill gog existe bien dans ton install
• mais moi ici, je n’ai accès qu’à :
• exec
• memory_search
• memory_get

paper scarabBOT
#

That sounds like a different issue, not missing skill files. I’m checking the exact rule for when a skill is installed but the runtime still only exposes exec + memory tools.

#

Ah, that part is probably normal.

gog is a skill, not a runtime tool.

So this can be true at the same time:

  • gog is installed and eligible
  • the runtime tool list only shows exec, memory_search, memory_get

That’s because the gog skill teaches the agent to use exec to run the gog CLI. It will not show up as a separate tool named gog.

So if openclaw skills list --eligible includes gog, the next likely issue is just session snapshotting. Skills are snapshotted when the session starts.

Try:

  1. openclaw skills info gog
  2. start a fresh thread/session
#

I found the culprit. Your agents are hard-allowlisting only four tools, so I’m checking the gog skill instructions to see whether that’s actually enough or whether you also need to widen tool policy.

#

Not quite, your tool allowlist is actually fine for gog.

gog is a skill, and it runs via exec.
You already allow:

  • exec
  • memory_search
  • memory_get
  • message

So tools.allow is not the blocker here.

What to check next is the skill allowlist, not the tool allowlist:

openclaw config get agents.defaults.skills --json
# 
openclaw config get agents.list[0].skills --json
openclaw config get agents.list[1].skills --json

If any of those are set and gog is missing, that’s why the agent won’t use it.

If you want skills unrestricted again, unset them:

openclaw config unset agents.defaults.skills
openclaw config unset agents.list[0].skills
openclaw config unset agents.list[1].skills
openclaw gateway restart

Then start a fresh thread/session, because skills are snapshotted at session start.

#

So the key point is:

  • tools = what the runtime can call
  • skills = prompt instructions that tell it how to use tools
  • gog should not appear as a tool, only as a skill

If you want, send just the output of those 3 ...skills --json lines, that’ll be short enough and should pinpoint it.

fierce spire
#

sylv@ratpi4:~ $ openclaw config get agents.defaults.skills --json
Config path not found: agents.defaults.skills
sylv@ratpi4:~ $ openclaw config get agents.list[0].skills --json
Config path not found: agents.list[0].skills
sylv@ratpi4:~ $

paper scarabBOT
#

Perfect, that rules out skill allowlists.

So at this point, the remaining likely causes are:

  1. wrong workspace / wrong agent
  2. stale session snapshot

Important bit: gog still will not show up as a tool.
That part is expected. It uses exec.

What jumps out from your config is that you have a separate agent workspace here:

/home/sylv/.openclaw/workspace-mathou

If gog was installed in one workspace only, the other agent won’t see it.

#

Quick check for the mathou workspace:

cd /home/sylv/.openclaw/workspace-mathou
openclaw skills info gog

If that fails there, but works in your main workspace, that’s the problem.

Best fix if you want both agents to have it:

  • put/install gog in ~/.openclaw/skills (shared to all agents)
  • then start a fresh thread/session

So the summary is:

  • not blocked by tools.allow
  • not blocked by agents.*.skills