Install deliberately on macOS, Linux, Windows, WSL, or a VPS

Verifiedon 2026-07-302026.7.1-2

Install the smallest supported thing

The installation lesson has two separate outcomes: make the openclaw executable available to the intended user, and preserve enough evidence to know what happened. It does not configure a provider, attach a channel, install a daemon, or prove that an agent is safe. Separating installation from onboarding keeps a failed runtime, a bad path, or an unexpected privilege request from being mistaken for a model or Gateway failure.

This lesson is checked against OpenClaw 2026.7.1-2, revision 1237c0cf8157a6ad4a900d6b165ea8c830449e78. Read the official install guide and its installer implementation notes immediately before installing. The source currently lists Node 22.22.3+, 24.15+, or 25.9+ as supported lines and notes that the installer can provision a newer default where appropriate. Treat those requirements as source-backed facts for this revision, not as timeless compatibility advice.

Choose the command family

On macOS, Linux, and WSL2, the reviewed installer is the shell script. The no-onboarding form is the right boundary for this lesson because it installs the CLI without immediately entering provider configuration. On Windows, use the PowerShell form. A VPS should use a dedicated non-root service account and the same no-onboarding idea; the account, SSH policy, firewall, backups, and removal owner are part of the install decision.

# macOS / Linux / WSL2 — run as the test user
curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | bash -s -- --no-onboard

# Windows PowerShell — run in the dedicated Windows profile
& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -NoOnboard

The curl | bash form is shown because it is the command in the reviewed primary source, not because piping a remote script is automatically safe. If your organisation requires inspection, use the installer’s documented help or dry-run option, retrieve the script through an approved review process, verify the URL and transport policy, and stop when the fetched content or requested privilege differs from the pre-flight card. Do not substitute a command copied from a video or a random package blog. The official installer notes explain that the script may install or select Node, choose an install method, and perform post-install probes; that scope must be part of your review.

Lab: record the host before and after

Before the installer runs, record only non-sensitive facts: operating system, architecture, current user role, Node version, shell, target workspace path, and the exact source URL/revision. Do not paste a full environment dump; environment variables often contain credentials. A safe record is deliberately boring.

before: platform=<Linux x86_64>; user=<test-user>; node=<22.22.3>; source=<revision>
command: <platform-specific no-onboard form>
after: openclaw path=<user-scoped path>; version=<redacted version string>
provider: not configured in this lesson
channels: none

Run node --version and then openclaw --version as the same user who will run the later lessons. A successful package installation under sudo may still be unusable to the intended user because the binary is in a different prefix, configuration is owned by root, or the shell’s PATH differs. If you see EACCES, stop and repair the user-level prefix according to the official installer guidance; do not make a permanent root-owned global install simply to silence the error.

Keep installation evidence attributable

Do not treat the installer’s last line as the result. The shell can report success while a PATH update is pending, a post-install daemon probe is skipped, or a different executable shadows the new binary. Capture the executable path and version from the intended user’s fresh shell, then compare them with the pre-flight card. If the version is outside the course range, stop rather than “trying it anyway”; unsupported behavior makes later failures impossible to classify. Also record whether the installer created files outside the declared state directory. A surprising path is a review question, not a cleanup invitation. This is the moment to preserve a receipt because the installation is still small and reversible.

Platform-specific decisions

macOS/Linux: confirm the shell can resolve the binary after installation. If the installer changes PATH, open a new shell and rerun only the version check. Do not add a broad shell export from an unreviewed snippet.

Windows: if PowerShell says openclaw is not recognised, check the user-level npm prefix and reopen PowerShell. Avoid changing machine-wide PATH for a disposable course exercise. Record whether Windows native, WSL2, or a desktop-managed Gateway is the source of truth; do not mix their state directories.

WSL2: keep the lab workspace in the Linux filesystem unless you have a reason to use a mounted Windows path. If you use /mnt/c, write down the Windows owner, backup location, and whether Windows security tooling or sync software can read the files. A path that looks local may cross a second trust boundary.

VPS: use a named non-root account, restrict SSH, and confirm where the Gateway state and workspace will live before running any daemon step. This course does not ask you to expose a remote Gateway to the public internet. Leave daemon installation for a later, reviewed decision.

Checkpoint and learner artifact

Your artifact is an installation ledger containing the selected path, source link, pre-install Node version, command family (not a secret-bearing shell history), post-install OpenClaw version, executable path, and the statement “provider, channels, and daemon not configured in this lesson.” A second operator should be able to tell whether you installed the intended binary without seeing your home directory or credentials.

Expected result: openclaw --version returns the intended version, and the path resolves for the test user. Failure mode: unsupported Node, a missing PATH entry, root-owned files, an unexpected installer prompt, or a host that is not actually disposable. Rollback: preserve the redacted ledger, stop the Gateway if any installer post-task started one, and follow the exact route in the official uninstall guide. That guide recommends previewing removal with openclaw uninstall --dry-run --all; do not delete guessed directories or a shared Node installation.

Primary source receipt

• Installation guide, reviewed revision
• Installer flow and flags, reviewed revision
• Uninstall scope and dry-run, reviewed revision

The next lesson configures one provider. If the install ledger has an unknown binary owner, unsupported runtime, or unresolved path, do not proceed: an onboarding failure will be harder to interpret and harder to remove.