OpenClaw Sandbox in 5 Minutes: Give Your AI Agent an Isolated Cloud Mac

First question: why not run Agents directly on bare macOS?

Many teams start with "it's just a test—SSH into the cloud Mac and let the Agent work." The problem: modern Agent frameworks (LangGraph, AutoGen, Cursor Background Agent, and similar) execute tool calls as the current user— file reads, child processes, network access, all with the same boundary as your own terminal session. In an internal pilot we asked an Agent to scan a Swift repo and auto-fix compile warnings; on the third iteration it tried to read ~/Library/Keychains and ran security find-identity to "help find signing certificates." Reasonable intent—catastrophic on a build machine that holds Distribution certs.

Switching accounts or reimaging after every task is expensive; Docker on macOS cannot cover the full Xcode toolchain. OpenClaw's approach: the Agent still runs on real macOS (so xcodebuild and Apple Neural Engine work), but every system call passes through a policy engine first—deny on violation, log everything to audit. This article covers only the shortest path from zero to a working sandbox task; architecture, multi-user zero-trust, and CI wiring live in the OpenClaw Complete Guide.

Before you start: three things you need

You do not need a local Mac—a Windows or Linux laptop with SSH is enough. Confirm these three items before you begin, or you will stall mid-flow:

Cloud node: if you do not have one yet, pick region and term on the order page. All five nodes (Singapore, Japan Tokyo, South Korea Seoul, Hong Kong, US East) share the same hardware and pricing—choose by latency. SSH credentials appear in the console within 1–5 minutes after payment.
instance-token: generated the first time you enable OpenClaw under "Security & Sandbox" in the console; shown once—store it in your team secrets vault immediately.
Policy file: Section 4 below provides a copy-paste read-focused template; save it as ~/policies/quickstart-readonly.yaml.

Five-minute flow: from enable to first sandbox task

Timings below reflect what we measured. We repeated the flow five times on a Singapore node; once familiar, the full run took about 4 minutes 20 seconds. Budget 5–8 minutes on your first attempt. Each step has a clear acceptance check—do not advance until you see the expected output.

1. 01
   Minute 1: enable OpenClaw in the console

   Log into the PixVPS console → instance details → "Security & Sandbox" → turn on OpenClaw. Copy the instance-token into 1Password or Bitwarden. Done when: the page shows OpenClaw status as enabled.

2. 02
   Minute 2: SSH in and install the CLI

   Copy the SSH command from "Access info" in the console, log into the instance, then run the install script and authenticate. Done when: openclaw status shows Policy Engine, Sandbox Runtime, and Audit Bus all healthy.

3. 03
   Minute 3: write the minimal read-only policy

   Create ~/policies/, paste the YAML from Section 4. Run openclaw policy validate -f ~/policies/quickstart-readonly.yaml to check syntax. Done when: output reads policy valid with no path-conflict warnings.

4. 04
   Minute 4: create the sandbox and probe

   openclaw sandbox create --name quickstart --policy ~/policies/quickstart-readonly.yaml, then openclaw sandbox exec quickstart -- /bin/zsh -lc 'ls -la /workspace'. Done when: you see an empty workspace directory listing inside the sandbox, with no permission errors.

5. 05
   Minute 5: run the Agent entry script and tail audit

   Execute your Agent entry (or the sample script below) inside the sandbox. In a second terminal, run openclaw audit tail --sandbox quickstart --follow to watch live logs. When finished, openclaw sandbox stop quickstart. Done when: audit logs contain decision: allow and decision: deny entries (if the Agent hit blocked paths).

Minimal permission YAML: read-only code scan template

Quickstart rule: start strict, loosen later. The first policy should expose only what the Agent needs. The template below allows read/write on /workspace, runs git / rg / python3, blocks keychain and SSH paths, and denies all outbound network— enough for "clone public repo → static scan → write report" workflows.

Note: /workspace includes write access because the Agent must persist the scan report; for purely read-only tasks, change access to [read]. To pull code from GitHub, switch network.egress to allow-list and add github.com:443— the most common "step two" after quickstart. Full network whitelist patterns are in Section 5 of the complete guide.

Run your first Agent task: copy-paste entry script

Before wiring LangGraph or a custom orchestrator, validate the "policy + sandbox + audit" loop with a ~20-line shell script. Save the following as /workspace/agent-entry.sh on the host (the sandbox maps that directory automatically):

With egress: deny-all still in place, git clone will be blocked by network policy— that is intentional for the demo: tail audit and you will see a decision: deny network record. Add GitHub to the allow-list and rerun; you should see decision: allow and a successful summary.txt.

Run: openclaw sandbox exec quickstart -- /bin/zsh /workspace/agent-entry.sh. On our M4 node the script (including clone) took about 38 seconds; cumulative policy evaluation overhead was under 200 ms—negligible. When done, run openclaw sandbox stop quickstart to free the workspace; zombie sandboxes consume disk—the default per-instance cap is five concurrent sessions.

Three common blockers and one-line fixes

Almost everyone hits one of these on the first run. No need to dig through a long manual—use the table.

After the pilot: expand permissions and scale at your pace

A five-minute read-only sandbox is only the starting point. Real workloads often need xcodebuild, npm registry access, and a fresh sandbox on every CI push. That is "pilot to production" territory—finer policy tiers and audit export— covered chapter by chapter in the OpenClaw Complete Guide (advanced permission YAML, GitHub Actions wiring, and 90-day audit retention).

If you do not have a cloud Mac yet, alternatives each have trade-offs: a local laptop running Agents 24/7 burns power and cannot hold a fixed overseas IP; public-cloud macOS VMs lack native OpenClaw integration and operation-level audit; buying office Mac minis means hardware depreciation and ops headcount. PixVPS offers dedicated physical Mac mini M4 (16 GB unified memory, 38 TOPS, 1 Gbps dedicated bandwidth), OpenClaw built into every standard instance, 1–5 minute delivery, from $21.1/day— rent by the day for Agent experiments, move to $105.7/month when stable, more flexible than buying hardware for uncertain demand.

Suggested path: run the read-only sandbox today → tomorrow copy a policy template for your task type (build / doc fetch / ops patrol—see the comparison table in the complete guide) → week three commit YAML to Git and force openclaw audit export in CI. For parallel build Agents, one M4 with 16 GB reliably runs two sandboxes with DerivedData in our tests; for more parallelism, add Thunderbolt 5 clustering for an 80 Gbps multi-machine pool.