OpenClaw Starter Config Presets: 3 Safe Baselines You Can Actually Run

Most OpenClaw “it doesn’t work” reports are not deep product bugs. They are usually the result of adding too much scope before the baseline is stable:

• remote dashboard access before auth is reproducible,
• a tools profile that does not match the job,
• channels enabled before model and delivery probes pass,
• or a config edited without a rollback path.

This guide gives you three starter presets that keep the blast radius small and the verification path obvious.

What this guide helps you finish

By the end of this guide, you should have:

• chosen the smallest preset that fits your real use case,
• installed it with a rollback path,
• made gateway auth reproducible,
• verified model, channel, and dashboard basics,
• and held off on extra scope until the baseline is boring.

If you want the broader mental model or adjacent fix pages, keep these nearby:

• /guides/new-user-checklist
• /guides/openclaw-configuration
• /guides/openclaw-cli-command-cheatsheet-and-reddit-faq

Who this is for (and not for)

This guide is for readers who want a sane first baseline for:

• a local assistant setup,
• a local coding machine,
• or a remote gateway with dashboard access from another device.

This is not the right page if you already know you need a fully customized trust model, multiple node hosts, or a heavily tuned production deployment. In those cases, start with a working baseline here, then branch into deeper guides.

Before you choose a preset: collect these four facts

Before you touch openclaw.json, answer these four questions:

1. Where will the gateway actually run? Laptop, dev box, NAS, VPS, or container host.
2. What is the first job you need OpenClaw to do? Messaging, coding, remote dashboard access, or something else.
3. How will you prove it works? Model probe, channel probe, dashboard open, or a specific real task.
4. What is your rollback path? Backed-up config, saved token source, and a known way to restart the gateway.

If those answers are fuzzy, the right move is to pick the smallest preset and verify it before you expand.

0) Pick your preset (do not start from “full”)

Download one:

1. Local + safe messaging-first (recommended)
   • Template: /templates/openclaw/openclaw-starter-local-safe.json5
   • Best for: you mainly want a reliable assistant, not an unbounded coding runtime.
2. Local + coding machine
   • Template: /templates/openclaw/openclaw-starter-local-coding.json5
   • Best for: personal dev machines where you expect hands-on file edits and execution.
3. Remote dashboard access (LAN/tailnet)
   • Template: /templates/openclaw/openclaw-starter-remote-lan-tailnet.json5
   • Best for: running the gateway on another box and accessing the Control UI from your laptop or phone.

A simple rule: choose the preset that matches the smallest trustworthy version of your actual goal.

Remote access gotchas are real. If the Control UI worked once and then started failing after you changed how you reach it, read:

• /guides/control-ui-auth-and-pairing
• /guides/openclaw-remote-dashboard-access-playbook

1) Install the preset (backup first, always)

On the gateway host, back up your current config:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%Y%m%d-%H%M%S) 2>/dev/null || true

Then replace ~/.openclaw/openclaw.json with the template you chose.

If you are not sure where your active config really lives (service vs shell vs profile overrides), fix that first:

• /guides/openclaw-configuration

Good outcome at this step:

• you know which file the gateway is actually reading,
• you have a backup you can restore,
• and the preset file is in place before any restart.

2) Make auth reproducible (this prevents dashboard loops)

All three presets use token auth via env var:

• OPENCLAW_GATEWAY_TOKEN

Set it in the environment that actually runs the gateway:

• foreground debugging shell,
• systemd or launchd service env,
• or Docker/PaaS env settings.

Quick test for a foreground shell:

export OPENCLAW_GATEWAY_TOKEN='your-long-random-token'

Then confirm the running environment sees it:

openclaw doctor
openclaw config validate

If your config references ${OPENCLAW_GATEWAY_TOKEN} but the service still behaves unauthenticated, you are debugging env propagation, not JSON.

If your real goal is remote dashboard use, stable auth is more important than any later pairing discussion.

3) Restart and verify (the minimal probe loop)

After swapping presets, restart the gateway and prove the baseline:

openclaw doctor
openclaw gateway restart
openclaw gateway status

Then probe the two paths that most often look healthy until you test them:

openclaw models status --probe
openclaw channels status --probe

Finally, open the dashboard the right way:

openclaw dashboard

What a good baseline looks like here:

• gateway status shows the service is alive,
• model probes succeed for the path you expect,
• channel probes match what you actually enabled,
• and the dashboard opens through the tokenized entrypoint without unstable auth behavior.

If you see unauthorized or pairing required (1008) loops, do not keep regenerating tokens blindly. Fix the access path and device-approval layer:

• /guides/control-ui-auth-and-pairing

4) Expand deliberately (the rule that keeps you sane)

Once the preset is stable, expand in this order:

1. One model path - verify models status --probe first.
2. One channel - verify channels status --probe and one real send.
3. One extra capability - tools profile, plugin, node host, or automation.

This sequence matters because it keeps cause and effect legible. If you expand three things at once, you lose the ability to tell which change actually broke the system.

If you broaden tools and the agent suddenly only chats, that is often tools.profile drift:

• /guides/openclaw-not-using-tools-after-update

If your goal is coding plus exec, do approvals deliberately instead of guessing:

• /guides/openclaw-exec-approvals-and-safe-bins

Verification checklist after your first expansion

Do not call the setup stable just because the initial preset worked once. Re-check after the first real expansion:

• The gateway still starts with the environment and config you think it does.
• The dashboard opens from the intended entrypoint, not a stale bookmark or wrong origin.
• Model probes still hit the expected provider path.
• Channel probes still reflect the channels you actually enabled.
• You can identify exactly which single change you made after the preset baseline.

If one new capability breaks the system, roll back to the preset plus one known-good addition. That is a healthy outcome, not a failure.

What to do if the preset feels wrong

If none of the three presets feels like a clean fit, that is usually a sign that your use case needs one more decision before more config:

• Need remote access? Solve dashboard path and trust first.
• Need coding/runtime power? Solve tools profile and exec approvals first.
• Need channels? Solve probes and delivery verification first.

The point of a starter preset is not to describe every possible deployment. It is to give you one clean baseline from which the next decision is obvious.