offstage Review: A Second Mac Desktop, Just for Your Agents

What Is offstage?

It turns one Mac into two desktops for the purpose of agent testing. A second macOS user account is created and logged in behind your own session; the agent's computer-use work — opening the app it built, launching Simulators, running XCUITest — happens on that account's desktop. Your screen, cursor, and keyboard stay with you. The tool ships as an MCP server, a Claude Code plugin, and a CLI, so the routing works whether you drive the agent from Claude Code, Codex, opencode, or raw shell commands.

How Work Gets Routed to the Second Account

Routing is rule-based and explicit. xcodebuild, xcrun simctl, XCUITest runs, open -a, osascript, and freshly built .app bundles open on the computeruse desktop. Headed browsers, Cypress, and WebGL work can be diverted into a Linux container with a virtual display if Docker is installed, and headless tests simply run in place. Two hard refusals matter for safety: installers (.pkg, .dmg, hdiutil) are refused because both accounts share one machine, and it refuses to run when the helper account would be the console user.

• Agent-built apps open on the helper desktop
• Simulators and XCUITest run off your screen
• Headed browsers can move to a Docker virtual display
• Installers refused; console-user execution refused

A Second Account, Not a Virtual Machine

The design is deliberately not a VM. The helper account shares the same CPU, memory, disk, and kernel as your account, which is why overhead is low and install is instant — but also why it is not an isolation boundary. The agent can read whatever macOS lets any local account read, though it cannot write to your files: sharing is read-only by design. Teams that need strong sandboxing should pair it with a real VM; teams that need cheap, screen-off GUI testing get exactly that.

• Shares CPU, memory, disk, and kernel with your account
• Low overhead, instant setup, no downloaded image
• Read-only share protects your files from writes
• Not a substitute for a VM when hard isolation is required

Claude Code, Codex, and opencode Integration

Setup is the same shape across agents. Claude Code adds the MCP server with one npx command or via the bundled plugin; Codex declares the server in config.toml; opencode lists it as a local MCP in opencode.json. Anything that can run shell commands can use the CLI directly. The docs recommend a doctor command to verify the helper account, permissions, and display state after setup, which keeps the environment honest before a long test run.

• Claude Code via MCP server or plugin
• Codex via config.toml MCP declaration
• opencode via local MCP entry
• Plain CLI for any shell-first automation

Input Safety and File Privacy

The core safety claim is semantic isolation of input: the daemon posts input only to its own session and refuses to act when that session is the console user, so the agent can never click on the screen you are using. File access is asymmetric by design — the helper account can read what macOS exposes to local accounts but the read-only share prevents writes into your files. That asymmetry is the product's privacy story: visibility without mutation.

• Input posted only to the helper session
• Cannot control the console user's screen
• Read-only mount for shared files
• Visibility without write access

What offstage Adds That Other Isolation Tools Miss

VMs give real isolation but cost a heavy download, GPU-sharing friction, and per-boot overhead; sandbox-exec wrappers protect the filesystem but leave GUI testing, Simulators, and Xcode UI tests undrivable. It sits in the middle: a real second session with a real desktop, near-zero setup, and Apple-native support for the tools iOS and macOS developers actually test with. The read-only share and installer refusals address the two ways an agent makes irreversible messes — writing your files or installing system-wide software.

• Real second desktop without VM cost or download
• Apple-native Xcode, Simulator, and XCUITest support
• Read-only sharing plus installer refusal
• Beats both pure sandboxes and heavyweight VMs

Platform and System Requirements

The requirements are specific: a Mac on Apple Silicon with Node 20 or newer, and one sudo command to set up the helper account and its permissions. A Docker install is optional but unlocks the headed-browser lane. Because everything is local, there is no cloud dependency and no account. The screenshots on the site show the computeruse desktop running a real app under test while the console session keeps an unrelated window — proof the split works on current hardware.

• Apple Silicon and Node 20+ required
• One sudo command for helper setup
• Optional Docker for headed browser lane
• Fully local with no account or cloud dependency

Alternatives to offstage

In this directory, [Harden](/tools/harden) guards agent commands rather than isolating their GUI, [Catenary](/tools/catenary) orchestrates several agents visually, and [Replay QA](/tools/replay-qa) automates web-app testing without a Mac desktop split. Externally, SandVault runs agents under sandbox-exec in a macOS user account with stronger filesystem guards but no GUI lane, GhostVM and similar tools ship full macOS VMs at the cost of gigabytes, and Docker containers cover headless Linux work. It is the only one that keeps a live second desktop native to macOS tooling.

• Harden — command gating, not GUI isolation
• Catenary and Replay QA — orchestration and web testing
• SandVault — stronger sandbox, no GUI lane
• GhostVM and macOS VMs — full isolation at real cost

Pricing & Plans

Free and MIT licensed. Install via npm with @viraatdas/offstage; requires macOS on Apple Silicon with Node 20+. Optional Docker lane routes headed browsers into a Linux container with a virtual display.

Best For

Recommended use cases and scenarios where offstage shines.

Frequently Asked Questions

Common questions about offstage, answered.