FREE GUIDE20 min read·Mar 2026
primarynode

How to Add a Second Mac Mini as an OpenClaw Agent Node

Two agents. Shared brain. Zero idle compute.

multi-agentmac-mininodeorchestrationintermediate

Why this matters

A second Mac mini isn't just more hardware — it's a second AI brain running in parallel. Both machines share the same memory, goals, and context. One handles what you're focused on. The other handles everything else. This guide shows you how to wire them together.

Most people install OpenClaw on one machine and stop there. But the moment you add a second Mac mini, something qualitatively different happens — you stop being a single-agent operation and become a coordinated AI team.

Here's what that actually looks like in practice:

  • You're writing a blog post and ask your primary agent to draft it. Meanwhile, your second agent is independently researching competitors, building SEO pages, and running a coding task — all at the same time. No waiting. No queuing.
  • You're in a meeting and your primary agent handles your messages. Your second agent is pushing commits, running tests, and summarizing pull requests in the background.
  • You spawn a Codex coding session on the second machine for a long-running build. Your primary agent keeps working on everything else uninterrupted — two separate contexts, zero interference.
  • One agent monitors your inbound emails and calendar. The other executes tasks. They share memory, so both know exactly what's going on.

The shared brain is what makes this powerful. Both machines pull from the same git-synced workspace — the same memory, soul, project context, and goals. They're not two separate AI assistants. They're two instances of the same agent, working in parallel, always on the same page.

🧠 The Brain Trust Effect: Think of it as optimizing for zero idle compute. When you're actively using one agent, the other can be doing background work — research, builds, content, monitoring. When you're not using either, both can run scheduled tasks. No brain cycles wasted.

The Best Part: You Get Both Access Modes

This is where it gets really interesting. The second machine has two independent services that work simultaneously:

  1. Node service — connects to your primary gateway, letting your primary agent delegate tasks, run remote commands, and orchestrate work on the second machine
  2. Its own gateway — gives the second machine its own dashboard, its own agent sessions, its own direct access point

These are completely independent. Running both at the same time is not only possible — it's the recommended setup. You get:

  • Direct access to the second agent whenever you want (open its dashboard, talk to it directly)
  • The primary agent can tap into it as a worker node behind the scenes
  • When you're using the second agent directly, the primary can still delegate tasks to it — the resources never go to waste

⚡ Real World Example: You open the second machine's dashboard and ask it to research a topic. Meanwhile, your primary agent notices it needs to run a long build — it dispatches that build to the second machine as a background node task. The second machine handles both simultaneously. Two conversations, one machine, zero waste.


Part 1: Shared Workspace (Git Sync)

Both machines should share the same brain. Point the second machine at your workspace repo:

cd ~/.openclaw
git clone https://github.com/YOUR-ORG/YOUR-workspace workspace-main

What stays shared (synced via git)

  • MEMORY.md — long-term project memory
  • SOUL.md — personality and values
  • AGENTS.md — workspace rules
  • USER.md — info about the human
  • TOOLS.md — tool-specific notes

What stays LOCAL — add to .gitignore

  • IDENTITY.md — each machine needs its own name and emoji
  • memory/ — daily session logs (prevents merge conflicts)
  • HEARTBEAT.md — per-machine tasks (optional)

Step 1 — Add local-only files to .gitignore on the primary machine:

cd ~/.openclaw/workspace-main
echo "IDENTITY.md" >> .gitignore
git add .gitignore && git commit -m "exclude local-only files" && git push

Step 2 — On the second machine, pull and create its own identity:

cd ~/.openclaw/workspace-main && git pull

cat > ~/.openclaw/workspace-main/IDENTITY.md << 'EOF'
# IDENTITY.md - Who Am I?
- **Name:** [Your agent name]
- **Creature:** AI agent running on OpenClaw on [Machine Name]
- **Vibe:** Competent and direct. Gets things done.
- **Emoji:** [Pick one]
EOF

Part 2: Install the Node Service on the Second Machine

The second machine runs as a node — it connects to the primary gateway and waits for work.

Step 1 — Install the LaunchAgent, pointing it at your primary machine's LAN IP:

openclaw node install --host PRIMARY_LAN_IP --port 18789 --display-name YourNodeName --force

Step 2:

openclaw node restart

Part 3: The LAN Security Bypass (Required)

Gotcha: OpenClaw blocks plaintext WebSocket connections (ws://) by default for security. On a trusted private LAN, you need to explicitly allow it.

Bake the bypass environment variable into the LaunchAgent plist:

/usr/libexec/PlistBuddy -c \
  "Add :EnvironmentVariables:OPENCLAW_ALLOW_INSECURE_PRIVATE_WS string 1" \
  ~/Library/LaunchAgents/ai.openclaw.node.plist

Then fully reload the LaunchAgent:

launchctl unload ~/Library/LaunchAgents/ai.openclaw.node.plist
launchctl load ~/Library/LaunchAgents/ai.openclaw.node.plist

💡 Why unload/load instead of openclaw node restart? openclaw node restart restarts the process but does not reload the plist configuration. You must use launchctl unload/load for new environment variables to take effect.


Part 4: Set the Gateway Auth Token

The second machine needs to authenticate with the primary gateway. Grab the token from your primary machine's config and set it on the secondary:

openclaw config set gateway.auth.token YOUR_PRIMARY_GATEWAY_TOKEN

Part 5: Approve the Pairing on the Primary Machine

Once the node connects, the primary gateway requires manual approval. On the primary machine:

# List pending pairing requests
openclaw devices list

# Approve by request ID
openclaw devices approve <request-id>

# Or approve the latest
openclaw devices approve --latest

Verify it's connected:

openclaw nodes status

You should see: paired · connected


Part 6: Test Remote Execution

From the primary machine, run a command on the node to confirm everything works:

openclaw nodes run --node <node-id> --raw "echo 'hello from secondary' && uname -a"

Get the node ID from openclaw nodes status.


Part 7: Install the Secondary Machine's Own Gateway

Install the gateway on the secondary machine:

openclaw gateway install && openclaw gateway restart

The secondary dashboard will be available at http://SECONDARY_LAN_IP:18789.

That's it. The node connection to the primary stays in place — adding the gateway doesn't affect it. From that point on, both access modes are live simultaneously.


Key Decisions & Lessons Learned

DecisionWhy It Matters
Keep IDENTITY.md local (not in git)Each machine needs its own name — shared identity causes confusion
Keep memory/ localTwo machines writing daily notes = git merge conflicts
Use launchctl unload/load not node restartOnly way to reload plist environment variables
Keep gateway auth onGateway is LAN-accessible; no auth = anyone on the network can use it
OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1Required for LAN ws:// connections on trusted private networks
Install secondary gateway separatelyEnables both access modes: direct dashboard + orchestration via primary

Troubleshooting

"SECURITY ERROR: Cannot connect over plaintext ws://" Add OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 to the LaunchAgent plist and do a full launchctl unload/load — not just node restart.

"pairing required" — but nothing in openclaw nodes pending Check openclaw devices list instead. Nodes appear under devices, not under the nodes pending subcommand.

"unauthorized: gateway token mismatch" Set the primary gateway token on the secondary: openclaw config set gateway.auth.token YOUR_TOKEN

"EHOSTUNREACH" Check if the secondary can ping the primary: ping -c 3 PRIMARY_LAN_IP. If ping works but WebSocket fails, it's the insecure WS issue above.

Node crashes in a loop (only PATH lines in logs) Check ~/.openclaw/logs/node.err.log — the actual error is there, not in node.log.

openclaw node restart didn't apply env var changes Always use launchctl unload/load after editing the plist. Restart alone is not enough.


Quick Reference

# On primary — check node status
openclaw nodes status

# On primary — run command on node
openclaw nodes run --node <node-id> --raw "<command>"

# On primary — list pending approvals
openclaw devices list

# On secondary — check node service
openclaw node status

# On secondary — view node logs
tail -f ~/.openclaw/logs/node.log
tail -f ~/.openclaw/logs/node.err.log

Also on Claw Guides