OpenClaw Best Practices: Running an Agent You Can Leave Alone

This page leads with OpenClaw because openclaw best practices is the phrase people actually search. The practices are not OpenClaw-only: every section notes the Hermes Agent equivalent, and the Hermes side is covered in its own guides.

1. Fix the DM policy before anything else

This is the one that costs money rather than dignity. Telegram bots are discoverable in search, so a bot with an open DM policy is a public endpoint billed to your model account.

{
  "channels": {
    "telegram": { "dmPolicy": "pairing" }
  }
}

With "pairing", an unknown sender gets a code that you approve explicitly:

openclaw pairing approve telegram <code>

Discord is the deliberate exception. Discord bots are invite-only, so there is no equivalent discovery problem, and pairing there produces a genuinely worse experience — the user has to DM the bot, collect a code, then find the gateway UI to approve it. Use an open policy on Discord, and note that it requires an explicit allow list or config validation rejects it:

{
  "channels": {
    "discord": { "dmPolicy": "open", "allowFrom": ["*"] }
  }
}

The rule generalises: decide per channel based on whether strangers can find the bot, not on a single global setting.

2. Understand what exec approvals are for

OpenClaw’s default for a trusted single-operator setup permits host execution without prompting. That is the right default for a laptop assistant and the wrong one for anything reachable by other people.

The important distinction, and the one that gets misread: an exec allowlist is a guardrail for operator intent. It protects you from an agent confidently running something destructive on your behalf. It is not a security boundary against a hostile user. If someone untrusted can send messages to the agent, the isolation has to come from the container, the user account, and the network — an approval prompt is not a sandbox.

Practical shape: restrict the high-risk tools — exec, browser, web_fetch, web_search — to the agents that genuinely need them, and allowlist rather than blocklist. A blocklist is a bet that you enumerated every dangerous command, and you did not.

3. Keep the gateway private

The gateway is the control plane: sessions, tools, events, channel connections, and the credentials behind them. Treat exposure as the highest-severity mistake on this page.

• Bind to 127.0.0.1 and reach it through an SSH tunnel or VPN.
• Never put the Control UI on an untrusted network.
• If it must be reachable, terminate TLS 1.2 or better in front of it, require authentication, and restrict by source address.
• Confirm WebSocket origin validation is enforced — a browser on the same network is an attack path otherwise.

openclaw gateway status

Hermes equivalent: the same reasoning applies to hermes gateway. Bind locally, tunnel in, and check status rather than assuming.

4. Treat extension code as code you are running

Plugins execute in the same process as the agent and its credentials. Both frameworks ask you to review declared capabilities before enabling a third-party plugin, and that prompt deserves a real read rather than a reflex.

• Review the declared capabilities, version, and source before enabling.
• Pin versions. OpenClaw npm specs take --pin; Hermes Git installs take --ref <40-char-SHA>. Unpinned means an upstream push changes what your agent runs.
• Disable rather than delete when something misbehaves, so you keep the configuration for diagnosis.
• Watch for message-injection capability in particular. In Hermes that is allow_gateway_injection; grant it only to plugins you control.

The same caution belongs on MCP servers and skills pulled from a public hub. See OpenClaw security advisories for the concrete cases.

5. Configure a model fallback

Agents fail in a specific and annoying way when a model route dies: every turn errors, and if nobody is watching, a scheduled job fails silently for days. Set a fallback before you need one.

This matters most when you are running a preview or stealth model — those slugs get withdrawn with no notice. Keep a stable production model as the default and reserve experimental routes for sessions you are watching. See fallback models.

6. Back up the state that is not reproducible

Reinstalling the agent is easy. Recovering what it learned is not. The parts worth a backup are the ones that accumulate:

Back up the whole data directory rather than cherry-picking files, and restore into a throwaway instance once to confirm the backup is real. An untested backup is a belief, not a backup.

7. Rotate credentials, and scope them

Least privilege applies to the keys as much as the tools. Use a separate model key per agent so you can revoke one without taking down the rest, rotate on a schedule rather than after an incident, and keep secrets in the intended credential store rather than baked into an image or a shell profile. If you build images, never bake a platform-owned token into one.

8. Change defaults deliberately, and write down why

Most agent outages we see are not exotic. They are a default that was changed to make one thing work, and then forgotten. Keep the config in version control, keep a one-line note for every non-default value, and re-read it before blaming the framework.

A useful test before going live: could a stranger who found this agent cost you money, read something private, or run a command? If the answer to any of those is yes and you did not intend it, the configuration is not finished.

OpenClaw Launch applies container isolation, TLS, and a private gateway to managed instances. On self-hosted deployments those are yours to configure.

OpenClaw best practices FAQ

Related guides

• OpenClaw Security Advisories
• Hermes Agent Plugins
• Hermes Agent vs OpenClaw
• OpenClaw on Docker