Give the agent a machine.
Just not yours.
Every AI coding agent gets its own Incus system container - root, Docker, systemd, and none of your credentials. Run one session by hand with Coi, or trigger, chain, and gate hundreds of them unattended with CoiPond.
MIT licensed From the maintainer of Karafka
Two ways in
Start with a single isolated session. Grow into unattended orchestration when you need it - CoiPond runs on Coi, so nothing is thrown away.
Coi available
The sandbox runtime. One binary, one command, and your agent has a full machine it can break without breaking anything of yours.
- ● Full system container: systemd, Docker, root, package managers
- ● Credentials stay on the host unless you forward them by name
- ● Threat detection with auto-pause / auto-kill and a JSONL audit log
- ● Three network modes, enforced with nftables
- ● Parallel slots, session resume, snapshots, profiles
curl -fsSL https://raw.githubusercontent.com/coipond/coi/master/install.sh | bash
coi build
coi shell
CoiPond coming soon
The orchestrator on top of Coi. Self-hosted infrastructure for running agent sessions unattended - and for the moments an agent gets stuck and needs a human.
Source and docs are being prepared for release. Watch the Coi repo for the announcement.
- ● Cron, webhook, chained, and manual triggers
- ● Multi-step workflows: AI task, shell, interactive, approval, sleep, sub-workflow
- ● Up to 10 parallel lanes per workflow, each in its own container
- ● Approval gates and blocked-session handling when an agent asks a question
- ● Live terminals streamed to the browser, status page, error tracking
- ● Agent-agnostic: Claude Code and Aider today, via a small adapter layer
Why Coi
Most sandboxes give the agent a cage. Coi gives it a machine - and watches what it does with it.
A real machine, not a container-shaped one
Incus system containers boot systemd, run Docker inside, and let the agent install packages, start services, and use cron.
sudo is fine - root is the container's root, not yours.
Your credentials never go in
SSH keys, env vars, git tokens, and .env files stay on the host unless you forward them by name.
Forward a host socket or mint a short-lived token per session instead of handing over the real thing.
Active defense, not just walls
Kernel-level nftables monitoring catches reverse shells, credential scanning, data exfiltration, and DNS tunneling.
HIGH threats pause the container; CRITICAL ones kill it. Everything lands in a JSONL audit log you can pipe to jq or a SIEM.
A network you actually control
restricted blocks private networks and allows the internet (default). allowlist resolves only the hosts you name and enforces it in the firewall. open is there when you mean it.
No permission hell
Automatic UID/GID mapping means files the agent writes are owned by you on the host - no chown rituals.
.git/hooks, .git/config, .husky, .vscode, and .claude/settings.* are mounted read-only against supply-chain tricks.
Built for how you actually work
Parallel slots for the same repo. Resume a session with its full history. Ephemeral or persistent containers, snapshots to checkpoint and roll back,
profiles like hardened for repos you don't trust, and coi run for any script - not just agents.
How it compares
| Coi | Docker Sandbox | Bare metal | |
|---|---|---|---|
| Credential isolation | Default - never exposed | Partial | None |
| Real-time threat detection | Kernel-level (nftables) | No | No |
| Automatic response | Pause / kill | No | No |
| Network isolation | 3 modes, firewall-enforced | Basic | No |
| Protected paths | Read-only mounts | No | No |
| Audit logging | JSONL | No | No |
| Runs on Linux natively | Yes - Incus is Linux-native | microVM isolation is macOS/Windows only | - |
No Docker Desktop, no vendor runtime, no nested VMs. Coi talks to Incus directly, and Incus is fully open source.
Both are open source under the MIT license. This page is a placeholder while the full site and documentation move here.