OpenClaw Complete Guide: Cloud Mac AI Agent Sandbox from Zero to Production

What Problem Does OpenClaw Solve?

AI Agent tools — Cursor, Claude Code, AutoGPT, and the growing list of autonomous coding assistants — are powerful and increasingly dangerous. They read and write files, execute shell commands, and make outbound network requests. When permissions are not explicitly bounded, the failure modes range from misconfigured projects to leaked API keys and deleted data. On macOS, the problem is sharper: you need the full Xcode toolchain, Apple Neural Engine access, and code-signing capabilities that Docker containers and Linux VMs simply cannot provide.

OpenClaw's role is to draw auditable, revocable, and enforceable operation boundaries around each Agent task on a real macOS physical machine. It is not a cage that strips Agents of capability. Instead, it precisely controls which directories they can touch, which system commands they can invoke, and which network destinations they can reach — while preserving native macOS behavior everywhere else.

If you only need to spin up your first sandbox session quickly, start with our five-minute quickstart. This guide assumes you have decided to run OpenClaw in production and covers the full lifecycle from provisioning through day-two operations.

Console Workflow: End to End

OpenClaw ships on every ZilCloud Mac mini M4 — no separate add-on purchase required. The full provisioning flow breaks into four stages:

1. 01
   Order and provision a Mac mini M4 instance

   On the order configuration page, pick a region (Singapore, Japan, South Korea, Hong Kong, or US East). Base pricing starts at $20.9/day. After payment, provisioning completes in 1–5 minutes and you receive SSH credentials plus a VNC password.

2. 02
   Open Console → select instance → OpenClaw tab

   First visit triggers zero-trust initialization: the system generates an Ed25519 key pair bound to the instance, installs the com.zilcloud.openclaw.daemon background service, and creates the default audit log directory at /var/log/openclaw/.

3. 03
   Configure access policies and team members

   In the Access Control panel, add collaborator emails and assign roles (Owner, Operator, or Auditor). Operators can start sandbox sessions; Auditors can read audit logs but cannot enter a sandbox shell.

4. 04
   Download CLI credentials and verify the environment

   The console provides a one-click install script and session token download. Run claw status in your terminal and confirm daemon: running and auth: valid before writing sandbox policies.

The console also exposes a live session monitor: active sandbox count, per-session CPU and memory usage, and BLOCK event statistics for the last 24 hours. For security reviews, you can export a PDF compliance summary directly from the dashboard.

CLI Command Reference

The OpenClaw CLI is invoked as claw. Every sandbox operation flows through it. Below are the command groups you will use most often:

# ── Status & health ──
claw status                          # daemon status, auth, active sessions
claw doctor                          # run environment diagnostics

# ── Session lifecycle ──
claw run --config policy.yaml        # start sandboxed session
claw run --template xcode-build      # start from saved template
claw attach <session-id>             # attach to running session
claw stop <session-id>               # gracefully terminate session
claw list                            # list all sessions (active + recent)

# ── Templates ──
claw template list                   # show built-in presets
claw template export agent > policy.yaml
claw template save my-ci-policy      # save current config as named template

# ── Audit ──
claw audit tail <session> --follow   # live audit stream
claw audit query --since 24h --action BLOCK
claw audit export <session> --format json

# ── Network policy testing ──
claw net test --domain api.openai.com   # dry-run domain against active policy

claw doctor is worth running on a schedule. It checks whether the daemon is running, Endpoint Security authorization is valid, the audit log directory is writable, and the CLI token has not expired. When a sandbox fails to start with a vague error, claw doctor usually surfaces the root cause.

Permission YAML: Field-by-Field Breakdown

OpenClaw policies are defined in YAML. Understanding each field is prerequisite to writing policies that work on the first try. Below is a production-ready configuration with section-by-section notes:

version: "1"
session:
  name: "prod-agent"
  auto_cleanup: false          # keep workspace after session ends
  max_duration: "4h"           # auto-terminate after 4 hours
  idle_timeout: "30m"          # terminate if no activity for 30 min

filesystem:
  workspace: "~/agent-workspace"
  readonly_mounts:
    - /Applications
    - /usr/local/bin
    - /Library/Developer      # Xcode toolchain
  deny:
    - ~/.ssh
    - ~/Library/Keychains
    - ~/Library/Application Support/Cursor/User/globalStorage

syscalls:
  preset: "agent"
  deny:
    - ptrace
    - setuid
    - mount

network:
  allow_domains:
    - "api.openai.com"
    - "api.anthropic.com"
    - "*.github.com"
    - "registry.npmjs.org"
    - "pypi.org"
  block_all_others: true
  log_blocked: true            # record blocked attempts in audit log

The session block controls lifecycle. auto_cleanup: false suits code-generation tasks where you want artifacts to survive after the session ends. max_duration and idle_timeout are safety rails that prevent Agents from holding resources indefinitely or running unattended.

The filesystem block is where most misconfigurations happen. workspace is the Agent's sole read-write root. readonly_mounts lists paths that can be read but not written. deny is a hard block list that overrides readonly_mounts. OpenClaw resolves symlink targets — if /usr/local/bin/git points into Homebrew's Cellar directory, you must add that Cellar path to readonly_mounts or git invocations will be intercepted.

In the network block, block_all_others: true combined with log_blocked: true silently drops unauthorized outbound requests and records them in the audit log. This is preferable to returning connection errors that tip the Agent off and encourage workarounds.

Multi-User Zero-Trust Access and Team Collaboration

In team settings, not everyone should get full sandbox shell access. OpenClaw's zero-trust model rests on three principles: verify identity on every access, assign least-privilege permissions, and make every action auditable.

The console supports three roles:

Each role authenticates through an independent CLI token. Tokens default to a 24-hour lifetime and can be revoked from the console. When a member leaves or their access changes, an Owner can revoke all active tokens and terminate running sandbox sessions in one action — without restarting the instance or rotating SSH keys.

For temporary access — external consultants reviewing code, for example — create a time-limited Guest token with read-only audit scope. It expires automatically; no manual cleanup required.

CI/CD Pipeline Integration in Practice

Embedding OpenClaw sandboxes in CI/CD is how you move AI Agent automation from experimental to production-grade. Below is a GitHub Actions workflow that runs a sandboxed code-review Agent on a ZilCloud Mac mini M4 self-hosted runner:

# .github/workflows/ai-review.yml
name: AI Code Review (Sandboxed)
on: [pull_request]

jobs:
  review:
    runs-on: self-hosted   # ZilCloud Mac mini M4 as self-hosted runner
    steps:
      - uses: actions/checkout@v4

      - name: Start OpenClaw sandbox
        run: |
          claw run --template ci-review --detach
          SESSION=$(claw list --json | jq -r '.[0].id')
          echo "SESSION_ID=$SESSION" >> $GITHUB_ENV

      - name: Run AI review agent
        run: |
          claw attach $SESSION_ID --exec \
            "claude -p 'Review the diff in this PR for security issues'"

      - name: Export audit log
        if: always()
        run: |
          claw audit export $SESSION_ID \
            --format json \
            --output audit-${{ github.run_id }}.json

      - name: Stop sandbox
        if: always()
        run: claw stop $SESSION_ID

This workflow does three important things: each pull request gets an isolated sandbox session (audit logs partitioned per PR); the Agent runs inside the sandbox with network policy limited to AI APIs and GitHub; and if: always() ensures audit logs are exported whether the review succeeds or fails.

Commit the ci-review template YAML to a .openclaw/ directory in your repository, versioned alongside the workflow. Policy changes then have Git history, and security reviewers can see the exact permission boundary in effect.

Advanced Audit Log Usage

Audit logs are OpenClaw's core differentiator. Beyond live tailing, these patterns are worth knowing:

Conditional batch queries: when an Agent behaves unexpectedly, filter history by time range and action type:

# Find all blocked network attempts in the last 7 days
claw audit query \
  --since 7d \
  --action BLOCK \
  --type network \
  --format table

# Find all file writes outside workspace
claw audit query \
  --since 24h \
  --action BLOCK \
  --type write \
  --format json | jq '.[] | select(.target | contains("/etc"))'

Compliance export: security audits often require specific report formats. OpenClaw supports JSON, CSV, and PDF. PDF reports include session summaries, ALLOW/BLOCK statistics, policy snapshots, and a timeline view suitable for compliance submission.

Alert rules: configure thresholds in the console — for example, "more than 50 BLOCK events per hour in a single session" or "read attempt on ~/.ssh detected." Alerts reach Owners via email or webhook without someone watching the audit stream around the clock.

Troubleshooting and Performance Tuning

These are the five issues we see most often in support tickets, with fixes that actually work:

On performance: OpenClaw sandbox overhead in full audit mode is roughly 3% CPU — negligible on a 10-core Apple M4. For latency-sensitive workloads such as real-time inference, you can disable fine-grained syscall auditing and keep filesystem and network interception only, dropping overhead below 1%. For production, we recommend keeping full audit enabled; 3% is a fair trade for complete traceability.

Production Security Checklist

Before running OpenClaw in production, walk through this checklist:

• Use a separate sandbox session per distinct task — never share sessions
• Version-control policy YAML; require code review on policy changes
• Keep ~/.ssh, Keychain, and Cursor/VS Code global storage on the deny list
• Default network policy to block_all_others: true; add allow-list entries as needed
• Set max_duration and idle_timeout to prevent unattended sessions
• Assign least-privilege roles; periodically review active tokens
• In CI/CD, use if: always() to export audit logs
• Configure BLOCK event alerts for anomalous behavior
• Export and archive all audit logs before decommissioning an instance

Bare-Metal Local Agents vs. Public Cloud — What's the Gap?

After working through this guide, a fair question is: why not run Agents directly on a MacBook, or spin up macOS on AWS? The comparison matters.

Running bare on a local MacBook gives the Agent the same system privileges as your primary development machine. One overreach and you are recovering your daily driver, not a disposable cloud node. You also lack independent audit logs to prove what the Agent did or did not touch — security teams rarely accept "I trust it" as a control. Practically, a laptop cannot run CI workloads 24/7, and sustained Agent tasks push fan noise and thermals into uncomfortable territory.

AWS EC2 Mac instances provide macOS, but entry pricing runs around $26/day on mac2.metal, and instances are virtualized rather than dedicated hardware — the Apple Neural Engine is not directly accessible to the guest OS, so much of the M4's 38 TOPS AI throughput goes unused. EC2 Mac also ships without built-in operation-level sandboxing or audit logs; you assemble third-party tooling yourself, adding cost and complexity. Minimum rental is 24 hours, which is awkward for day-scale experimentation.

GitHub Actions macOS runners bill per minute at roughly 10× the Linux rate, and you cannot define fine-grained security policies — jobs share the runner environment without per-task isolation. Queue times during peak hours often exceed 30 minutes.

ZilCloud takes a different path: dedicated Mac mini M4 hardware from $20.9/day, OpenClaw sandbox built in with no extra install, zero-trust access and full audit logs out of the box, 1–5 minute automated provisioning, five global regions, and 7×24 human support. You are not just renting a Mac that can run an Agent — you get an auditable, isolated, team-ready production environment. That is the foundation this guide's workflows are designed to run on.