Skip to content
Last updated

OpenClaw Advanced Configuration Guide

This guide is for users who already finished the first install and want safer routing, gateway protection, skills, and browser relay related controls.

Files and workflow

Common config locations:

  • ~/.openclaw/openclaw.json
  • ~/.openclaw/.env

Recommended workflow:

  1. Update config with the CLI when possible
  2. Confirm values with openclaw config get
  3. Restart the gateway
  4. Run a test message
Command
openclaw config set key.value "value"openclaw config get || trueopenclaw gateway restart || openclaw restart

Routing and model control

Use advanced configuration when you need:

  • primary and fallback models
  • provider-specific routing
  • stricter channel controls
  • workload-specific policies

Example goals:

  • cheap default model for daily use
  • stronger reasoning model for hard tasks
  • fallback provider when the primary provider fails

Gateway token and secure access

The gateway token protects access to the gateway or related control surfaces. Treat it like an API key.

Illustrative structure:

JSON
{  "gateway": {    "bind": "127.0.0.1",    "port": 18789,    "token": "REDACTED_TOKEN"  }}

Best practices:

  • keep gateway access on localhost when possible
  • store tokens in .env or another secret store
  • never commit tokens to git

If you need a quick definition first, read the gateway token glossary term.

Browser relay and network-sensitive workflows

Browser relay refers to the part of your environment that lets OpenClaw coordinate browser-driven actions or bridge browser sessions back to the gateway.

Use browser relay carefully when:

  • you depend on browser automation or browser-side validation
  • your gateway should only trust authenticated or isolated relay traffic
  • you need proxy, sandbox, or tunnel controls for browser-connected workflows

Operational advice:

  • keep relay traffic inside a controlled network boundary
  • combine relay features with a gateway token and local binding
  • verify logs after every change

If you are still learning the concept, read the browser relay glossary term.

Skills, plugins, and custom extensions

OpenClaw skills and plugins expand what your environment can do, but they also increase risk.

Typical pattern:

Command
openclaw plugins install @xxx/yyyopenclaw gateway restart || trueopenclaw logs | tail -n 100

For custom repositories:

Command
mkdir -p ~/.openclaw/skillscd ~/.openclaw/skillsgit clone https://github.com/someone/some-skill-repo.git

Rules of thumb:

  • trust skills like code, not like simple content
  • test new skills in isolation first
  • combine skills with allowlists, policy controls, and careful logging

Continue with the skills hub if you want to browse examples.

Security and operational checklist

  • keep secrets in .env
  • use a minimal command allowlist
  • avoid public gateway exposure
  • restart and re-test after every meaningful config change
  • prefer Docker or VPS isolation for long-running setups

Related OpenClaw guides