sricola/drydock

<p align="center"> <img src="site/logo-512.png" alt="drydock" width="160"> </p>

drydock

<p align="center"> <img alt="status: alpha" src="https://img.shields.io/badge/status-alpha-orange"> <img alt="version" src="https://img.shields.io/github/v/tag/sricola/drydock?label=release&color=brightgreen"> <img alt="platform" src="https://img.shields.io/badge/platform-macOS%2026%2B%20·%20Apple%20silicon-black"> <img alt="license" src="https://img.shields.io/badge/license-MIT-blue"> </p>

drydock runs autonomous coding agents (Claude Code or OpenAI Codex, per-task selectable) on your own Mac — not someone's cloud — each task sealed in its own hardware-isolated VM. It starts from the assumption that the agent is already compromised: your real API key never enters the sandbox (a host-side gateway hands it short-lived, budget-capped tokens), egress is deny-by-default, and the only thing that crosses back out is a git diff you approve before it reaches origin.

Most agent tooling tries to keep the agent well-behaved — permission prompts, output filters, policy. drydock takes the opposite stance: contain the blast radius so a hostile agent (a poisoned repo, a malicious dependency, a prompt-injection that turns a fetched URL into a shell command) can't reach your key, your filesystem, your push credentials, or the open internet — regardless of what it tries.

Status: working alpha (v0.1.6). The full task lifecycle works end-to-end — submit → isolated VM → gated diff → push — and drydock ships through a Homebrew tap. It is pre-1.0 and single-maintainer: only main is supported, behavior and config can change between minor versions, and it hasn't been hardened by real-world use. There has been no third-party security audit — the security model is written down in detail in the threat model, so read that and decide for yourself before trusting it. Hard requirement: macOS 26+ on Apple silicon —