Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

Original Article ↗ Hacker News Discussion ↗

Giving AI coding agents their own disposable Linux VMs instead of direct access to a developer’s machine is emerging as a preferred way to limit damage from bugs, prompt injection, and supply-chain attacks. Commenters compare Clawk’s VM-based approach to Docker containers, OS-level sandboxes, and a growing ecosystem of similar tools, weighing trade-offs between security, performance, configurability, and ease of use across macOS and Linux. Many argue that simple sandboxes are now commoditized, and that the harder, more important problems are network policy, credential management, rollbacks, and scalable remote environments.

Why VMs instead of containers or separate users

  • Many argue containers share the host kernel and rely heavily on its correctness; VMs provide a smaller, clearer isolation boundary.
  • Counterpoint: if containers are properly configured, any breakout is still a kernel bug; some see containers as “good enough,” especially with extra hardening (gVisor, Firecracker, Kata, eBPF).
  • Using a separate non‑sudo user is proposed as simplest and most portable, but others note this still shares host packages, daemons, and world‑readable files, and is easy to misconfigure.
  • Some prefer VMs because they behave like “real Linux boxes” where Docker, Kubernetes, etc. run naturally, avoiding Docker‑in‑Docker hacks.

Security & threat models

  • Concerns go beyond “avoid rm -rf /”:
    • Supply chain attacks via npm/pip/cargo and untrusted repos.
    • Prompt injection making agents run privilege escalation or exploit LPEs.
    • Agents installing hostile packages or abusing local services.
  • Some users split their world into a trusted host (only distro packages) and disposable VMs for everything else.
  • Others think VMs are overkill if you don’t assume a hostile agent; they prefer simpler user or container isolation.
  • VM escapes are also acknowledged; people stress keeping kernels updated.

Networking and firewall controls

  • Several tools focus on strict network allow‑lists, per‑domain or protocol‑aware policies, and application‑level proxies.
  • One implementation uses a user‑space network proxy (e.g., gvproxy) that terminates guest connections and re‑dials host sockets, applying an allow‑list there.
  • On Linux, TAP devices may still require root, but filtering logic can remain in user space.
  • Others experiment with eBPF, nftables, or MITM proxies to control outbound traffic and protect secrets.

Alternative sandboxing approaches

  • Wide range of options discussed:
    • Full VMs (Firecracker, KVM, QEMU, Nix microVMs, incus, quickemu, Vagrant).
    • Containers and nspawn (Docker, Podman, systemd‑nspawn, LXC).
    • “Almost containers” and namespaces (bubblewrap, Landlock, Firejail, bwrap‑based tools).
    • Remote CI/dev platforms and cloud sandboxes (various hosted offerings, some with macOS).
  • Several projects emphasize: declarative config, per‑project sandboxes, secrets control, snapshot/rollback, diff/apply workflows, MCP integration, and credential injection.

Local vs cloud sandboxes

  • Some prefer local VMs for “local‑first,” company‑policy compliance, and lower trust in third parties.
  • Others prefer remote sandboxes so their laptop can sleep while agents keep running, and to keep agents air‑gapped from personal machines.
  • Cost vs owning a dedicated dev box (e.g., a Mac mini) is debated.

Performance and ergonomics

  • On macOS, file I/O and process supervision overhead are said to slow agent workloads; running agents inside Linux VMs can be significantly faster.
  • Some highlight instant‑start namespace sandboxes as lighter than full VMs or containers.
  • Common usability needs: multi‑repo workspaces, persistent history, network scoping, easier auth reuse, and clean ejection from the tool.

Skepticism and meta‑discussion

  • Many note there are “dozens” of overlapping projects; some see this as needless wheel‑reinvention, others as healthy experimentation and desire for full ownership of code.
  • Critiques focus on missing higher‑level pieces: policy engines, configuration management, rollback strategies, dynamic credential management, and service proxies.
  • There is interest in an integrated “agent platform” where sandboxing, policy, secrets, and observability are all first‑class, rather than yet another bare sandbox.