Give your coding agent its own Linux machine.

Each task gets a fresh microVM on your Mac, with its own kernel, no network, and no host folders mounted. It is ready in 299 ms, sized to the job, and hands back a patch you review before anything touches your checkout.

brew install baires/tap/dynocap

299 ms is the median warm boot on one Apple Silicon Mac, after setup. How we measured

  1. Copy your project

    dynocap clone . demo

    Imports the current directory into a disposable workspace.

  2. Run code inside

    dynocap exec demo -- uname -a

    Runs in the Linux guest. Output returns to your terminal.

  3. Review the changes

    dynocap diff demo

    Shows the patch for anything you or your agent changed.

  4. Export and clean up

    dynocap finish demo

    Saves the patch and logs, then destroys the sandbox.

Your host directory is never mounted into the guest.

One task, start to finish.

Recorded in real time on an Apple Silicon Mac with DynoCap already set up. The typing is scripted; every pause after Enter is the command running. Watch the last line: the file on your Mac never changed.

Show the commands
  1. cat README.md
  2. dynocap clone . demo
  3. dynocap exec demo -- uname -sr
  4. dynocap exec demo -- sed -i 's/from the host/from a microVM/' README.md
  5. dynocap diff demo
  6. dynocap finish demo
  7. cat README.md
  1. cat README.md
  2. dynocap clone . demo
  3. dynocap exec demo -- uname -sr
  4. dynocap exec demo -- sed -i 's/from the host/from a microVM/' README.md
  5. dynocap diff demo
  6. dynocap finish demo
  7. cat README.md
Watch the 20-second recording

Fast enough to throw away.

A clean microVM for every task costs less than a third of a second, so there is no reason to reuse a dirty one. Copying a whole repository in takes about one.

  1. 11ms

    Next command in a running microVM

    dynocap exec

    Median, after run returned

  2. 299ms

    Fresh microVM, ready for commands

    dynocap run

    Median of 6 runs

  3. 491ms

    Small project copied in and ready

    dynocap clone

    One-file directory, shell:1, 3 runs

  4. 989ms

    This repository copied in and ready

    dynocap clone

    387 files, shell:1, 2 runs

Warm starts, measured on one Mac.

Measured on one Apple Silicon Mac on 13 November 2026, with the daemon already running and artifacts prepared. The raw microVM used 1 vCPU, 1024 MB RAM, and a warm page cache, after one warmup. Project measurements used a prepared shell:1 runtime. These are observed medians, not guarantees. First installation, runtime preparation, and dependency installation are excluded.

A separate kernel between the agent and your Mac.

Let the agent install, delete, and run whatever it needs. It is working on a copy, inside a virtual machine, with the doors closed.

Read the security boundary
On your MacInside the microVM

Your checkout

A copy in a disposable workspace. Your directory is never mounted into the guest.

Your network

No network device at all, unless you choose filtered registry access or NAT for that task.

Your kernel

A separate Linux kernel under Apple’s Virtualization framework, not a container sharing yours.

Your decision

finish exports a patch and logs, then destroys the microVM. Nothing is applied until you apply it.

These are concrete isolation features, not a claim of absolute security. Files you import can still contain secrets, and filtered or NAT access reaches real systems.

Every limit is a flag.

Pick the toolchain, resources, network, and lifetime for each task. The same options work from the CLI, the TypeScript SDK, and MCP.

dynocap clone . fix-auth --runtime node:24 --cpus 4 --memory 4096 --network filtered --ttl 900
  • --runtime node:24

    Toolchain

    Node, Python, Go, or a plain shell, detected from your project files and attached read-only.

    • node 24
    • node 22
    • python 3.14
    • go 1.27
    • shell 1
  • --cpus 4 --memory 4096

    Resources

    Virtual CPUs and RAM for each task, so a heavy build gets room and a quick check stays small.

  • --network filtered

    Network

    Off by default. Filtered allows HTTPS to the runtime’s registry and Git host only. NAT opens outbound access when a task truly needs it.

  • --ttl 900

    Lifetime

    30 seconds to 24 hours, counted from creation. Activity never extends it, so nothing lingers.

Every option in the CLI reference

Tools for the agent.
A skill for the workflow.

Connect your coding assistant through MCP, then give it the DynoCap skill. The server hands it a machine. The skill tells it how to behave inside one.

MCP gives it the tools.

Let Claude Desktop, Cursor, or Cline start a task, run commands, inspect the diff, and export the result through the local daemon. The agent cannot turn on networking unless you allow it on the host.

  • dynocap_task_start
  • dynocap_task_exec
  • dynocap_diff
  • dynocap_task_finish
Connect the MCP server

The skill teaches it the rules.

Give your agent the repository’s DynoCap skill: prefer MCP when connected, work in the copied workspace, ask before enabling network access, and finish before the TTL expires.

skills/dynocap/SKILL.md

Copy the folder into .agents/skills/ or your agent’s own skills directory. It works with the CLI too; MCP is optional.

Read the DynoCap skill

Working directly? Use the CLI or build DynoCap into your own agent loop with the TypeScript SDK.

  1. Your terminal

    Use clone, exec, shell, diff, and finish. Keep your editor and the terminal you already use.

    Read the CLI reference
  2. Your application

    Create tasks, execute commands, and collect results from your own agent loop through the local daemon.

    Use the TypeScript SDK

The TypeScript SDK and MCP server are built from this repository. Their guides include the local setup; a public npm install is not available yet.

Set up once.
Then every task is one command.

Install with Homebrew, then let doctor prepare the guest image and your project’s runtime. After that, each task starts with clone.

Full installation guide

Project tasks need an Apple Silicon Mac with macOS 13 or newer. The installation guide lists everything doctor prepares.

  1. Install DynoCap

    Homebrew installs the CLI and its companions, and this command trusts the formula. For a later short-name upgrade, run brew trust --formula baires/tap/dynocap. Prefer another route? Use curl or build from source.

    brew install baires/tap/dynocap
    Use curl or build from source

    Install with curl

    curl -fsSL https://dynocap.dev/install.sh | sh

    Build from source

    From your DynoCap source checkout, with the build prerequisites installed:

    ./scripts/build-macos.sh
    export PATH="$PWD/.build/release:$PATH"
    Source build guide
  2. Prepare your project

    Replace the path with your project. Doctor builds the guest image, prepares the detected runtime, and checks the daemon.

    cd ~/code/my-app
    dynocap doctor --fix

First preparation downloads verified inputs and can take a few minutes. Run dynocap doctor whenever you need to check your setup.

Next: run your first project task

Your next task starts here.

Get started

Install DynoCap. Prepare your project. Give the next task its own machine.
DynoCap is Apache-2.0 and runs locally on your Mac.

Read the documentation