OpenClaw Week-One Checklist: Secure Setup You Can Verify

What this guide helps you complete

By the end of week one, you should have an OpenClaw install that is:

• Running reliably in the background
• Accessible through the dashboard without auth confusion
• Locked down against accidental open inbound messaging
• Backed up and recoverable
• Easy to debug with a repeatable first-check routine

Official references:

• Dashboard (Control UI)
• Updating
• Gateway runbook

Who this is for (and not for)

Use this checklist if you just installed OpenClaw and want a safe default operating baseline.

If you are still deciding runtime/platform (especially Windows native vs WSL2), read this first:

• /guides/openclaw-windows-native-vs-wsl2

Step 0 (2 minutes): Preflight before you configure anything

1. Confirm Node.js is >= 22.
2. Decide where OpenClaw will run daily (local laptop, homelab node, cloud VM, etc.).
3. Decide who can send the bot messages on day one (default to strict).

If any of these are unclear, stop and decide now. Most first-week issues come from changing these assumptions mid-setup.

Step 1: Install and daemonize the gateway

Install globally:

npm install -g openclaw@latest
# or
pnpm add -g openclaw@latest

Run onboarding with daemon setup:

openclaw onboard --install-daemon

Verify Step 1

openclaw gateway status
openclaw health

You should confirm all three checks below:

• Gateway service is running under your user session
• Health output is returned without critical startup failures
• Service still starts after you close and reopen your terminal/session

If this fails, do not reinstall first. Capture logs:

openclaw logs --follow

Step 2: Use tokenized dashboard access (avoid “unauthorized”)

The dashboard is served locally (default http://127.0.0.1:18789/) and requires auth.

Use:

openclaw dashboard

Open the tokenized URL it prints (?token=...).

Verify Step 2

• Dashboard loads with no unauthorized message
• Refreshing the same browser session remains authenticated
• You are not exposing the dashboard publicly during first-week setup

If dashboard access is part of a remote setup, use this playbook instead of opening public ports:

• /guides/openclaw-remote-dashboard-access-playbook

Step 3: Set safe inbound policy before enabling real traffic

Recommended safe defaults:

• DMs: pairing or allowlist
• Groups: mention-triggered behavior only

Start strict, then relax intentionally if your workflow needs it.

Verify Step 3

• A trusted sender can trigger expected behavior
• An unapproved sender is blocked or queued for approval
• Group chatter without mentions does not trigger the bot

Channel-specific setup:

• /guides/telegram-setup
• /guides/whatsapp-setup

Step 4: Back up state before you rely on the system

Back up the full state directory (default ~/.openclaw/), including config, credentials, sessions, and workspace data.

tar -czf openclaw-state-backup.tgz ~/.openclaw

Treat this archive as sensitive credential material.

Verify Step 4

Run a quick archive integrity check:

tar -tzf openclaw-state-backup.tgz | head

Confirm you can see expected files/directories from .openclaw.

If backups matter for long-running workflows, add automation in week one.

Step 5: Update with a boring, reversible routine

npm i -g openclaw@latest
openclaw doctor
openclaw gateway restart
openclaw health

Verify Step 5

• Gateway restarts cleanly
• Health checks pass after the update
• Existing channel behavior still works with your policy defaults

If an update regresses behavior, capture status/logs first, then rollback or config-adjust deliberately.

What to check first when anything looks wrong

Always run these in order before trying ad hoc fixes:

openclaw gateway status
openclaw health
openclaw logs --follow

Why this order works:

1. gateway status tells you if the supervisor/process layer is up.
2. health shows higher-level subsystem failures quickly.
3. logs --follow gives live error context for the failing component.

For symptom-first triage and common failure classes:

• /guides/openclaw-symptom-first-triage-card
• /guides/openclaw-no-response-and-rate-limit-troubleshooting

Week-one done criteria

You are in a good state when all are true:

• Gateway survives session restarts and still reports healthy
• Dashboard access is reliable via tokenized flow
• Inbound policy blocks unknown senders by default
• A recent ~/.openclaw/ backup exists and is inspectable
• You can collect status, health, and logs in under two minutes

Next useful hardening guides:

• /guides/openclaw-starter-config-presets
• /guides/openclaw-skill-safety-and-prompt-injection
• /guides/openclaw-operability-and-observability