How to Configure OpenClaw Agent Tool Access

Tool access is the difference between a helpful OpenClaw agent and an expensive accident. The model may decide what to do, but the Gateway decides which tools are available. OpenClaw gives you profiles, allowlists, denylists, provider-specific restrictions, and agent-level policy so every agent does not need the same blast radius.

30-second answer

Start with a narrow tools.profile such as minimal or messaging, then add only the tool groups or individual tools the agent needs. Use tools.deny for hard blocks because deny wins. Use tools.byProvider for model-specific restrictions, and use per-agent settings when one agent needs more or fewer tools than the default.

When this pays off

This is buyer-intent work because serious OpenClaw usage almost always involves real tools: messaging, memory, web search, files, runtime, browser, media, cron, or nodes. The value comes from action, but action must be bounded. A support agent, coding agent, finance agent, and public demo agent should not share one unrestricted tool menu.

Operator runbook

1. Choose the base profile first. The official docs define minimal as session_status only, messaging as messaging plus session/status tools, coding as filesystem/runtime/web/sessions/memory/cron/media-oriented groups, and full as unrestricted. Pick the smallest profile that still lets the agent do its job.
2. Add allow rules intentionally. Tools can be named directly or grouped, such as group:runtime, group:fs, group:web, group:sessions, group:memory, group:ui, group:automation, group:messaging, group:nodes, and group:media. Group names are convenient, but they widen access quickly, so prefer specific tools for sensitive agents.
3. Use deny for non-negotiables. The docs say deny wins over allow. If browser, exec, apply_patch, sessions_spawn, cron, or node relay should never be available to an agent, put that in deny even if a profile or group might otherwise include it.
4. Restrict by provider when model trust differs. tools.byProvider can set a different profile or allow/deny set for a provider or model. This is useful when a cheap model is fine for summaries but should not get runtime or filesystem tools, while a trusted coding model gets a broader surface.
5. Separate agent roles. Put business support, coding, research, and public demo work into different agents or Gateways when tool needs differ sharply. An agent with no filesystem access behaves very differently from one that can edit a repo, even if their prompts sound similar.
6. Review elevated exec separately. tools.elevated controls elevated execution outside the sandbox, and per-agent overrides can only further restrict. Keep elevated access off or tightly allowlisted unless you have a clear operator approval workflow.

Verification

After changing policy, start a session as that agent and inspect available tools through the normal runtime path. Then try one allowed low-risk tool and one denied tool. For HTTP /tools/invoke, confirm denied tools return 404. For chat, confirm the agent does not claim it can perform actions the policy removed.

Common mistakes

Do not start with full because setup is easier. Do not forget that allowing write does not automatically cover every mutation path the same way as apply_patch; read the exact docs for the tool ids you care about. And do not trust prompts like “never use shell” as a substitute for removing runtime tools.

Turn it into a repeatable operating system

The Playbook gives practical tool-access recipes: founder operator, coding agent, support responder, research scout, social media agent, and rescue bot. Each recipe starts with what business outcome the agent owns, then grants only the tools that outcome actually requires.

Before rollout

Before rollout, test the policy with the model you will actually use. Tool availability can vary by provider policy, agent config, group policy, and HTTP deny lists. A passing config review is useful, but a live allowed-tool and denied-tool test catches drift faster.