Review Remote Mac Agent Work Before It Ships

Fully automated Mac agents are fast, but some workflows — publishing a release, sending bulk communications, mutating production data — carry enough risk that a human should look at the proposed output before it leaves the machine. This guide shows how to build that gate: the agent packages its evidence, the pipeline pauses in a protected environment, a named reviewer approves or rejects, and the job either proceeds or rolls back.

for most review-gated agents, run the workload on the Figment virtual Intel macOS instance at $29/month (2 vCPU, 8 GiB RAM, 80 GiB disk) and let GitHub Actions environments hold the ship step behind required reviewers. If the gated step must execute an Apple-silicon-only binary, run visionOS tooling, or needs GPU-accelerated work, request an M-series Mac from $95/month — the exact chip, RAM and disk are confirmed in the Figment quote. The i3 Mac at $49/month and physical M-series plans are request-based while supply is confirmed.

Choose a Mac plan and define the job

The first decision is which hosted Mac tier matches your agent's work:

The $29 virtual Intel macOS instance runs real macOS on Linux/KVM. It can host compatible Intel Mac toolchains — including supported Xcode 26 or earlier releases per Apple's porting guidance — and is well-suited to review-gated agents that call REST APIs, run CLI tools, diff state, and build the review packet itself. It has no GPU acceleration and no audio, and it cannot execute arm64-only binaries; choose an M-series Mac for those. Access is via the browser console; inbound SSH to the $29 VM is not currently offered, and outbound CI-runner agents still connect out to GitHub or your CI service normally.

Before writing any YAML, write down three things: what the agent produces, the blast radius if it ships a wrong result, and which named teammate is qualified to approve.

Inputs and required permissions

For a review gate to be meaningful, the agent must produce verifiable evidence — not a bare "done" flag. Establish:

• A change description the agent writes itself, structured so a reviewer understands intent without reading raw logs.
• Artifact references — file paths, object-storage URLs, or API diff responses documenting the proposed change.
• A run identifier generated at job start and reused as the idempotency key on any downstream system the agent pre-stages to.
• Reviewer identity — a named person or team configured as a required reviewer on the environment.

macOS's shortcuts CLI fits cleanly here. Per Apple's Shortcuts command-line reference, shortcuts run "GenerateReviewSummary" --output-path /tmp/review-summary.json exits 0 on success and 1 on error, and --output-type can force a specific UTI. The wrapper reads that file, assembles the review packet, and uploads it as a CI artifact.

Implement the concrete workflow

A two-job pipeline: Job 1 runs the agent and uploads a review packet; Job 2 is gated behind a protected environment that requires a named reviewer.

Job 1 — produce the review packet:

# .github/workflows/agent-with-review.yml
jobs:
  agent-run:
    runs-on: [self-hosted, mac]
    steps:
      - name: Run agent
        run: /usr/local/bin/run-agent-job.sh

      - name: Build review packet
        run: /usr/local/bin/build-review-packet.sh

      - name: Upload review packet
        uses: actions/upload-artifact@v4
        with:
          name: review-packet-${{ github.run_id }}
          path: /tmp/review-packet/
          retention-days: 7

Job 2 — human gate, then ship:

  ship:
    needs: agent-run
    runs-on: [self-hosted, mac]
    environment: production-review      # protected environment
    steps:
      - name: Download review packet
        uses: actions/download-artifact@v4
        with:
          name: review-packet-${{ github.run_id }}
          path: /tmp/review-packet/

      - name: Ship approved output
        run: /usr/local/bin/ship-output.sh

In repository settings, create the production-review environment and add required reviewers. GitHub's documentation notes you can add up to six people or teams and that only one required reviewer must approve for the job to proceed. Environments on private repositories require GitHub Pro or GitHub Team; public repositories are supported on all plans. Pending reviewer requests do not wait forever — set a Slack or email notification so the reviewer sees the request early, and check the current pending-deployment expiry in the GitHub docs rather than relying on a memorised number.

The review packet

The packet is the agent's structured case. A workable layout:

review-packet/
├── summary.md          # plain-language description of proposed change
├── diff.txt            # line-level diff or API response diff
├── evidence/
│   ├── before.json     # snapshot of relevant state before the agent ran
│   └── after.json      # proposed state the agent will commit on approval
├── links.json          # URLs to tickets, prior runs, staging previews
└── run-metadata.json   # run ID, timestamp, agent version, host name

summary.md should answer three questions in under 200 words: what did the agent intend, what did it actually produce, and what will ship-output.sh do if approved? A reviewer who can answer those in a minute gives fast, accurate approvals.

links.json example:

{
  "runId": "7842a1bc",
  "priorRunUrl": "https://github.com/org/repo/actions/runs/7842a1bc",
  "ticketUrl": "https://linear.app/team/issue/ENG-412",
  "stagingPreview": "https://staging.example.com/preview/7842a1bc",
  "artifactUrl": "https://storage.example.com/artifacts/7842a1bc"
}

Failure and recovery checks

Review-gated pipelines have three distinct failure modes:

• Agent-side failure (Job 1 fails). No packet, no gate, no ship. Inspect agent logs on the Mac, fix, re-run Job 1. Because Job 2 never ran, no downstream writes were made.
• Reviewer rejection (Job 2 declined). Any pre-staged work must be reversed. Keep rollback-output.sh <runId> alongside the ship script; it reads the idempotency key and undoes staged writes. Run it immediately — do not leave staged state around.
• Approval, then ship failure mid-way. Treat it like a network-interrupted job: reconcile by run ID before retrying, and make ship-output.sh idempotent so a replay is safe.

Have your reviewer practise a rejection once against a dry-run packet before trusting this in production.

A small worked worksheet: one review per workday

Say one agent runs each weekday and holds for human review. At 21 workdays per month, the hosted Mac costs $29 regardless of reviewer wait time — the Mac is billed by the month, not the active minute. If you upgrade to the Managed Build Mac to get monitoring and the 30 minutes of monthly support, the difference is $249 − $29 = $220/month, or about $10.48 per workday review. Judge that against the cost of a missed rejection in your workflow. Note that $29 is a monthly charge, not a daily rate: a two-week project still pays the full month.

If the agent pre-stages to an external system (staging DB, object store), include the holding cost of that staged state between agent completion and reviewer approval when comparing plans.

Start or migrate the workload

Request your plan, configure the self-hosted GitHub Actions runner on the Mac, create the production-review environment, and add the first required reviewer. The /mac-hosting/start page walks through requesting a plan and connecting a runner; the /mac-hosting overview lists the current plans and what each managed tier includes.

Start a hosted Mac at Figment → | Browse Mac hosting plans →

Related guides:

• Mac agent run audit
• Mac agent screenshot privacy
• Mac GitHub Actions self-hosted runner