Setting Up a Mac Mini with OpenClaw – A Step-by-Step Guide

I wanted a dedicated, always-on machine in my data rack running OpenClaw — three independent AI agent instances, each with its own memory, handling different parts of my work and life. Here is exactly how I did it using Claude Code on a blank new Mac Mini.

Preview: This is how I talk to 5 of my agents through Telegram:


You might wonder why I didn’t just do this manually in the terminal. I know my way around a command line, and in principle I could have pieced together the installation from the OpenClaw docs. But that wasn’t really the point. What I wanted was competent guidance from something that had seen a thousand variations of this setup — someone who would ask the right questions before touching anything, flag the non-obvious tradeoffs, and make sure I wasn’t inadvertently building security flaws into the system. OpenClaw’s own documentation warns that roughly 17–20% of community Skills contain malicious code. The inter-instance communication model, the QMD memory isolation, the launchd auto-start configuration — these are all areas where a confident but half-informed setup can leave you with something that technically works but is quietly broken or exposed. Using Claude Code to drive the installation meant I got an opinionated, question-first approach that I wouldn’t have gotten from reading docs alone (and that would have taken way more time).

Hardware and Initial Setup

I’m using a Mac Mini M4 (10-core CPU, 10-core GPU, 16-core Neural Engine, 24 GB unified memory, 512 GB SSD). Solid choice for this: silent, energy-efficient, and plenty of headroom for the workload. For security reasons it is located in a DMZ (demilitarized zone) of my home network, which means it can’t be accessed from the outside world and it cannot access my private LAN.

The initial setup steps:

  • Create a dedicated Gmail account — this becomes the agent’s email identity
  • Create an iCloud account using that new address to set up the Mac
  • Unpack the Mac Mini, attach a monitor, mouse, and keyboard for the initial setup run
  • Go through macOS setup using the new iCloud account
  • In Settings → Sharing, enable Remote Desktop and add the main account as a user — this is what allows you to run the machine headless, tucked away in a rack without any peripherals attached
  • In Settings, enable Time Machine — it backs up every hour, so you can always roll back if you break something
  • In Settings → Energy, enable Start automatically after power loss — critical for rack-mounted machines that might lose power
  • Install TeamViewer for external access from outside your local network
  • At this point I removed monitor, mouse and keyboard and moved the max “headless” into my data rack into the DMZ. Everything else went through the remote desktop.
  • Install the Claude App for OSX
  • Use Claude Code to install OpenClaw

The Installation Conversation

Rather than just running a script, I let Claude Code handle the whole installation. My prompt was deliberately open-ended:

“Can you install OpenClaw for me on this computer? I need it with three instances and QMD for all of them in separate memory systems, so the three instances (maybe more later) can work independently from each other. Please first discuss with me, ask everything you need to understand my intentions. Then we decide to get started later.”

Claude Code came back with exactly the right questions before touching anything:

  • Purpose of each instance — different projects? different roles?
  • LLM provider — which API key, shared or separate per instance?
  • Node.js — installed or should it handle that?
  • Channels — WhatsApp, Telegram, Slack, Signal, iMessage?
  • QMD stability warning — it flagged that QMD currently has 20+ open bugs and asked about hardware specs and fallback tolerance
  • Security — noted that roughly 17–20% of community Skills contain malicious code, asked whether I planned to use third-party Skills
  • Instance isolation — separate ~/.openclaw/agents/ directories with independent config.yaml and QMD collections, or even stronger isolation via Docker or separate user accounts?
  • Scaling — do I want an add-instance.sh script so adding instance #4, #5 etc. is trivial?

My answers:

  • Number One — my chief of staff, life and work organizer
  • CDR Research Agent — focused on carbon dioxide removal and enhanced weathering
  • Number One Code — coding and computer projects
  • OpenRouter as LLM provider, Opus 4.6 for all instances
  • No personal data on this machine; I may install Skills, but Claude Code should ask me before installing each one
  • Telegram — three bots already created: X, Y and Z
  • Node.js not yet installed — handle it
  • Instances should be able to talk to each other and hand off tasks
  • Auto-start on boot: absolutely yes

A second round of clarifying questions followed — mostly about which OpenRouter models, whether Master should be able to query the other two instances, and whether I wanted the Cisco Skill Scanner for vetting community Skills. Once those were answered, we were ready to go.

The Actual Installation

I gave Claude Code root folder access on the Mac Mini. From there it handled everything: installing Homebrew, Node.js 22, OpenClaw itself, setting up three agent directories with separate QMD collections, wiring up the Telegram bots, configuring OpenRouter, and setting up launchd for auto-start.

My hands-on time was roughly five minutes:

  • Copy the Homebrew install command into Terminal (sudo requires a human)
  • Tap each of the three Telegram bots to complete pairing

Everything else — including a detour to debug a bun/sqlite-vec crash in QMD — Claude Code handled autonomously. Total elapsed time was about 70 minutes. Without the QMD bug, it would have been around 50.

Gateway Restart Fix (a bit techy….)

One issue that surfaced post-install: the OpenClaw gateway dies when an agent triggers a config-change self-restart. The fix involves three steps.

1. Add OPENCLAW_NO_RESPAWN=1 to the launchd plist

Edit ~/Library/LaunchAgents/ai.openclaw.gateway.plist and add the environment variable. This makes config-change restarts happen in-process instead of exiting and relying on launchd to respawn.

2. Fix the PATH in the same plist

Add /opt/homebrew/opt/node@22/bin to the front of the PATH entry. Without this, child processes spawned by agents can’t find node.

3. Install a watchdog LaunchAgent

Create ai.openclaw.gateway-watchdog.plist — a small bash script that runs every 15 seconds. It checks whether the gateway job is still registered in launchd via launchctl print. If it’s gone, it re-registers with launchctl bootstrap. This catches the edge case where openclaw gateway restart does a bootout followed by a bootstrap, and the bootstrap silently fails.

After making these changes, reload both plists:

launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist

launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway-watchdog.plist

Observations

The whole setup — from unboxing to three running, auto-starting, Telegram-connected agent instances — took roughly 70 minutes, with me actively involved for maybe 5 of those. The conversation-first approach before touching anything is worth it: the questions Claude Code asked up front caught several things I hadn’t thought through (the QMD stability tradeoffs, the Skills security surface, the inter-instance communication model).

The watchdog pattern for the gateway is something I’d recommend anyone doing a similar setup add from day one — it’s a small piece of infrastructure that makes the whole thing significantly more reliable.

Unknown's avatar

Author: Dirk Paessler

CEO Carbon Drawdown Initiative -- VP Negative Emissions Platform -- Founder and Chairman Paessler AG