clawk Puts Coding Agents in VMs

clawk is an Apache-2.0 open-source project from clawkwork that puts Claude Code, Anthropic's coding agent, Codex, OpenAI's coding agent, or a plain shell inside a disposable Linux VM. It deals with the awkward part of agentic coding: 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. The takeaway is simple: a real machine boundary is often a better training surface than endless command approvals. For anyone comparing the best ai code 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.

The trap is treating “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.

The trap is making 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 the related training topic.

Copy this clawk trial checklist

Use this as a small experiment, not a grand platform decision. One repo, one task, one afternoon.

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

• Is clawk safer than running Claude Code on my laptop?

  Yes, clawk gives the agent a stronger default boundary than a normal local shell because the work happens inside a disposable Linux VM. The important caveat is that your mounted repository can still be changed, so it reduces host exposure; it does not remove the need for review, backups, or secret hygiene.

• Why not just use a Docker container?

  Docker may be enough for many repos, especially when the project already has a containerized dev setup. clawk is interesting because it uses a VM boundary rather than a shared host-kernel container boundary, and it pairs that with network restrictions. The cost is more moving parts than a simple container command.

• Does clawk help choose the best ai code assistants for developer training?

  Yes, but indirectly: clawk gives every assistant the same constrained execution arena, which makes behavior easier to compare. In a training exercise, ask Claude Code, Codex, and Claude, Anysphere's AI code editor, to attempt the same fix, then compare commands run, network requests made, tests passed, and diff quality.

• 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.

• Is clawk ready for every production codebase?

  No, and that is fine. It is a young open-source project, so you should test it on a low-risk repository before trusting it with sensitive work. Look for boring signals first: repeatable startup, predictable mounts, clear network allow-list behavior, and clean recovery when a session is destroyed.

Best ways to use this research

• Best for: developers who want coding agents to run real commands without giving them the whole laptop. clawk is most compelling when the task needs package installs, test execution, or local servers.
• Best first artifact: the trial receipt above. It captures the boundary decisions that matter without turning the experiment into paperwork.
• Best comparison angle: compare execution behavior, not only final code. The useful questions are which commands ran, which hosts were requested, which tests passed, and what changed in the diff.
• Best limit to keep: do not mount secrets or broad host directories into the VM. If the agent needs credentials, pause and design that path deliberately.

Further reading

• clawk — source
• Claude Code — overview
• Claude — Agent
• OpenAI Developers — Codex quickstart

Try the boundary before the agent

Pick one boring repo, run one agent task through clawk, and write down every host and port the task actually needed. If that list surprises you, you learned something before the agent touched a more important codebase.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.