clawk Puts Coding Agents in VMs
clawk is an Apache-2.0 open-source project from clawkwork that puts Claude Code Codex or a plain shell inside a disposable Linux VM. Useful agents need to install packages, run tests, start servers, and touch the network, but your laptop is a terrible place to discover what they can do. A real machine boundary is often a better training surface than endless command approvals. For anyone comparing the coding assistants for developer training, clawk is a useful reminder that the assistant is only half the lesson; the execution boundary teaches the other half.
As of July 13, 2026, the repository had 296 GitHub stars, was mostly Go, and described itself around disposable, network-restricted Linux VMs for AI coding agents. The project showed up on Hacker News because it names a pain many developers now recognize: either babysit every command, or let an agent run with broad local permissions and hope nothing weird happens.
Give the agent a machine you can throw away
clawk is a local VM launcher for coding agents. You cd into a repository, run clawk, and the agent works in a Linux guest with your code mounted in, root inside the guest, and your host files, keychain, and local environment outside the normal blast radius.
A disposable VM is a short-lived operating system instance you can destroy after the task, instead of trusting a process running directly on your workstation. That matters because coding agents are not just autocomplete anymore. They execute commands, follow instructions from files, install dependencies, and sometimes make network calls you did not expect.
A realistic Claude Code workflow might look like this:
cd ~/src/inventory-api
clawk
# inside the VM-backed session, ask Claude Code to run tests and fix failures
The nice part is not that the agent becomes magically safe. It is that the failure mode changes. If a dependency script writes into /tmp, modifies system packages, or tries to inspect the home directory, it is doing that inside the guest, not across your actual laptop.
Don't treat “disposable” as “careless.” Your repository is still mounted. A bad edit can still land in your working tree. You still review diffs, keep secrets out of repo files, and avoid mounting extra host paths just because it is convenient.
Why the network allow-list is the sharp edge
The most interesting clawk detail is not only the VM. It is the network posture. The project is pitched as network-restricted: unknown outbound connections are blocked unless you allow them.
That is a better default for agentic coding than “the internet is probably fine.” A coding agent fixing a failing integration test may need api.example.com, a package registry, or a local service. It probably does not need to post data to a random host mentioned in a README, generated script, or poisoned dependency instruction.
The workflow the README highlights is small and memorable:
clawk network allow my-project api.example.com
clawk forward add my-project 3000
clawk attach my-project
That shape is useful for ai engineering training because it makes permissions visible. A developer learns to ask, “What host should this task need?” before granting access. That is a better habit than clicking approve on a command transcript after the agent already decided what to do.
Don't make the allow-list so broad that it stops meaning anything. *.example.com may be reasonable for a controlled internal environment. * is just vibes with extra steps.
The Docker objection is fair
The first obvious question is: why not Docker? It is a fair objection. Containers are familiar, fast, scriptable, and good enough for a lot of development tasks.
clawk’s answer is that a VM gives a harder isolation boundary than a normal container. A container shares the host kernel. A VM runs a separate guest kernel. That does not make VM escape impossible, but it moves the project out of the “please respect this namespace” category and into a boundary most developers already understand from cloud and CI systems.
That distinction is why the project got attention. People are becoming less comfortable giving coding agents direct access to their workstation, but they also do not want to return to a permission prompt every few seconds. clawk aims at the middle: fewer prompts inside the guest, stricter boundaries around the guest.
The tradeoff is weight. VMs can be slower to start, need more orchestration, and may not match every local development assumption. If your project already has a tight devcontainer, no secrets, and narrow network needs, Docker may be perfectly fine. If your agent regularly installs system packages or runs unknown scaffolding tools, the VM starts to look less fussy.
Try it on a boring repo first
The best first clawk test is not your production monorepo. Pick a small service with ordinary tests, a local server, and one known external dependency. Let the agent do real work, but make the boundary easy to inspect.
For Claude Code users, keep the repository memory boring too. A concise CLAUDE.md can say which test command to run and which directories are off-limits, but do not use it as the security boundary. Prompt rules are guidance. The VM and network rules are the boundary.
A useful slash-command-style task is this:
/fix-tests
Run the smallest relevant test command first.
If a network request is blocked, stop and explain the hostname and why it is needed.
Do not add new dependencies without showing the package name and reason.
That command works because it turns clawk’s constraints into a learning loop. The agent can still act, but blocked access becomes a teaching moment instead of a surprise.
This is where clawk fits naturally into ai developer training. Do not ask new developers only to compare models by code quality. Ask them to compare what each assistant tries to execute, what network access it asks for, and how cleanly it recovers when the environment says no. For more on this wider skill area, see AI coding governance.
Copy this clawk trial checklist
Use this as a small experiment, not a grand platform decision. One repo, one task, one afternoon.
| Check | Good fit | Not fit yet |
|---|---|---|
| Repo shape | Small service, library, or CLI with clear tests | Huge monorepo with fragile local setup |
| Agent task | Fix tests, add a small endpoint, update dependencies | Migrate auth, rotate secrets, rewrite deployment |
| Network need | One or two known hosts | Unknown browsing, scraping, or broad SaaS access |
| Host exposure | Only the repo is mounted | Home directory, SSH keys, cloud config, or keychain needed |
| Review habit | Diff reviewed outside the agent session | Agent commits are trusted because the VM existed |
Copyable starter receipt:
clawk trial receipt
repo:
task:
agent used: Claude Code / Codex / shell
allowed hosts:
forwarded ports:
blocked request worth investigating:
test command run:
diff reviewed outside VM: yes / no
keep using clawk for this repo: yes / no / unsure
This is also a clean skills checklist for developer ai training. The point is not to crown one assistant. The point is to train the reflexes that make coding agents usable: isolate execution, name required network access, keep secrets off the path, and review the patch after the agent is done.
For a companion note on the same project, see Clawk Gives Coding Agents a Throwaway VM.
Common questions
Can I use clawk with MCP servers?
Yes, but treat MCP access as another permission surface, not as harmless context. If a Model Context Protocol server can read GitHub issues, database records, or internal docs, write down whether the VM session actually needs it. Start read-only where possible, and keep credentials outside the mounted repo.