DEV Community: Ma Xiao

OpenClaw Basic Configuration: A Practical Starter Guide

Ma Xiao — Sat, 20 Jun 2026 22:57:10 +0000

OpenClaw is easiest to understand if you treat it as a local-first control plane for an AI assistant. The model is only one part of the system. The real behavior comes from the gateway, the channels you expose, the tools you allow, the workspace you give it, and the safety boundaries around all of that.

This is a practical pass through the basic configuration I would check before calling an OpenClaw setup "ready enough to use."

1. Start with onboarding unless you have a reason not to

For a new install, the recommended path is still:

openclaw onboard --install-daemon

The onboarding flow handles the boring but important parts: choosing a model provider, storing auth, configuring the gateway, and getting a first usable session running. After that, you can inspect and refine the generated config instead of writing everything from scratch.

That is the right order. Let the tool create a valid baseline, then edit deliberately.

2. Know where the config lives

OpenClaw reads an optional JSON5 config from:

~/.openclaw/openclaw.json

You can point OpenClaw somewhere else with:

OPENCLAW_CONFIG_PATH=/path/to/openclaw.json

The important detail: OpenClaw validates config strictly. Unknown keys, wrong types, or invalid values can stop the gateway from starting. That sounds fussy, but it is a useful guardrail for an agent that may be connected to real accounts and real tools.

A tiny config might look like this:

{
  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace"
    }
  },
  channels: {
    telegram: {
      enabled: true,
      dmPolicy: "pairing"
    }
  }
}

3. Use the CLI for small config edits

For one-off changes, prefer the config CLI over opening the file manually:

openclaw config get agents.defaults.workspace
openclaw config set agents.defaults.heartbeat.every "2h"
openclaw config unset plugins.entries.brave.config.webSearch.apiKey

For larger edits, direct editing is fine, but validate immediately:

openclaw config validate
openclaw doctor

If the gateway refuses to start after a config change, openclaw doctor is the first command I would run.

4. Pick a primary model and define fallbacks

Model configuration is usually under agents.defaults.model.

{
  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-sonnet-4-6",
        fallbacks: ["openai/gpt-5.4"]
      },
      models: {
        "anthropic/claude-sonnet-4-6": { alias: "Sonnet" },
        "openai/gpt-5.4": { alias: "GPT" }
      }
    }
  }
}

The convention is provider/model. If you define agents.defaults.models, that list becomes an allowlist for model selection. That is useful in team or multi-agent setups, but it can surprise you later when /model some-new-model fails because the model is not on the allowlist.

My rule of thumb:

Use a strong primary model for tool-enabled agents.
Add one or two fallbacks for reliability.
Avoid weak models for agents that read untrusted messages or operate real tools.

5. Lock down who can message the bot

This is the configuration area I would not skip.

Each channel has its own section, such as:

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "${TELEGRAM_BOT_TOKEN}",
      dmPolicy: "pairing",
      allowFrom: []
    }
  }
}

The common DM policies are:

pairing: unknown senders get a pairing code before they can interact.
allowlist: only approved senders can talk to the bot.
open: anyone can message it, and this should be rare.
disabled: DMs are ignored.

For a personal assistant, pairing is a sane default. For a public or team-facing channel, be much more explicit. The bot is not just chat UI; it may have tools behind it.

6. Treat sessions as part of privacy

Session configuration controls how conversation state is shared or isolated.

{
  session: {
    dmScope: "per-channel-peer",
    threadBindings: {
      enabled: true,
      idleHours: 24,
      maxAgeHours: 0
    },
    reset: {
      mode: "daily",
      atHour: 4,
      idleMinutes: 120
    }
  }
}

For single-user local experiments, a broad shared session can be convenient. For anything involving multiple people, channels, or accounts, isolate more aggressively. per-channel-peer is a good starting point because it avoids one person's context bleeding into another person's conversation.

7. Enable sandboxing before the agent meets messy inputs

OpenClaw can run tools with significant host access. That is powerful, and also exactly why sandboxing matters.

A basic sandbox posture:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
        scope: "agent"
      }
    }
  }
}

The practical interpretation:

off: no sandboxing.
non-main: keep the trusted main session direct, sandbox other sessions.
all: sandbox everything.

If you are connecting group chats, webhooks, public channels, or feeds that may contain prompt injection, prefer stricter isolation. The more untrusted the input, the smaller the tool surface should be.

8. Keep secrets out of plain config when possible

OpenClaw reads environment variables from the parent process, a local .env, and ~/.openclaw/.env. You can reference env vars in config strings:

{
  gateway: {
    auth: {
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  },
  channels: {
    telegram: {
      botToken: "${TELEGRAM_BOT_TOKEN}"
    }
  }
}

That is better than hardcoding tokens into a config file you might sync, back up, or paste into a ticket. For more advanced setups, OpenClaw also supports secret references through env, file, and exec-backed providers.

9. Use hot reload, but know its limits

The gateway watches ~/.openclaw/openclaw.json and can hot-apply many changes. Agent, model, channel, tool, session, cron, and logging changes are generally designed to apply without a full manual restart.

Gateway server settings are different. Port, bind address, TLS, auth, and similar gateway-level changes may require restart behavior.

So the habit is:

openclaw config validate
openclaw gateway status
openclaw doctor

If you changed a networking or auth-related setting, expect a restart to be involved.

10. A starter checklist

Before using OpenClaw for anything real, I would check:

openclaw onboard --install-daemon has completed successfully.
openclaw gateway status reports the gateway is running.
The primary model and fallbacks are configured.
Each channel has a deliberate dmPolicy.
Group chats require mention unless you truly want always-on behavior.
Multi-user setups use isolated session scope.
Sandbox mode is enabled for non-main or untrusted sessions.
Secrets come from env vars or secret refs, not pasted tokens.
openclaw doctor is clean.

The theme is simple: configure OpenClaw like an assistant with hands, not like a chatbot with text. Once it can touch tools, accounts, files, or other people, basic configuration becomes part of your safety model.

References:

OpenClaw GitHub README: https://github.com/openclaw/openclaw
Getting started: https://docs.openclaw.ai/start/getting-started
Gateway configuration: https://docs.openclaw.ai/gateway/configuration
Models CLI: https://docs.openclaw.ai/concepts/models

How I Passed AWS SAP-C02 in Just 3 Days

Ma Xiao — Sat, 20 Jun 2026 22:46:24 +0000

When I tell people I passed the AWS Certified Solutions Architect – Professional (SAP-C02) exam after only three days of preparation, the first reaction is usually:

"There's no way you learned SAP-C02 in three days."

And they would be right.

I didn't start from zero.

I already had several years of hands-on AWS experience and had previously passed SAA-C03. What I needed wasn't months of learning AWS services—it was three days of focused exam preparation to bridge the gap between real-world experience and AWS's exam style.

This article explains exactly what I used and what worked for me.

Day 0: Understanding What SAP-C02 Really Tests

One mistake I see many candidates make is treating SAP-C02 like a harder version of SAA.

It's not.

The exam is heavily focused on:

Multi-account architectures
AWS Organizations
Hybrid connectivity
Migration strategies
Disaster recovery
Cost optimization at scale
Complex networking scenarios
Security and governance

The questions are long.

Very long.

In many cases, the challenge isn't knowing the service. It's identifying the best architectural trade-off among several technically correct answers.

After reading through multiple Reddit success stories, one common theme stood out:

SAP-C02 is as much a reading-comprehension and architecture exam as it is an AWS knowledge exam.

I quickly realized that practice questions would be the key.

Day 1: Focused Theory Review

Instead of watching a 50+ hour course from start to finish, I reviewed only the topics where I felt weak.

The resources I used were:

AWS Documentation

I spent several hours reviewing:

AWS Organizations
Control Tower
Transit Gateway
Direct Connect
Site-to-Site VPN
Route 53 routing policies
Disaster Recovery patterns
Migration services

The AWS documentation remains the most reliable source when you're unsure about service limitations or implementation details.

Stephane Maarek's SAP-C02 Course

I didn't watch the entire course.

Instead, I jumped directly to:

Hybrid networking
Security
Organizations
Migration
Cost optimization

Many SAP-C02 candidates on Reddit consistently recommend Stephane's course as a strong foundation resource, especially when paired with practice exams.

Day 2: Practice Questions, Practice Questions, Practice Questions

This was easily the most important day.

If I had to credit one factor for passing, it would be practice exams.

Tutorials Dojo

I completed multiple timed and review-mode practice exams.

What I liked:

Questions are scenario-based
Detailed explanations
Explanations often teach more than the questions themselves
Difficulty is reasonably close to the real exam

Many SAP-C02 pass posts on Reddit mention Tutorials Dojo as their primary exam preparation tool, especially for getting used to long-form architectural scenarios.

My scores were not amazing initially.

I was averaging around 65–75%.

Instead of worrying about the score, I focused on understanding why I got questions wrong.

That review process was where most of the learning happened.

Day 3: Mobile Revision and Weak Areas

By the third day, I didn't want to sit at my desk anymore.

I switched to shorter review sessions throughout the day.

For quick practice sessions on my phone, I used a few different question sources, including Revizo on iOS.

What I liked about using a mobile practice engine:

Easy to review during breaks
Quick quiz sessions
Useful for reinforcing concepts repeatedly
Helps build familiarity with AWS terminology

I wouldn't rely on any single question bank alone, but having something available on my phone made it easier to squeeze in extra revision time when I wasn't at my computer.

At this stage, I wasn't trying to learn new topics.

I was simply identifying recurring mistakes and reinforcing weak areas.

Exam Day Experience

The biggest surprise wasn't the technical difficulty.

It was the mental stamina required.

SAP-C02 contains lengthy scenarios and answer choices.

Several times I narrowed questions down to two seemingly correct answers and had to choose the option that best aligned with AWS architectural best practices.

Topics that appeared frequently included:

AWS Organizations
Multi-account governance
Hybrid networking
Migration
Resiliency
Security controls
Cost optimization

Time management was critical.

If you're preparing for SAP-C02, I strongly recommend doing full-length practice exams under timed conditions before attempting the real exam.

What I Would Do Again

If I had only three days to prepare again, I would follow almost exactly the same strategy:

1. Review Weak AWS Services

Don't try to relearn everything.

Focus on areas that regularly appear in SAP-C02:

Organizations
Control Tower
Direct Connect
Transit Gateway
Route 53
DR strategies

2. Prioritize Practice Exams

Practice exams provide the highest return on investment.

For me, Tutorials Dojo delivered the most value.

3. Review Every Incorrect Answer

The explanation is often more important than the score.

4. Use Mobile Study Time

Whether it's flashcards, notes, or a practice app like Revizo, small review sessions throughout the day add up surprisingly quickly.

Final Thoughts

Could a complete beginner pass SAP-C02 in three days?

Absolutely not.

Could someone with solid AWS experience pass in three focused days?

Yes.

SAP-C02 is less about memorizing services and more about understanding architectural trade-offs at scale.

If you already work with AWS regularly, focus your preparation on practice exams, identify your weak areas, and spend your time reviewing explanations rather than chasing perfect scores.

That's exactly what worked for me.

And three days later, I walked away with a pass.