Approval gate issues | Friends of the Crustacean 🦞🤝 | Page 1

sinful ravine Apr 16, 2026, 11:40 PM

#

"approvals": {
"exec": {
"mode": "both",
"agentFilter": []
}
},
"env": {
"shellEnv": {
"enabled": true
}
}
is this proper way to give all sessions and acp agent unlimited permission?

naive wraithBOT Apr 16, 2026, 11:40 PM

#

unborn spruceBOT Apr 16, 2026, 11:40 PM

#

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

stark wingBOT Apr 16, 2026, 11:42 PM

#

Just checking the docs and source so I don’t guess the config keys.

#

I’ve got the docs. I’m checking one subtle bit now: whether agentFilter: [] means “all agents” or “none”, because that changes the answer.

#

Short answer, no.

That snippet does not give unlimited permissions.

approvals.exec only controls where approval prompts are forwarded, not whether exec is allowed.
With enabled omitted, that forwarding is off anyway.
env.shellEnv.enabled: true only imports missing env vars from your login shell.

If you want never-prompt / YOLO host exec for normal sessions, you need both:

OpenClaw exec policy

{
  tools: {
    exec: {
      host: "gateway", // optional, if you want host exec by default

#

      security: "full",
      ask: "off",
    },
  },
}

Host approvals file

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

#

    askFallback: "full"
  }
}
EOF

For ACP/acpx agents, that is separate again. You also want:

openclaw config set plugins.entries.acpx.config.permissionMode approve-all

Then restart the gateway.

A couple small details:

#

agentFilter: [] currently behaves like “all agents”, but I’d omit it for clarity.
If you only wanted approval prompts forwarded to chat, you’d need approvals.exec.enabled: true, but that still does not grant permission.

Useful docs:

If you paste openclaw --version, I can give you the exact minimal config for your setup.

sinful ravine Apr 16, 2026, 11:47 PM

#

OpenClaw 2026.4.15 (041266a)
yeah i want yolo mode

stark wingBOT Apr 16, 2026, 11:48 PM

#

Yep, for 2026.4.15, if you want real YOLO mode, use the actual YOLO knobs, not that snippet.

Do this instead:

openclaw exec-policy preset yolo
openclaw config set plugins.entries.acpx.config.permissionMode approve-all
openclaw gateway restart

What that does:

openclaw exec-policy preset yolo
- sets local tools.exec.host/security/ask
- sets local ~/.openclaw/exec-approvals.json
permissionMode approve-all
- makes ACP/acpx sessions auto-approve writes + exec too

#

Your snippet is the wrong layer:

approvals.exec = only approval prompt forwarding/routing
env.shellEnv.enabled = only imports env vars from your shell

So it won’t give unlimited permissions.

Two caveats:

exec-policy preset yolo is local-only
- if exec runs on a separate node host, that node needs its own approvals config too
This is basically full-admin / never-prompt mode
- any session on that host can run host exec freely, so only do this on a box you trust

If you want, I can also give you the manual JSON5 config equivalent of preset yolo. Docs: https://docs.openclaw.ai/tools/exec-approvals and https://docs.openclaw.ai/tools/acp-agents#permission-configuration

sinful ravine Apr 16, 2026, 11:52 PM

#

non@debian:~/.openclaw$ openclaw gopenclaw exec-policy preset yolo
openclaw config set plugins.entries.acpx.config.permissionMode approve-all
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present
01:52:05 [plugins] mattermost: registered slash command callback at /api/channels/mattermost/command
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present
[openclaw] Failed to start CLI: Error: The openclaw gopenclaw command is unavailable because plugins.allow excludes "gopenclaw". Add "gopenclaw" to plugins.allow if you want that bundled plugin CLI surface.
at runCli (file:///home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/run-main-BBeVm29G.js:458:45)
anon@debian:~/.openclaw$ openclaw exec-policy preset yolo

stark wingBOT Apr 16, 2026, 11:53 PM

#

You’ve just got a typo there, the failure is from the extra gopenclaw.

Use these as three separate commands:

openclaw exec-policy preset yolo
openclaw config set plugins.entries.acpx.config.permissionMode approve-all
openclaw gateway restart

A few notes:

openclaw gopenclaw exec-policy ... is wrong, that stray gopenclaw triggered the plugin error
the amazon-bedrock warning is unrelated
the Mattermost line is just startup noise, also unrelated

If you want to verify after:

#

openclaw exec-policy show
openclaw config get plugins.entries.acpx.config.permissionMode

If openclaw exec-policy preset yolo prints anything unexpected, paste that output and I’ll check it.

sinful ravine Apr 17, 2026, 12:12 AM

#

Select plugin to configure
│ @openclaw/memory-core
│
◆ Dreaming Frequency — Optional cron cadence for the full dreaming sweep
(light, REM, then deep).
│ 0 3 * * *
what can i set here?

stark wingBOT Apr 17, 2026, 12:13 AM

#

Let me check the exact config text so I don’t guess the cron format.

#

That field is just a cron expression for how often the full dreaming sweep runs.

Safest option: keep the default

0 3 * * *

That means every day at 03:00.

Some useful examples:

0 3 * * * → daily at 3 AM
0 */6 * * * → every 6 hours
0 0 * * 0 → every Sunday at midnight
30 2 * * 1-5 → weekdays at 2:30 AM

Cron order is:

#

minute hour day-of-month month day-of-week

A couple notes:

If you don’t care, just leave 0 3 * * *
If you want local-time scheduling, set dreaming.timezone separately
If you want dreaming off, disable dreaming.enabled instead, not this field

I’d stick with daily or every 6 hours. No need to run it super aggressively.

Docs:

sinful ravine Apr 17, 2026, 12:14 AM

#

Non-Interactive Permission Policy — Policy when interactive
│ permission prompts are unavailable.
│ ● deny
│ ○ fail how to approve all

stark wingBOT Apr 17, 2026, 12:15 AM

#

There isn’t an “approve all” option for that field.

That setting only controls what happens if a prompt would be needed and there’s no interactive TTY:

deny = silently deny
fail = error out loudly

If you want full YOLO / auto-approve, the setting you want is:

openclaw config set plugins.entries.acpx.config.permissionMode approve-all

For Non-Interactive Permission Policy, I’d pick:

fail if you want unexpected permission issues to be obvious
deny if you want quieter graceful degradation

#

With permissionMode=approve-all, that non-interactive fallback should mostly stop mattering, because writes/exec won’t ask in the first place.

Docs: https://docs.openclaw.ai/tools/acp-agents#permission-configuration

sinful ravine Apr 17, 2026, 12:17 AM

#

Memory Model — Provider/model used for the blocking memory sub-agent.
│ _
how does active memory work?

stark wingBOT Apr 17, 2026, 12:18 AM

#

I’m checking the memory docs so I can explain what that field actually controls.

#

That field is for Active Memory, which is separate from the normal memory index/search settings.

How it works:

Before the main agent replies, OpenClaw can run a small blocking memory sub-agent
That sub-agent looks at the latest message, or recent convo depending on config
It queries your memory backend
If it finds something relevant, it injects a short hidden memory summary into the main prompt
Then the normal reply is generated with that memory in mind

So:

agents.defaults.memorySearch.* = the memory backend / search / embeddings side
plugins.entries.active-memory.config.model = the LLM used by that pre-reply memory sub-agent

For the Memory Model field specifically:

#

if you leave it blank, active memory will try to inherit the current session model first
you can set a specific provider/model if you want active memory to always use a separate model
there’s also a modelFallback if you want a backup

If you’re unsure, I’d leave it blank for now and tune later.

Docs:

If you want, I can also tell you the safest starter settings for active memory so it stays fast and doesn’t get in the way.

sinful ravine Apr 17, 2026, 12:21 AM

#

good syntax for codex auth gpt 5.4 mini?

stark wingBOT Apr 17, 2026, 12:21 AM

#

I’m checking the docs/source for the exact provider/model syntax so I don’t hand you a made-up string.

#

If you mean OpenAI Codex OAuth auth, the safest explicit form is:

openai-codex/gpt-5.4-mini

Examples:

session command:
```
/model openai-codex/gpt-5.4-mini
```
config:
```
{
```

#

    agents: {
      defaults: {
        model: {
          primary: "openai-codex/gpt-5.4-mini"
        }
      }
    }
  }

Important distinction:

Codex OAuth → openai-codex/gpt-5.4-mini
normal OpenAI API key → openai/gpt-5.4-mini

If you want, run:

#

openclaw models status

That’ll confirm whether your Codex auth is actually resolving. Docs: https://docs.openclaw.ai/concepts/models

sinful ravine Apr 17, 2026, 12:27 AM

#

Select sections to configure
│ Plugins
│
◇ Select plugin to configure
│ Memory Wiki
│
◇ Vault Mode — Choose isolated, bridge, or unsafe-local mode for the
│ wiki vault.
│ isolated
│
◆ Vault Path — Filesystem path for the wiki vault root.
│ _
how to set up memory wiki?

stark wingBOT Apr 17, 2026, 12:29 AM

#

I’m pulling the Memory Wiki docs so I can give you the recommended mode and what to put in Vault Path.

#

Easiest safe setup:

Vault Mode: keep isolated
Vault Path: set a real folder, for example
```
~/.openclaw/wiki/main
```

Finish the wizard, then run:

openclaw wiki init
openclaw wiki status
openclaw wiki doctor

What the modes mean:

isolated: best default, own wiki vault, no dependency on memory-core internals

#

bridge: pulls in public memory artifacts from the active memory plugin
unsafe-local: same-machine escape hatch for private local paths, higher risk, only use if you really mean it

So if you’re just getting started, I’d use:

vaultMode = isolated
vault.path = ~/.openclaw/wiki/main

A couple gotchas:

memory-wiki does not replace active memory, it’s the durable wiki/knowledge vault layer
if you want Obsidian, point vault.path at that vault root and use the Obsidian-friendly render settings
if you choose bridge later, you’ll usually run:
```
openclaw wiki bridge import
```

#

Docs:

If you want, I can give you a good starter config block for either:

plain local wiki, or
Obsidian-backed wiki.

sinful ravine Apr 17, 2026, 12:40 AM

#

Active Memory Recall — Globally enable or pause Active Memory
│ recall while keeping the plugin command available how to set up active memory,

stark wingBOT Apr 17, 2026, 12:40 AM

#

Safest starter setup for Active Memory:

Active Memory Recall: on
Target Agents: main
Allowed Chat Types: direct
Memory Model: leave blank at first
Fallback Memory Model: optional, can leave blank initially
Query Mode: recent
Prompt Style: balanced
Timeout: 15000
Max Summary Characters: 220
Logging: on while tuning, then off later
Persist Transcripts: off

Why this setup:

keeps it limited to DM-style chats first

#

avoids forcing a separate model right away
recent is the best default balance
logging helps you see whether it’s actually doing useful work

Then:

save config
restart gateway

in chat, test with:

/active-memory status
/verbose on
/trace on

A good starter config looks like:

#

{
  plugins: {
    entries: {
      "active-memory": {
        enabled: true,
        config: {
          enabled: true,
          agents: ["main"],
          allowedChatTypes: ["direct"],
          queryMode: "recent",
          promptStyle: "balanced",
          timeoutMs: 15000,
          maxSummaryChars: 220,
          persistTranscripts: false,
          logging: true,

#

        },
      },
    },
  },
}

One important bit: active memory is the pre-reply memory sub-agent. It works best once your normal memory backend/search is already set up.

Docs:

If you want, I can give you a wizard-by-wizard value list for every active-memory prompt so you can just click through it.

sinful ravine Apr 17, 2026, 1:49 AM

#

=openclaw-managed root=~/.openclaw/skills reason=symlink-escape requested=~/.openclaw/skills/git-guardrails-claude-code resolved=~/.agents/skills/git-guardrails-claude-code
03:48:39 [skills] Skipping escaped skill path outside its configured root: source=openclaw-managed root=~/.openclaw/skills reason=symlink-escape requested=~/.openclaw/skills/github-actions-templates resolved=~/.agents/skills/github-actions-templates
03:48:39 [skills] Skipping escaped skill path outside its configured root: source=openclaw-managed root=~/.openclaw/skills reason=symlink-escape requested=~/.openclaw/skills/grpc-integration-patterns resolved=~/.agents/skills/grpc-integration-patterns
03:48:39 [skills] Skipping escaped skill path outside its configured root: source=openclaw-managed root=~/.openclaw/skills reason=symlink-escape requested=~/.openclaw/skills/grpc-protobuf resolved=~/.agents/skills/grpc-protobuf
03:48:39 [skills] Skipping escaped skill path outside its configured root: source=openclaw-managed root=~/.openclaw/skills reason=symlink-escape requested=~/.openclaw/skills/helius resolved=~/.agents/skills/helius
03:48:39 [skills] Skipping escaped skill path outside its configured root: source=openclaw-managed root=~/.openclaw/skills reason=symlink-escape requested=~/.openclaw/skills/hooks-automation resolved=~/.agents/skills/hooks-automation
03:48:39 [skills] Skipping escaped skill path outside its configured root: source=openclaw-managed root=~/.openclaw/skills reason=symlink-escape requested=~/.openclaw/skills/implement-design resolved=~/.agents/skills/implement-design
how can i fix these?

stark wingBOT Apr 17, 2026, 1:50 AM

#

I’m checking the skill loader behavior so I can tell you the clean fix instead of guessing.

#

Those warnings mean OpenClaw found entries under:

~/.openclaw/skills

but they’re actually symlinks escaping that root and resolving to:

~/.agents/skills/...

OpenClaw skips them on purpose.

Clean fix

Pick one real home for those skills, don’t symlink between the two:

#

~/.agents/skills = personal agent skills
~/.openclaw/skills = shared managed/local skills for all agents

Since your resolved paths are already in ~/.agents/skills, the simplest fix is:

keep the real skill folders in ~/.agents/skills
remove the duplicate symlink entries from ~/.openclaw/skills

You do not need both. ~/.agents/skills is already loaded by OpenClaw.

If you want them shared instead

Put the real directories directly in ~/.openclaw/skills, not symlinks that point outside it.

Why this happens

OpenClaw only accepts skill paths whose realpath stays inside the configured root. A symlink from ~/.openclaw/skills/foo → ~/.agents/skills/foo counts as an escape, so it gets skipped.

#

Quick check

Inspect what’s there:

ls -l ~/.openclaw/skills
ls -l ~/.agents/skills

If you want, paste that output and I can tell you exactly which entries should stay where. Docs: https://docs.openclaw.ai/tools/skills and https://docs.openclaw.ai/tools/clawhub

sinful ravine Apr 17, 2026, 1:53 AM

#

◇ Install failed: summarize (exit 1) — Error: steipete/tap/summarize: formula requires at least a URL
==> Auto-updating Homebrew...
Adjust how often this is run with $HOMEBREW_AUTO_UPDATE_SECS or disable with
$HOMEBREW_NO_AUTO_UPDATE=1. Hide these hints with $HOMEBREW_NO_ENV_HINTS=1 (see man brew).
Error: steipete/tap/summarize: formula requires at least a URL
Warning: Removed Sorbet lines from backtrace!
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/formula.rb:397:in 'Formula#determine_active_spec'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/formula.rb:287:in 'Formula#initialize'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/formulary.rb:464:in 'Formulary::FormulaLoader#get_formula'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/formulary.rb:708:in 'Formulary::FromTapLoader#get_formula'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/formulary.rb:967:in 'Formulary.factory'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cli/named_args.rb:343:in 'block in Homebrew::CLI::NamedArgs#load_formula_or_cask'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/api.rb:380:in 'Homebrew.with_no_api_env_if_needed'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cli/named_args.rb:336:in 'Homebrew::CLI::NamedArgs#load_formula_or_cask'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cli/named_args.rb:85:in 'block in Homebrew::CLI::NamedArgs#to_formulae_and_casks'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cli/named_args.rb:84:in 'Array#each'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cli/named_args.rb:84:in 'Enumerable#flat_map'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cli/named_args.rb:84:in 'Homebrew::CLI::NamedArgs#to_formulae_and_casks'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cmd/install.rb:209:in 'Homebrew::Cmd::InstallCmd#run'
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/brew.rb:114:in '<main>'

stark wingBOT Apr 17, 2026, 1:54 AM

#

I’m checking what that Homebrew formula actually expects, because this looks like a formula/package issue rather than an OpenClaw one.

#

I found the tap formula, and the good news is this is not a permissions bug. It’s the installer path for Linux. I’m just checking the upstream install instructions so I can give you the clean workaround.

#

This one isn’t an approvals problem.

You’re on Linux, and steipete/tap/summarize is macOS-only. The tap formula itself says to use the Node package on Linux instead of Homebrew.

So the real fix is:

don’t install summarize from that Homebrew tap on Linux
install the @steipete/summarize package via a Node package manager instead

That weird:

formula requires at least a URL

is basically Homebrew being confusing. The actual issue is the wrong install path for your OS.

#

If this was triggered by an OpenClaw skill/plugin installer, then that installer logic is the thing that needs fixing, it should avoid the Homebrew path on Linux.

Upstream refs:

If you want, paste which OpenClaw skill/plugin tried to install summarize, and I can tell you whether you should:

preinstall it manually, or
file a bug against that installer metadata.

sinful ravine Apr 17, 2026, 1:55 AM

#

@trim patrol/summarize where to install it?

stark wingBOT Apr 17, 2026, 1:55 AM

#

Install it on the same machine and for the same user that runs OpenClaw/Gateway, so the summarize binary is on that runtime’s PATH.

So, on Linux:

if you run OpenClaw manually as your user → install it for that user
if OpenClaw runs via systemd/service user → install it for that service user or system-wide so the service can see it

Do not put it in ~/.openclaw.
It should just be a normal executable available on PATH, so:

which summarize

should work in the same environment the gateway uses.

Since this is Linux, use the Node package install path, not the Homebrew tap. In this server we prefer pnpm.

#

Useful refs:

If you want, paste whether you run OpenClaw:

directly in shell, or
as a systemd service,

and I’ll tell you the exact place it should live.

sinful ravine Apr 17, 2026, 1:58 AM

#

installed via npm i -g @trim patrol/summarize, now openclaw did not see it

stark wingBOT Apr 17, 2026, 1:59 AM

#

Two likely issues here:

Package name
- if you literally used @Peter Steinberger/summarize, that’s the wrong package name
- the upstream package is @steipete/summarize
PATH / service environment
- OpenClaw only sees binaries that are on the gateway process PATH
- so even if summarize works in your shell, the gateway may still not see it if it runs as a daemon/service with a different PATH

Quick checks

In the same shell where you installed it:

which summarize

#

summarize --version
npm bin -g

If those work, then the problem is almost certainly that the gateway service user/path can’t see that global bin dir.

What usually fixes it

install summarize for the same user that runs OpenClaw
make sure that user’s global Node bin dir is on the gateway PATH
then restart the gateway

That daemon-vs-shell mismatch is super common on Linux.

Docs:

https://github.com/steipete/summarize

#

https://docs.openclaw.ai/help/environment

If you paste:

output of which summarize
output of npm bin -g
whether OpenClaw runs in shell or systemd

…I can tell you the exact PATH fix.

sinful ravine Apr 17, 2026, 2:00 AM

#

anon@debian:~$ which summarize
/home/anon/.nvm/versions/node/v25.6.1/bin/summarize
anon@debian:~$ which summarize
/home/anon/.nvm/versions/node/v25.6.1/bin/summarize
anon@debian:~$ summarize --version
npm bin -g
0.13.0 (70006c3e)
Unknown command: "bin"

To see a list of supported npm commands, run:
npm help
anon@debian:~$ summarize --version
npm bin -g
0.13.0 (70006c3e)
Unknown command: "bin"

To see a list of supported npm commands, run:
npm help
anon@debian:~$

stark wingBOT Apr 17, 2026, 2:00 AM

#

Nice, that proves summarize is installed and working.

The important bit is this path:

/home/anon/.nvm/versions/node/v25.6.1/bin/summarize

So the problem is almost certainly nvm PATH visibility. OpenClaw/Gateway probably runs in an environment that does not load your nvm shell setup, so it never sees that bin dir.

Also, the npm bin -g failure is not the important part here, you already got the path from which summarize.

What this means

If you run OpenClaw manually in that same shell
restart it from that shell, and it should see summarize.

#

If OpenClaw runs as a daemon/systemd service
the service needs PATH access to:

/home/anon/.nvm/versions/node/v25.6.1/bin

or summarize needs to live somewhere more stable than an nvm-only path.

Most likely fix

Your gateway service is probably not inheriting nvm. That’s very common.

If you paste:

#

openclaw gateway status

I can tell you whether you should:

restart from the current shell, or
fix the service PATH for that nvm bin dir.

Docs: https://docs.openclaw.ai/help/environment

sinful ravine Apr 17, 2026, 2:02 AM

#

◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-17.log
Command: /home/anon/.nvm/versions/node/v25.6.1/bin/node /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/anon/.nvm/versions/node/v25.6.1/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/anon/.nvm/versions/node/v25.6.1/bin/node)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
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 2536665, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

stark wingBOT Apr 17, 2026, 2:02 AM

#

Ah, nice, this changes the picture.

Your systemd service already uses the same nvm bin dir:

/home/anon/.nvm/versions/node/v25.6.1/bin

and that is exactly where summarize lives.

So this probably is not a PATH problem anymore.

Most likely now

The earlier check/install failed before summarize was installed, and OpenClaw hasn’t retried that step yet.

#Approval gate issues

Clean fix

If you want them shared instead

Why this happens

Quick check

Quick checks

What usually fixes it

What this means

Most likely fix

Most likely now

I’d do this next