Incus

Checked: 2026-07-14

Summary

Incus is an Apache-2.0 system-container and virtual-machine manager. It is general infrastructure rather than a coding-agent product, but a Linux developer can use it to give each agent a separate VM, snapshot it, apply resource and network limits, and discard it after work.

Incus offers a local command-line client, REST API, reusable profiles, projects, storage pools, managed networks, image servers, and optional clustering.

Problem

Coding agents need broad control inside a development environment without receiving the developer’s full laptop identity. Incus supplies an established VM management layer, but the user must build the agent-specific workflow, credential policy, project transfer, and network rules.

How It Works

• The incusd daemon runs on Linux and manages system containers through LXC and virtual machines through QEMU.
• System containers share the host Linux kernel. VMs use hardware virtualization and a dedicated guest kernel.
• Images provide base operating systems. incus launch ... --vm creates and starts a VM.
• The Incus guest agent enables direct command execution, file transfer, and detailed metrics inside supported VMs.
• Profiles apply reusable configuration and devices to many instances.
• Projects group instances and can enforce counts, CPU, memory, process, disk, and other aggregate limits.
• Snapshots and copies support rollback, cloning, backup, and parallel agent environments.
• The REST API and command-line client make a small per-project automation script practical.

Security Boundary

• For coding-agent containment, use an Incus VM when a separate guest kernel is required.
• Unprivileged containers use Linux namespaces and user-ID mapping but still share the host kernel. Privileged containers weaken the boundary further and are discouraged by official guidance.
• Restricted projects can block security-sensitive features such as raw LXC configuration, risky devices, and nesting unless explicitly allowed.
• Network access-control lists can enforce ingress and egress rules. Applying an ACL adds default reject behavior unless changed.
• Local access to the Incus Unix socket grants full Incus control, including mounting host paths and changing instance security. The official docs say such access should be treated like root access.
• Members of incus-admin have full API access. The less-privileged incus group can be restricted to a user-specific project.
• Incus is a strong building block, but a VM still needs secure guest configuration and carefully limited host mounts, network access, and credentials.

Platforms and Agents

• Incus daemon: Linux only.
• Incus client: available on most platforms, including documented Windows installation.
• Managed VM guest agent: Linux, Windows, macOS, and FreeBSD guests.
• Coding agents: no built-in agent integration. Claude Code, Codex, Gemini, Pi, or another agent must be installed in the chosen image or by provisioning scripts.
• Hardware virtualization and QEMU 8.2 or newer are required for VMs in current documentation.

Setup

1. Install a supported Incus package on a Linux host. Production users should prefer the 6.0 long-term support branch; feature users receive monthly 6.x/7.x releases.
2. Initialize storage and networking, then restrict daemon access.
3. Create a restricted project and set instance and resource limits.
4. Create a reusable VM profile with CPU, memory, disk, network, and device policy.
5. Launch a Linux VM from an official image and install the preferred coding agent and tools.
6. Transfer or clone the project, create a baseline snapshot, and run the agent with incus exec or through a guest shell.
7. Restore the snapshot, copy the VM, stop it, or delete it when the task ends.

The exact provisioning script is user-owned; Incus does not supply a one-command coding-agent workflow.

Network and Credentials

• Managed bridge and OVN networks support access-control lists for ingress and egress.
• ACL rules can match addresses, protocols, and ports; unmatched traffic is rejected by default once ACLs are applied unless the default action is changed.
• Network logging is available for selected ACL rules.
• Incus network controls are address and port policy, not HTTP payload inspection or credential brokering.
• Agent credentials must be installed inside the guest, mounted, fetched from a separate secret system, or injected by user automation. Incus has no agent-specific placeholder-token proxy.
• The remote API uses JSON over HTTPS with TLS client certificates or OpenID Connect. Authorization options include project-restricted TLS clients, OpenFGA, and scriptlet authorization.
• Remote API access is disabled by default. Local socket or remote client credentials must not be given to an untrusted agent, because they could provide control over other instances or host mounts.

Strengths

• Dedicated-kernel VMs provide a stronger boundary than normal local containers.
• Mature image, storage, network, snapshot, copy, backup, project, and resource-limit features.
• Local and self-hosted: source code need not enter a third-party sandbox service.
• Profiles and the API make repeatable per-agent environments possible.
• Supports both lightweight containers and stronger VMs in one manager.
• Projects and authorization can separate users, teams, and agent fleets.
• Long-term support branch exists for production stability.

Limits and Risks

• Incus is infrastructure, not an agent workflow. Users must create provisioning, cleanup, credential, logging, and source-sync automation.
• The daemon runs only on Linux, so direct macOS use needs a separate Linux host or nested setup.
• VMs consume more memory, disk, and startup time than containers.
• Network ACLs do not inspect HTTP content, prevent data hiding in allowed services, or keep API keys outside the guest.
• Any writable project shared with the agent can still be damaged.
• Unix-socket, daemon-group, or remote API access is root-equivalent or broadly privileged unless carefully restricted.
• Snapshots are stored with the instance and are not a substitute for an off-host backup.
• Container mode shares the host kernel and should not be described as VM-equivalent isolation.
• Incus 7.2 fixed multiple critical host-impacting vulnerabilities in June 2026, including malicious-image and restricted-project bypass issues. This makes prompt patching and supported versions part of the security boundary.

Activity and Maturity

• Current feature release: Incus 7.2, released 2026-06-26.
• Current long-term support branch: 6.0.
• Official documentation was updated through July 2026 and recommends supported versions and current security patches.
• The project documentation carries a 2014–2026 contributor copyright, and Incus has regular feature and security releases.
• Compared with new agent-specific wrappers, Incus is mature infrastructure. Its coding-agent use is a community pattern, not an officially packaged feature.
• Recent critical security fixes show both active maintenance and the risk of granting management software deep host privileges.

Best Fit

• Linux developers or teams already comfortable managing VMs and networks.
• Users who want local, self-hosted agent isolation without trusting a new agent-specific wrapper.
• Repeatable agent farms that need snapshots, resource quotas, API control, or clusters.
• Workloads that require a dedicated guest kernel and can tolerate VM overhead.

It is less suitable for someone seeking a turnkey one-command agent experience, native laptop-only macOS operation, or built-in secret brokering and request inspection.

Comparison Facts

Fact	Incus	Clawk
Product type	General VM/container manager	Coding-agent VM tool
Host daemon	Linux only	macOS and Linux paths described by Clawk
Isolation	User chooses container or VM	VM-focused
Agent setup	User provisions agent and workflow	Agent-oriented commands and defaults
Network	Bridge/OVN ACLs by address, protocol, port	Domain allowlist in userspace forwarding
Credentials	User-designed	Project VM workflow; no broker documented in HN
Recovery	Snapshots, copies, backup, restore	Disposable VMs and suspend/resume
Scale	Projects, limits, API, clustering	Local project orchestration
Maturity	Established infrastructure with LTS	New agent-specific project

Incus gives more infrastructure control and maturity. Clawk removes setup work and centers the interface on coding agents.

Hacker News Context

In the Clawk discussion, JeremyNT said they jail coding agents with shell access inside VMs and use Incus as the VM management layer on Linux. They described it as simple enough to customize with a small script and preferred relying on established infrastructure rather than another third-party agent wrapper.

Clawk’s author asked what the setup looks like and whether it applies network filtering. No answer was posted in that reply chain. This is important: using an Incus VM does not automatically define safe outbound network or credential policy. A separate commenter mentioned Containarium as an LXC and eBPF approach, which is a different project.

Unknowns

• The HN commenter’s exact provisioning, network filtering, credentials, and source-transfer workflow.
• A maintained official Incus profile specifically hardened for coding agents.
• Independent evidence comparing an Incus agent VM with Clawk’s default security settings.
• Operational cost on the user’s hardware; Incus itself is free software.

Sources

• Incus overview and documentation
• Containers and VMs
• Installation and release branches
• Create instances
• Projects and restrictions
• Network ACLs
• Remote authentication
• Authorization
• Snapshots and backup
• Incus release news
• HN: Clawk discussion
• HN: Incus comment