InstaVM Coderunner

Checked: 2026-07-14

Summary

InstaVM Coderunner is an Apache-2.0 local execution sandbox for Apple Silicon Macs. It runs a Linux OCI image through Apple’s container runtime, where each container has its own lightweight virtual machine. A built-in MCP and REST service lets AI clients execute Python in persistent Jupyter kernels, browse web pages, and use packaged skills. Users can also install and run Claude Code directly inside the sandbox.

Despite the repository name, the current open-source project is mostly one persistent local execution environment rather than a full per-project coding-agent orchestrator.

Problem

Remote AI tools can generate useful code but running that code directly on a laptop exposes host files and installed software. Coderunner gives generated code a separate Linux VM and exposes controlled host folders for inputs, outputs, and optional user skills.

How It Works

• The installer sets up Apple’s container runtime and pulls the instavm/coderunner OCI image.
• It starts one named coderunner container with 8 CPUs and 4 GB memory.
• Only two host directories are mounted by the default installer: user skills and outputs under ~/.coderunner/assets.
• A FastMCP server listens at http://coderunner.local:8222/mcp.
• Python code runs in a pool of persistent Jupyter kernels with retry, timeout, and health checks.
• Additional MCP tools navigate pages with Playwright and expose built-in or user-defined skills.
• The container can stop and resume with installed packages, uploads, kernels, and agent state preserved. Deleting and reinstalling creates a clean environment.
• Claude Code can run inside an interactive container shell; a separate Claude plugin exposes Coderunner’s MCP tools to an agent running outside it.

Security Boundary

• Apple container runs each Linux container in a separate lightweight VM using macOS Virtualization.framework. This provides a dedicated guest kernel rather than a shared Docker-style Linux VM.
• The host filesystem is not broadly mounted by default. User-added volume mounts determine what guest code can read or change.
• The coderunner process runs as root inside the guest according to the documented shell prompt and image workflow. VM isolation protects the host, but guest files and mounted folders remain writable by sandbox code.
• Apple’s VM boundary reduces host risk but does not guarantee protection against hypervisor, kernel, runtime, image, or mounted-volume vulnerabilities.
• Coderunner’s repository has a vulnerability-reporting policy and incident-response plan, but no security threat model or audit report was found.
• The README’s claim of running multiple agents without fear of data loss or exfiltration is broader than the implemented controls: host isolation helps with local damage, but outbound internet access is not restricted by Coderunner.

Platforms and Agents

• Required host: Apple Silicon Mac and Python 3.10 or newer.
• Official Apple container support requires macOS 26. Coderunner’s installer warns on older macOS versions but may continue, even though Apple no longer supports those versions.
• Agents and clients documented: Claude Code, Claude Desktop, OpenCode, OpenAI Agents SDK, Gemini CLI, Kiro, and Coderunner UI.
• OpenClaw-style long-lived orchestration and Linux hosts are not currently supported.
• The roadmap lists Linux through Firecracker, external-action guardrails, and a dedicated CLI.

Setup

1. Clone the repository on an Apple Silicon Mac and run install.sh.
2. The installer may download and install Apple’s container package, requiring administrator approval.
3. It starts the container system, configures the .local container domain, creates host asset folders, pulls the image, and starts coderunner.
4. Connect an MCP client to http://coderunner.local:8222/mcp, or open a container shell and install Claude Code.
5. Stop and restart the named container to preserve state; delete it for a clean reset.
6. Place custom skills in the host skills folder and retrieve generated files from the outputs folder.

The installer pins Apple container 0.8.0 even though Apple had released newer versions by the check date. Confirm compatibility before installation.

Network and Credentials

• Coderunner does not document an outbound firewall, domain allowlist, proxy, or credential broker. Guest code appears to have ordinary internet access through Apple container networking.
• API keys used by a client-side OpenAI example remain in the host client process unless passed into guest code.
• Claude Code installed inside the sandbox must authenticate inside the guest; those credentials persist with the container and are readable by processes with sufficient guest access.
• The MCP endpoint and /execute REST route do not show application authentication in current server.py.
• DNS-rebinding protection restricts accepted host and origin names to localhost, loopback, and coderunner.local, but this is not user authentication.
• Anyone able to reach the execution service may be able to submit Python code. Users should verify interface reachability and add access controls before using it on untrusted or shared networks.
• Mounted user skills are executable trusted code; mounted outputs are writable from the guest.

Strengths

• Hardware-backed VM isolation through Apple’s native runtime.
• Simple persistent local environment for Python execution and document or image workflows.
• MCP support across several agent clients.
• Persistent Jupyter kernel pool reduces repeated startup and preserves Python state.
• Host files stay outside the guest unless mounted or copied in.
• Standard OCI image and an open Apache-2.0 repository.
• Built-in skills and user-skill discovery make repeatable local tools easy to expose.

Limits and Risks

• Apple Silicon and effectively macOS 26 only.
• No documented outbound filtering or exfiltration prevention despite README wording.
• The local network execution endpoint lacks visible authentication in current source.
• One shared persistent sandbox can mix state, credentials, and files across multiple agents or tasks.
• Default host mounts are not a project checkout; users must design project synchronization or add a mount, which widens access.
• Running Claude Code directly inside the container requires manual installation and authentication.
• The install script pins an older Apple runtime release and uses a prebuilt image whose build provenance users must assess.
• No snapshots, checkpoints, per-agent network policy, domain rules, or credential brokering are documented.
• Root inside the guest can fully alter guest state and mounted writable folders.
• Persistent state preserves compromise or unwanted changes until the container is deleted.

Activity and Maturity

• Repository created 2025-06-23.
• GitHub showed 869 stars, 40 forks, and no published releases.
• Latest repository push was 2026-05-16, primarily fixing stop-and-resume behavior.
• April 2026 changes added dependency security work, private vulnerability reporting, and an incident-response plan.
• The project has meaningful adoption signals but no versioned release channel or published audit.
• Apple container itself reached 1.0.0 in June 2026, while Coderunner’s installer remained pinned to 0.8.0.

Best Fit

• Apple Silicon users who want AI-generated Python or browser work to run away from host files.
• Claude Desktop, OpenCode, Gemini, Kiro, or OpenAI agent workflows that can call MCP tools.
• Local document, image, data, and web-processing tasks with explicit input/output folders.
• A persistent personal sandbox on a trusted machine and network.

It is not a strong fit for untrusted network users, strict data-exfiltration controls, per-project coding agents, Linux or Windows hosts, or workloads needing audited security guarantees.

Comparison Facts

Fact	InstaVM Coderunner	Clawk
Main workflow	Local MCP Python/browser execution; optional in-guest Claude	Disposable per-project coding-agent VM
Host	Apple Silicon macOS	macOS and Linux paths
Isolation	Apple lightweight VM per container	Apple virtualization or Firecracker VM
Project access	Default asset mounts; project workflow is user-defined	Project-oriented VM commands
Network	Ordinary access; no policy documented	Domain allowlist before outbound dialing
Credentials	Client-side or stored inside persistent guest	Agent credentials in project VM workflow
Parallel agents	Can share one sandbox; no per-agent manager	Multiple independent project VMs
Recovery	Stop/resume or delete/reinstall	Disposable lifecycle and suspend/resume
Control API	MCP and unauthenticated local REST execution	Local CLI and daemon workflow

Coderunner is simpler for tool-style code execution. Clawk is better aligned with full coding-agent sessions and explicit network containment.

Hacker News Context

In the Clawk thread, mkagenius said they made “the exact same thing” when Apple containers were released and linked Coderunner’s Claude Code section. Both use a local VM boundary on Apple Silicon, but their current interfaces differ: Coderunner centers one persistent MCP/Jupyter sandbox, while Clawk centers disposable project VMs and network allowlisting.

The HN comment is from the project author and is not an independent comparison or security review.

Unknowns

• Independent security audit, penetration testing, or published threat model.
• Exact host exposure of coderunner.local:8222 across macOS network configurations.
• Authentication plans for MCP and REST execution routes.
• Image signing, reproducible-build status, and update policy for instavm/coderunner.
• Timeline for Linux, Firecracker, guardrails, and a dedicated CLI.
• Whether multiple concurrent Claude sessions are isolated from each other’s guest state.

Sources

• InstaVM Coderunner repository and README
• Coderunner installer
• Coderunner server
• Coderunner security policy
• Apple container technical overview
• Apple container repository
• HN: Clawk discussion
• HN: Coderunner comment