Why this lesson matters
A calm first setup makes the rest of OpenClaw much easier to learn. This lesson helps you reach a clean baseline before you add any complexity.
Installation and first-run success
Lesson 1: Install OpenClaw and reach the first working chat
A plain-language walkthrough of the official setup path, from prerequisites to the first successful local dashboard session.
People who need a confidence-building first win before they can trust the rest of the tool.
You do not need to read every page manually. Paste this URL into AI tools such as ChatGPT, Gemini, OpenClaw, or another agent, then use this prompt:
Read this page carefully, summarize the key points, and guide me through the next decision step by step. I want to ask follow-up questions in conversation, and you can also help turn the material into reusable GPTs, Gems, or skills if useful.
Learning goals
- Use the official baseline before attempting deeper customization
- Understand the difference between installation and onboarding
- Verify success with visible checks instead of guesswork
Prerequisites
- A machine running macOS, Linux, or WSL2
- Node.js 24 recommended locally (Node.js 22.14+ still supported)
- Permission to install CLI tooling and open the local Control UI
How to use this lesson
Start with the key ideas, work through the action steps, then use the mistakes, notes, and assignment to turn the lesson into a repeatable habit you can trust later.
Action steps
Step 1: Confirm the environment before installing
Before running anything, check node -v and confirm you are on a supported release. Node 24 is the current recommended baseline, while Node 22.14+ still works.
Build the habit of verifying prerequisites first. It keeps later debugging focused on the real problem instead of vague environment drift.
Step 2: Use the standard installer (Resist the custom path)
Use the standard installer path first so you can reach a known-good baseline quickly. Avoid extra layers such as custom folders or nested containers until the default path works.
Once the first local run is stable, you can decide whether extra isolation or customization is actually necessary.
Step 3: Run the onboarding wizard and complete the wiring
Run the initialization command and complete the onboarding wizard. This is where gateway configuration, auth, and optional integrations are wired into a usable system.
Keep installation and onboarding separate in your mind so you can identify which layer failed if something breaks later.
Step 4: Verify the gateway and launch the Control UI
Confirm the gateway is listening on port 18789, then open the Control UI in your browser. A working local dashboard is the clearest proof that the setup succeeded.
Do not move on until you have that visible success signal. It is a better checkpoint than staring at terminal output and hoping for the best.
Start with the supported baseline (Zero Customization on Day One)
A common beginner mistake is trying to customize the whole stack before the first working session exists. The official documentation points to a much simpler starting line: use Node 24 if possible, or at least stay on a supported Node 22.14+ release, and follow the standard installer path first.
That matters because the first goal is not originality. It is a clean, verifiable baseline you can trust. Once you know the default setup works, every later change becomes easier to judge.
For macOS, Linux, or Windows WSL2, the safest first move is still the direct shell installer. Let it place the standard files, keep the defaults, and postpone deeper customization until the environment is already stable.
Treat onboarding as the real first milestone
It is easy to think the job is finished once the CLI is installed. In practice, that only gives you the tool on disk. The onboarding flow is what turns it into a usable local system.
The official setup sequence uses onboarding to connect local authentication, create gateway configuration, and prepare the pieces that let the dashboard and tools work together.
If you separate these two milestones in your mind, troubleshooting gets much easier later. Installation confirms the software is present. Onboarding confirms the software has been assembled into a working environment.
Verify with the visible dashboard, not with terminal guessing
Do not treat a quiet terminal as proof that everything is working. The clearer check is to confirm the gateway is running and then open the local dashboard in the browser.
If the Control UI loads through openclaw dashboard or directly at http://127.0.0.1:18789/ and responds normally, you have a visible success signal for the network and interface layer.
That habit matters throughout the course: do not move to bigger automation until each layer has passed a visible, human-readable check first.
Common mistakes
- Treating install logs as proof that the full environment is ready
- Skipping onboarding and then guessing at auth or gateway problems
- Changing folders or config structure before the first working session exists
Why this matters in real work
A calm first win builds more confidence than early complexity.
Operational clarity matters more than advanced customization in the first stage.
Assignment
Assignment: produce your first clean setup checkpoint
- Write down your OS and exact Node version
- Complete the default install and onboarding flow without extra changes
- Capture one concrete success signal, such as the dashboard loading locally
- Write one sentence naming the layer you now know is working
Key takeaway
A reliable OpenClaw setup is more than a successful install command. It is a verified local environment with a working gateway and a visible first interaction.
If you want a deeper implementation guide after this first win, continue with OpenClaw Playbook One.
Sources and references
In this course
Related guides
Read the related guide and course overview if you want broader context around safety, workflow design, and the rest of the learning path.
Previous lesson
This is the first lesson in the sequence.
Next lesson
Lesson 2: Understand the Gateway, Control UI, and workspace strategy
What the Gateway does, how the Control UI connects, and why your custom operating files should live outside the main repo.
Continue to next lesson