OpenClaw feels simple after the first message. The hard part starts when the Gateway can reach files, channels, skills, and more than one person.
A safe setup needs boundaries before personality.
This guide is current as of July 15, 2026. It covers the Gateway, workspace, sessions, memory, and skills without turning the first day into an automation project.
Kill the default approach
The default setup connects every channel to one assistant and assumes continuity means safety.
OpenClaw routes messages into persisted sessions. Direct messages can share a main session by default. That works for a single-user assistant, but it is dangerous when several people can message the same agent.
Build one private lane first. Add channels after you understand session scope.
By the end you will have
- A running Gateway and Control UI
- A workspace with explicit operating files
- Isolated direct-message sessions where needed
- Curated memory instead of hidden assumptions
- The OpenClaw Safe Start Pack
Step 1: install and verify the Gateway
OpenClaw currently requires a supported Node.js 22, 23, or 24 release; the official docs recommend Node 24. Use an official installer or an installation method you can inspect.
Do not paste an unaudited network-to-shell command from a repost.
Run onboarding:
openclaw onboard --install-daemonThen verify the process:
openclaw gateway status
openclaw dashboardThe documented default Gateway port is 18789.
You should see: a running Gateway and a Control UI that can complete one chat.
Step 2: treat the workspace as the operating system
The default workspace lives at ~/.openclaw/workspace. OpenClaw can create files such as:
AGENTS.md
SOUL.md
TOOLS.md
IDENTITY.md
USER.md
HEARTBEAT.mdEach file has a job. AGENTS.md carries operating rules. TOOLS.md explains local tool constraints. USER.md holds user context that belongs in the workspace.
Keep the workspace in a private git repository if it contains personal instructions or operational history. Review diffs before syncing because memory files can include sensitive details.
Start with four rules in AGENTS.md:
# Operating rules
1. Ask before external writes, sends, installs, or deletion.
2. Keep secrets out of chat, memory, and logs.
3. State the evidence used for consequential claims.
4. End completed tasks with decision, result, and next action.Step 3: isolate sessions before inviting anyone
OpenClaw routes DMs, group chats, rooms, cron jobs, and webhooks differently. A single-user configuration can use the default shared DM session for continuity.
If several people can message the agent, isolate by channel and sender:
{
session: {
dmScope: "per-channel-peer",
},
}Without isolation, one person's context can affect another person's conversation. Treat this as a privacy boundary, not a preference.
Inspect stored sessions with:
openclaw sessions
openclaw sessions --active 120
openclaw sessions --all-agents --limit 25Session rows show persisted conversation state. They do not prove a channel is connected. Use channel probes and health commands for liveness.
Step 4: keep memory curated
OpenClaw memory is written to files. The model only remembers what gets saved.
The main layers are:
| File | Job | Load behavior |
|---|---|---|
MEMORY.md | Durable facts and standing decisions | Loaded at normal session start within budget |
memory/YYYY-MM-DD.md | Daily working notes | Recent notes load on a fresh session |
DREAMS.md | Optional review summaries | Human review layer |
Do not copy full transcripts into MEMORY.md. Store stable facts, preferences, and decisions that should change future behavior.
Use a small entry shape:
## 2026-07-15
- Decision: package releases require a clean build and signed tag.
- Evidence: release checklist in docs/release.md.
- Review: remove if the release process changes.Memory has a context budget. A giant file may stay on disk while only part of it enters the prompt. Short entries make truncation less damaging.
Step 5: inspect skills like code
OpenClaw skills are directories with a SKILL.md contract. Skills can also bring dependencies, commands, secret needs, and tool access.
Use owner-qualified references where possible, and verify the trust envelope before installation:
openclaw skills verify @owner/skill-name
openclaw skills verify @owner/skill-name --cardSecurity scans reduce risk. They do not prove a workflow matches your intent.
Read the skill body, inspect dependency installers, and decide which agent may load it. Prefer sandboxed runs for untrusted inputs or risky tools.
Related: install agent skills without getting owned.
Magnet: OpenClaw Safe Start Pack
# OpenClaw Safe Start Pack
GATEWAY
- Official or audited install path
- Gateway status green
- One Control UI chat works
WORKSPACE
- Private workspace repo
- AGENTS.md defines approvals and secrets boundary
- TOOLS.md documents local constraints
SESSIONS
- One user: shared DM scope may be acceptable
- Multiple users: per-channel-peer isolation
- Channel health checked separately from session rows
MEMORY
- Durable facts only in MEMORY.md
- Daily residue in dated notes
- Every standing decision has a review condition
SKILLS
- Owner-qualified source
- Verify trust envelope
- Read instructions and installers
- Start sandboxed when risk is unclearYou should see: one healthy Gateway, explicit session isolation, a short MEMORY.md, and no unreviewed skill.
Worked example: private Telegram assistant
You configure one Telegram bot for yourself and keep the default single-user session. The workspace contains operating rules and a short user profile.
Before adding a second user, you change the DM scope to per-channel-peer. Each sender now gets a separate session key. You verify channel health independently, then send synthetic messages from both test identities.
Only after isolation works do you add a calendar skill. You inspect the skill and keep event creation behind approval.
Failure modes
| Failure | What happened | Repair |
|---|---|---|
| Two users share context | DM scope stayed on main | Use per-channel-peer and clean stale rows carefully |
| Agent forgets a decision | It never reached memory | Write a short reviewed entry |
| Memory crowds the prompt | MEMORY.md became a transcript | Split daily notes and prune durable memory |
| Channel looks dead | Session list was used as a health check | Probe the channel or run deep status |
| Skill passes a scanner but acts wrong | Trust was confused with fit | Read and test the behavior in isolation |
| Gateway has broad host access | Tools run outside a sandbox | Narrow tools and use sandbox controls |
When not to use OpenClaw
- You want a terminal-first coding session with no messaging gateway
- A managed task surface already covers the workflow
- You cannot isolate multiple users or protect workspace memory
- You only need one short chat
- You are not ready to operate a daemon, channels, and updates
A persistent assistant creates persistent maintenance.
Sources and related guides
- OpenClaw getting started
- OpenClaw session management
- OpenClaw memory
- OpenClaw skills
- Hermes Agent vs OpenClaw vs Claude Cowork
- Agent OS for solo developers
Bottom line
OpenClaw becomes useful when the Gateway, workspace, sessions, and memory have separate jobs.
Your next action: apply the OpenClaw Safe Start Pack before connecting a second person or installing a community skill.