Some gateway.nodes.denyCommands entries are ineffective
gateway.nodes.denyCommands uses exact node command-name matching only (for example system.run), not shell-text filtering inside a command payload. - Unknown …
Fix: Use exact command names (for example: canvas.present, canvas.hide, canvas.navigate, canvas.eval, canvas.snapshot, canvas.a2ui.push, canvas.a2ui.pushJSONL, canvas.a2ui.reset). If you need broader restrictions, remove risky command IDs from allowCommands/default workflows and tighten tools.exec policy.
help me fixing this
#warnings with openclaw status
stone hatch
prisma sinewBOT
hazy turtleBOT
That warning means your gateway.nodes.denyCommands probably contains patterns or shell words like system.*, rm, curl, etc. It only matches exact node command IDs.
First, please run:
openclaw --version
openclaw config get gateway.nodes.denyCommands
openclaw config get gateway.nodes.allowCommands
For the common “block node shell execution” case, use exact command names:
openclaw config set gateway.nodes.denyCommands '["system.run.prepare","system.run","system.which"]' --strict-json
openclaw config validate
openclaw gateway restart
openclaw security audit
If you were trying to block canvas commands, don’t use canvas.*; list them exactly:
openclaw config set gateway.nodes.denyCommands '[
"canvas.present",
"canvas.hide",
"canvas.navigate",
"canvas.eval",
"canvas.snapshot",
"canvas.a2ui.push",
"canvas.a2ui.pushJSONL",
"canvas.a2ui.reset"
]' --strict-json
Also: denyCommands does not filter shell text inside system.run. If you need shell command restrictions, tighten exec policy instead:
openclaw config set tools.exec.security allowlist
openclaw config set tools.exec.ask on-miss
Docs: https://docs.openclaw.ai/gateway/configuration and https://docs.openclaw.ai/tools/exec-approvals
stone hatch
next one is:
security.trust_model.multi_user_heuristic Potential multi-user setup detected (personal-assistant model warning)
Heuristic signals indicate this gateway may be reachable by multiple users:
- channels.telegram.groupPolicy="allowlist" with configured group targets
Runtime/process tools are exposed without full sandboxing in at least one context.
Potential high-impact tool exposure contexts: - agents.defaults (sandbox=off; runtime=[exec, process]; fs=[read, write, edit, apply_patch]; fs.workspaceOnly=false)
OpenClaw's default security model is personal-assistant (one trusted operator boundary), not hostile multi-tenant isolation on one shared gateway.
Fix: If users may be mutually untrusted, split trust boundaries (separate gateways + credentials, ideally separate OS users/hosts). If you intentionally run shared-user access, set agents.defaults.sandbox.mode="all", keep tools.fs.workspaceOnly=true, deny runtime/fs/web tools unless required, and keep personal/private identities + credentials off that runtime.
hazy turtleBOT
Yep — this one is a trust-boundary warning, not necessarily a broken config.
It’s saying: “you have a Telegram group configured, so multiple humans may be able to prompt the same agent, and that agent currently has host filesystem + exec access.”
First check version:
openclaw --version
Recommended safe fix
If Telegram/group users are not all fully trusted, sandbox everything and restrict file access:
openclaw config set agents.defaults.sandbox.mode all
openclaw config set agents.defaults.sandbox.scope session
openclaw config set agents.defaults.sandbox.workspaceAccess none
openclaw config set tools.fs.workspaceOnly true
openclaw config validate
openclaw gateway restart
openclaw security audit
That keeps exec/process/read/write/edit/apply_patch from touching your host directly.
Stricter “chat-only bot” fix
If this gateway is mainly for Telegram/group use, remove runtime/filesystem/web tools globally:
openclaw config set tools.profile messaging
openclaw config set tools.deny '["group:runtime","group:fs","group:web","group:ui","group:nodes","cron","gateway"]' --strict-json
openclaw config validate
openclaw gateway restart
openclaw security audit
Important nuance
Because you have channels.telegram.groupPolicy="allowlist" with group targets, the audit may still mention “potential multi-user setup.” That part is expected. The dangerous part is the line showing:
sandbox=off; runtime=[exec, process]; fs=[read, write, edit, apply_patch]; fs.workspaceOnly=false
You want that gone or reduced.
stone hatch
I want that gone while at the same time having my agent working as root on the host
hazy turtleBOT
Short version: you can’t have “no warning” + “Telegram group/multi-user access” + “root host exec/filesystem” at the same time. That warning is doing its job.
If you want the agent working as root on the host, make it single-operator only. Remove/disable Telegram group access:
openclaw --version
openclaw config set channels.telegram.groupPolicy disabled
openclaw config unset channels.telegram.groups
openclaw config validate
openclaw gateway restart
openclaw security audit
If you use Telegram accounts, check for account-level group config too:
openclaw config get channels.telegram.accounts
and disable/unset the matching account paths.
If you still want a group bot, the safe pattern is two gateways:
- Private/root gateway: only you, no groups, host/root access.
- Group gateway: sandboxed, no root, limited tools.
Running a root-capable host agent from a group chat is exactly the setup the audit is warning about. I wouldn’t try to silence that; I’d split the trust boundary.
Docs: https://docs.openclaw.ai/channels/telegram and https://docs.openclaw.ai/gateway/security
stone hatch
how to reverse the previous flow of commands?
After openclaw tui im gettin now this messeage?
Agent failed before reply: Sandbox mode requires Docker, but the "docker" command was not found in PATH. Install Docker (and ensure "docker" is
available), or set agents.defaults.sandbox.mode=of f to disable sandboxing. | spawn docker ENOENT.
Logs: openclaw logs --follow
hazy turtleBOT
Yep — that error is from the sandbox setting we enabled. Since Docker isn’t installed, turn sandboxing back off.
Run:
openclaw --version
openclaw config set agents.defaults.sandbox.mode off
openclaw config unset agents.defaults.sandbox.scope
openclaw config unset agents.defaults.sandbox.workspaceAccess
openclaw config unset tools.fs.workspaceOnly
openclaw config validate
openclaw gateway restart
If you also ran the stricter “chat-only bot” commands, undo those too:
openclaw config unset tools.profile
openclaw config unset tools.deny
openclaw config validate
openclaw gateway restart
Then try:
openclaw tui
Small warning: this gets your agent back to host/no-sandbox mode, but the security audit warning may return — because that’s the risky setup it was warning about. To keep sandboxing instead, install Docker and make sure docker is in PATH.
stone hatch
how to add a AI API key manually?
hazy turtleBOT
Don’t paste the key here. Add it on the machine running the Gateway.
First:
openclaw --version
Manual env-file method:
mkdir -p ~/.openclaw
nano ~/.openclaw/.env
Add the provider key you use, for example:
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...
GEMINI_API_KEY=...
OPENROUTER_API_KEY=...
Save, then restart:
openclaw gateway restart
openclaw models status --probe
If you’re not using the gateway daemon and only running openclaw tui, just close/reopen the TUI after editing ~/.openclaw/.env.
Easier interactive option: