clawk Runs Coding Agents in Disposable VMs

clawk is clawkwork's open-source Go project for running coding agents inside disposable, network-restricted Linux VMs instead of on your laptop. It deals with the awkward middle ground between approving every command and giving an agent broad access to your machine. The takeaway is simple: if an agent needs to install packages, run tests, start servers, and touch the network, put a real boundary around it. The best AI code 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, Anthropic's coding agent, 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. Developers cared because 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 the related training topic, 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 best ai code 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

Try clawk when...	It may be overkill when...
The agent needs to install packages or run unknown scripts.	You only use chat suggestions and copy code manually.
You want fewer permission prompts without trusting the laptop.	The repo is already isolated in a short-lived CI job.
You need local servers, forwarded ports, and repeatable sessions.	The task is a tiny read-only refactor.
You are teaching agentic coding habits with real command execution.	Your main risk is code quality, not workstation access.
You can review diffs and verification output after the run.	Nobody will review the resulting patch.

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.

Common questions

• Why not just use a Docker container?

  Docker can be enough for low-risk work, but clawk aims for a stronger machine boundary. The project gives the agent root in a disposable Linux VM while keeping host files, keychain data, and unrestricted network access out of reach. The caveat is that mounted repo files are still real files, so review remains mandatory.

• Does clawk make it safe to skip permission prompts?

  clawk makes fewer prompts more reasonable, not universally safe. Its value is that the dangerous work happens inside a disposable, network-restricted VM rather than directly on your laptop. You still decide which repo is mounted, which hosts are allow-listed, and whether the final diff deserves to merge.

• Which are the best ai code assistants for developer training if I use clawk?

  The best choice is the assistant your developers will actually use in real repos. clawk's README names Claude Code, Codex, and a plain shell as possible guests, so the training lesson is tool-agnostic: run commands in a bounded environment, verify results, and review the patch rather than trusting the chat transcript.

• Is clawk only for Claude Code?

  No. The repository describes clawk as usable with Claude Code, Codex, or a shell. That is useful because the project is about the execution environment, not a single vendor feature. The agent can vary; the boundary stays the same.

• What should I review after an agent finishes in a VM?

  Review the diff, the verification output, and the boundary assumptions. A good handoff says which commands ran, which network hosts were allowed, which files changed, and which tests failed or were skipped. The VM answers where the work ran; it does not answer whether the change is good.

Best ways to use this research

• Best for: evaluating coding-agent workflows where the assistant must run real commands, not just suggest edits.
• Best first artifact: a tiny AGENTS.md boundary note plus a required verification receipt from the agent.
• Best comparison angle: VM isolation versus container isolation for agentic coding tasks that need package installs, local servers, and network access.
• Best workshop exercise: give two agents the same failing test, run one with broad host access and one inside a disposable VM, then compare speed, evidence, and reviewer comfort.

Further reading

• clawk — source
• Codex — Agent
• OpenAI Developers — Codex quickstart
• Model Context Protocol — 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.

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.