clawk Runs Coding Agents in Disposable VMs

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

clawk is clawkwork's open-source Go project for running coding agents inside disposable, network-restricted Linux VMs instead of on your laptop. The awkward middle ground between approving every command and giving an agent broad access to your machine. If an agent needs to install packages, run tests, start servers, and touch the network, put a real boundary around it. The coding assistants for developer training still need a safe lab, not just better prompts.

As of July 2026, the repository has about 296 GitHub stars, an Apache-2.0 license, and topics that make its intent plain: agent sandboxing, microVMs, Claude Code, Codex, and AI agents. That is small-project territory, not infrastructure canon. But the idea landed because it names a pain many agentic coding users already feel.

Give the agent a machine you can throw away

The pitch in clawk's README is wonderfully blunt: give the coding agent its own disposable Linux machine, not yours.

The project starts from a real workflow problem. Claude Code OpenAI Codex, and similar tools are most useful when they can do real developer work: install dependencies, run the code they wrote, open a local server, and inspect failures. But those are exactly the actions that make people nervous on a personal workstation full of SSH keys, browser cookies, cloud credentials, and half-finished projects.

clawk is a disposable VM wrapper for coding-agent sessions. Your repository is mounted into the guest. The agent gets root inside that guest. Your keychain and the rest of the host stay outside the boundary.

The concrete workflow is intentionally boring:

cd my-project
clawk

From there, the agent works in the VM. If it needs a local web port, the README shows a forwarding shape like this:

clawk forward add my-project 3000

If it needs a known external API, the network allow-list is explicit:

clawk network allow my-project api.example.com

And if you need to come back later:

clawk attach

That is the interesting bit. The safety boundary is not a sentence in a prompt that says please be careful. It is a separate machine with a smaller set of openings.

Notice what Hacker News cared about

The reaction was not just nice-project applause. Clawk removes a familiar tax from AI coding work: babysitting permission prompts.

Most agent workflows end up with two bad modes. In the first, the agent asks before every meaningful command, and you become a human modal dialog. In the second, you bypass permissions because you want momentum, then hope the agent does not delete the wrong path or exfiltrate a token.

clawk offers a third shape. Let the agent move quickly, but inside an environment designed to be disposable.

That matters for ai engineering training too. Beginners do not only need to learn which prompt to send. They need to learn where the command runs, what secrets it can see, what network it can reach, and how to review the diff after the agent is done.

This is also why clawk belongs near AI coding governance, even though the project itself is refreshingly practical. It is not a policy document. It is a small working answer to a policy problem: what should a coding agent be allowed to touch?

Do not confuse a VM with magic

The most useful objection in the discussion was the obvious one: why not just use Docker?

For many jobs, a container is enough. If you are running tests for a throwaway toy app, a Docker container with a bind mount and no secrets may be fine. Containers are familiar, fast, and easy to wire into development scripts.

A VM is a stronger boundary because the agent runs behind a guest machine boundary rather than only a process and namespace boundary. That distinction matters more when you are tempted to give the agent root inside the sandbox, install arbitrary packages, or let it run a long chain of commands without pausing.

But VM does not mean invincible. You still need to decide what host files are mounted, what network destinations are allowed, what credentials are injected, and how the resulting diff is reviewed. A disposable machine reduces blast radius. It does not remove judgment.

A good trap to avoid: treating any sandbox as permission to skip code review. The VM protects the workstation. It does not prove that the code is correct, secure, or maintainable.

Try it when the agent needs real tools

clawk is most interesting when the agent needs to behave like a developer, not a text autocomplete.

A good first experiment is a repo with a real test suite and a boring dependency graph. Ask Codex or Claude Code to fix a failing test, let it install packages inside the VM, run the tests, and produce a patch. Then inspect the diff as if it came from a junior teammate who worked very fast and did not know your production scars.

Here is a small Codex-flavored boundary note you could put in AGENTS.md for that experiment:

# Agent execution boundary

Run install, build, test, and server commands inside the disposable clawk VM.
Do not request or use host credentials.
Only use external network hosts that are explicitly allow-listed for this task.
Before handoff, run the verification commands below and summarize changed files.

Verification:
- npm test
- npm run lint
- git diff --stat

That file is not the security boundary. The VM is. The file is the handrail that tells the coding agent how to behave inside the boundary and tells the reviewer what evidence to expect.

This is the practical answer for developer AI training: teach the assistant, the shell, and the reviewer as one loop. The command environment is part of the lesson.

If you are comparing the coding assistants for developer training, include this scenario in the evaluation: can the tool work productively when all real commands run inside a disposable VM, with network access limited and verification required before handoff?

Use this fit table before you install it

A safe first pass looks like this:

• Pick a non-secret repo with a working test command.
• Start clawk from the repo root.
• Allow only the network host the task truly needs.
• Ask the agent to make one small change.
• Require a verification receipt: commands run, tests passed or failed, files changed, and remaining risk.
• Delete the VM session if the run gets messy.

The checklist is small on purpose. The point is to feel the boundary, not build ceremony around it.

Further reading

• clawk on GitHub
• Cursor Agent docs
• Codex CLI docs
• MCP specification For a shorter companion note on the same project, see Clawk Gives Coding Agents a Throwaway VM.

Next step

Try clawk on one non-secret repo where an agent needs to run tests and install dependencies. Keep the change small, allow-list only what is needed, and judge the workflow by the patch and verification receipt.