OpenClaw 2026 cloud Mac install runbook: Node 22, onboard daemon, and TCC permissions

Unlike our companion article on node selection and launchd troubleshooting, this piece focuses on the 0→1 path when the instance is freshly delivered and OpenClaw is not yet installed. You have SSH (and VNC when needed), no corporate Golden Image, and no colleague machine with a copyable ~/.openclaw tree.

The cloud Mac install story differs from local development in one important way: every prerequisite must be scripted and verified in non-interactive shells. A developer laptop accumulates Node versions, brew packages, and TCC grants over months; a rented Mac starts empty and expects you to reproduce that stack in a single session. Teams that treat the instance like a disposable CI runner usually succeed faster than teams that try to mirror a hand-tuned workstation without documenting each step.

In architecture reviews, these five pain points are routinely underestimated:

• Node version drift: macOS may ship Node 18 or 20 by default. Gateway runtime requires Node 22 LTS (22.16+) or Node 24, which causes openclaw onboard to exit during dependency resolution before any daemon is registered.
• Wrong install channel: CI images favor global npm; ops teams favor Homebrew. Mixing both leaves two openclaw binaries on PATH and doctor reports version mismatches that look like corruption.
• TCC with no one to click Allow: Automation, Accessibility, and Screen Recording prompts cannot be answered over pure SSH. Gateway or channel probes fail intermittently until a human completes grants through VNC or screen sharing.
• Incorrect token placement: The 2026 config key is gateway.auth.token (not legacy gateway.token). Writing the secret only in .zshrc without launchd inheritance produces the loop: Gateway auth is set to token, but no token is configured.
• Memory and storage underestimated: Multi-agent workloads with local model caches on M4 16 GB can trigger heavy swap. Large repositories should plan for 1 TB / 2 TB expansion or M4 Pro sizing before onboarding (see decision closure at the end).

Operations that skip preflight often discover failures at step four or five of onboard, then spend hours uninstalling and reinstalling CLI packages when the real fix was Node 22 or a single TCC checkbox. Documenting the sequence before you start saves rework when the same playbook runs across staging and production nodes.

Memory line for on-call: Node 22 first, one CLI path, TCC next, then onboard plus daemon. Skip any step and pairing plus tunnel troubleshooting becomes multi-hour rework.

OpenClaw on macOS supports multiple install entry points. On a SSH-only cloud Mac, pick the path that is repeatable, scriptable, and matches your team CI so staging and production stay aligned.

Homebrew fits teams that already standardize Mac maintenance through brew and want upgrades to look like any other package. npm global install fits Node-centric pipelines where GitHub Actions or internal runners already cache npm artifacts. Source builds belong only when you must pin a commit or carry a private patch; they add compile time and PATH management that most first-time cloud installs do not need.

Regardless of channel, treat the install as infrastructure: record the exact commands in your runbook, version-control any wrapper scripts, and avoid ad hoc curl-to-bash on production hosts unless your security team explicitly allows it. The matrix below summarizes trade-offs from a 2026 production perspective on rented Macs.

After install on any path, run which -a openclaw and confirm exactly one executable. Symlink into /opt/homebrew/bin or /usr/local/bin so launchd ProgramArguments never point at a PATH that exists only inside an interactive shell session.

Before running openclaw onboard, assert the environment with non-interactive commands so on-call does not discover a half-finished install at midnight.

Preflight should run in the same shell context you will use for automation: if onboard runs under a login shell but launchd jobs use a minimal environment, test both. Node version checks belong in CI gates for any script that provisions cloud Macs; rejecting an instance early is cheaper than debugging Gateway token loops on a host that never had the right runtime.

node -v | grep -E 'v22\.(1[6-9]|[2-9][0-9])|v24\.' || exit 1
uname -m | grep -q arm64
df -h / | awk 'NR==2{gsub(/%/,"",$5); if($5>85) exit 1}'
xcode-select -p || xcode-select --install

If Node fails the check, install Node 22 LTS via fnm or the official pkg, and keep login shell and launchd environments consistent. For daemons, the safer pattern is writing the token into gateway.auth.token inside ~/.openclaw/openclaw.json rather than exporting it only in .zprofile.

Disk pressure above 85% on the system volume slows npm installs and log rotation during onboard. If you plan multiple agents or large model caches, provision extra storage before the first onboard rather than resizing mid-incident. Apple Silicon arm64 is assumed for JEXCLOUD nodes; Rosetta-only workflows are out of scope for this runbook.

• Citable: minimum Node version — Gateway runtime requires Node 22.16+ or Node 24 (per official onboarding documentation).
• Citable: default Gateway port — 18789; after install, lsof -i :18789 should show 127.0.0.1 only.
• Citable: disk guidance — Reserve at least 30 GB beyond the system volume for dependency cache and logs; multi-agent parallelism often warrants 512 GB to 1 TB expansion.

Follow these steps in order during initial install and after major upgrades. Skipping doctor acceptance before moving to remote pairing is the most common source of false Gateway is broken escalations.

1. SSH access and base tooling: Configure key login per the help center; confirm sw_vers reports macOS 14+, and system clock is synchronized (TLS and token validation depend on accurate time).
2. Install Node 22 and a single CLI path: Example: brew install node@22 && brew link --overwrite node@22, or npm install -g openclaw@latest; verify with openclaw --version.
3. Run onboard: openclaw onboard walks through Gateway setup; add --install-daemon when you need a background service, which registers LaunchAgent ai.openclaw.gateway.
4. Write gateway.auth.token: Use openclaw doctor --generate-gateway-token or edit config manually; chmod 600 ~/.openclaw/openclaw.json; if launchd does not inherit shell exports, run launchctl setenv OPENCLAW_GATEWAY_TOKEN '…' then launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway.
5. Doctor acceptance: Run openclaw status, openclaw gateway status, and openclaw doctor in sequence; healthy output includes Runtime running and RPC probe ok; curl against local /health should return 200.
6. Register ops baseline: Add log directories to rotation; on the pricing page evaluate M4 Pro or a second build machine; proceed to local app remote pairing.

Steps three through five are where most teams lose time. Onboard may succeed interactively while launchd still lacks the token if you only exported variables in the current SSH session. Always restart the Gateway agent after token writes and re-run doctor before declaring the host ready for pairing.

openclaw onboard --install-daemon
openclaw doctor
lsof -nP -iTCP:18789 -sTCP:LISTEN
TOKEN=$(openclaw config get gateway.auth.token)
curl -sf -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18789/health

If openclaw gateway restart fails to recover after an agent-triggered restart, the community fix is often openclaw gateway install --force (see openclaw#40306). Do not uninstall and reinstall repeatedly before doctor acceptance completes; that hides the underlying token or port conflict.

Cloud Macs often run without a physical display. macOS privacy (TCC) prompts must be answered through VNC or screen sharing by a human or on-call engineer. Use the table below to grant only what your workflow needs and avoid over-broad permissions that complicate audits.

Schedule a short VNC window before onboard when your workflow uses UI automation, screen capture, or reads protected directories. Pure Gateway-only setups may need fewer grants, but channel plugins often pull in Accessibility or Automation even when you did not expect it during planning. After grants, run onboard again rather than assuming partial progress persisted across a failed permission step.

After authorization, restrict VNC to internal networks or SSH tunnels and record grant time and operator in your change log for audit trails. JEXCLOUD provides VNC access for exactly this class of one-time setup; lock it down once TCC and onboard are complete.

Running OpenClaw on a home Mac or laptop on unstable Wi-Fi often yields Gateway dropouts when sleep and automatic updates restart the host overnight. Hosting on oversubscribed VPS or non-macOS environments cannot satisfy Apple channel and TCC compliance paths. Teams that need 0→1 install within hours, repeatable Node 22, and dedicated bare-metal compute usually get the calmest path by following this six-step runbook on JEXCLOUD multi-region cloud Mac hosts, then continuing with node selection and remote pairing articles: roughly two-minute provisioning, optional M4 Pro and 1 TB / 2 TB storage upgrades per project. See the JEXCLOUD pricing page for plans and regions.