Tako VM CLI
Tako VM runs agent code in single-use Docker containers with a job queue, run history and network isolation
- 90 ★ on the repository
- Last commit
- Apache-2.0
Broad access
Why this level
- Executes arbitrary model-generated code, so Docker and gVisor isolation is the only protection for the host
- Containers can get network access when package install or an allowlist is enabled
- The server stores run code, output and artifacts in PostgreSQL
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add cli/tako-vmDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Executes arbitrary model-generated code, so Docker and gVisor isolation is the only protection for the host
- Containers can get network access when package install or an allowlist is enabled
- The server stores run code, output and artifacts in PostgreSQL
This is third-party code. Review the repository files before installing.
What it does
Tako VM is the code-execution tool behind an AI agent: the model writes Python, the service runs it in an isolated container and the agent receives stdout and stderr as its observation. Each job goes into its own Docker container with an ephemeral workspace and optional gVisor sandboxing. Network is off by default, and jobs can get an allowlist of addresses. It includes a job queue with a worker pool, retries, idempotency through `idempotency_key`, run history in PostgreSQL with output, timing and artifacts, and rerun of a job with the same code for debugging. It starts with `pip install "tako-vm[server]"`, `tako-vm setup` and `tako-vm server`, and is driven through a REST API and a Python SDK. The documentation covers `run_python` tool integrations with LangChain and OpenAI function calling. Persistent agent workspaces are on the roadmap, and for now each container is single-use.
Who it is for. Teams building their own agents that must safely execute model-generated Python on their own servers without Redis and Celery queues.
Good fit when
- A LangChain agent writes Python and it must run in an isolated container
- You need run history with stdout, stderr, timing and artifacts for debugging
- The agent must install packages on the fly with limited network access
- A run must be repeated with the same code and inputs to debug a failure
Not a fit when
- The machine has no Docker or Python 3.10 or newer
- You need persistent agent workspaces between runs: containers are single-use today
- You want a managed cloud service with no self-hosting
Example request
Start Tako VM locally, run print(1 + 1) in it through REST and then show the run historyLimitations
- Docker and Python 3.10 or newer are required, and on first run the server starts PostgreSQL through Docker.
- Each container is single-use, and persistent workspaces are on the roadmap and not ready.
- Package installs by the agent need `allow_runtime_requirements: true`, off by default, and such a job runs with network access.
- Model-generated code must be treated as untrusted: for agent workloads the docs advise `security_mode: strict` so that plain `runc` is not used in place of gVisor.
How to disable. Stop the server and local database with `tako-vm dev down`, remove the executor Docker image and uninstall the package with `pip uninstall tako-vm`.
FAQ
How do I run Tako VM?
You need Docker and Python 3.10+. Run `pip install "tako-vm[server]"`, then `tako-vm setup` to pull the executor image and `tako-vm server` to start the server with PostgreSQL.
How does it differ from e2b or daytona?
Those give isolated execution, and you build queues, run history, retries and idempotency yourself. Tako VM includes all of that and runs on your machine with no per-run fee.
Do jobs have network access?
Not by default. A job type can get an allowlist of addresses. A job that installs packages gets network for the installation.
How do I connect it to a LangChain agent?
Define a `run_python(code, requirements)` tool that submits code through `tako_vm.submit_code` and waits for the result. On failure return the traceback text so the model can fix its own code.
What is a job replay?
Running a past job again with the same code and inputs through the rerun or fork API. It reproduces a failure for debugging.
Discussion
No questions or reviews yet.
Related
CLI toolsTensorlake offers MicroVM cloud sandboxes for agents: the tl CLI and SDK run AI code in isolation with snapshots and auto-suspend.
devvm gives each project its own virtual machine with the right toolchains, where Claude Code and Codex cannot see your secrets
Container by Aerovato
Container
A CLI for persistent per-project Linux workspaces in Docker or Podman that keep the agent away from the rest of your system
CLI for microVMs: an isolated virtual machine with its own kernel for agents, sub-second boot, checkpoints and branching.
CLI that runs commands and AI agents in isolated microVMs that boot in under 125 ms and keeps API keys out of the sandbox itself.
A background process manager for agents: the agent starts a dev server and reads its logs, status and ports later, plus a TUI
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| Tako VM (this card) | no | 90 | ||
| LLM Sandbox MCP | no | not required | 1,143 | an MCP server where an agent runs code in a container and gets charts, while Tako VM adds a queue, history, replay and a REST API |
| AIO Sandbox | no | key is optional | 6,331 | a container with the whole agent environment: browser, terminal, VS Code, while Tako VM specializes in code execution with a job queue |
README in short
The README presents Tako VM as a file system and Python execution for agents with job queues and Docker isolation. It shows installation, a sample `curl` request, a comparison with sandbox-only solutions, the feature list, CLI commands and a documentation table. A Japanese version exists.