VibePod — Containerized AI Coding Agent Runner
One CLI that runs Claude, Codex, Copilot and other coding agents inside isolated Docker or Podman containers, with local metrics and traffic analytics.
- Source repo
- VibePod/vibepod-cli
- Stars
- ★ 190
- Last updated
- 3d ago
- License
- MIT
- Primary language
- Python
- FA score
- 50/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude CodeChatGPT · Claude.ai (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A platform team wants several engineers to try Claude, Codex and Gemini side by side without each person installing and configuring a different agent toolchain.
- Not a fit if
- Users without a working Docker or Podman runtime
- Teams unwilling to let agents skip approvals or bypass sandboxes
- Source review
- 50/100 · Major gaps
What does this agent do, and when should you use it?
VibePod is a unified CLI (invoked as vp) for launching AI coding agents inside isolated Docker or Podman containers. The execution model is deliberately zero-config: vp run <agent> resolves the agent to a default image under the vibepod Docker Hub namespace (for example vibepod/claude:latest), starts it in a container, and forwards anything after -- to the agent process itself. Alongside vp run there are vp stop, vp list, vp config init/show/path, and vp version for lifecycle and configuration management. Per-project customization is expressed as a FROM-less Dockerfile fragment committed under .vibepod/overlay/, which VibePod builds into a cached, content-addressed layer on top of the agent's base image. While agents run, VibePod collects local metrics and HTTP traffic and exposes them through a dashboard container started with vp logs start, showing per-agent usage, traffic and Claude token metrics, plus side-by-side agent comparison. Everything stays on the local machine, and --acp turns vp into an Agent Client Protocol adapter so containerized agents appear directly in editors such as Zed.
VibePod parses the subcommand and agent name, separating its own flags from agent arguments (use -- before agent flags), then maps the agent to a default image or to an override supplied via VP_IMAGE_<AGENT> environment variables. It starts an isolated container with Docker or Podman and runs the agent process inside it. --ikwid appends each agent's auto-approval flag where supported (claude's --dangerously-skip-permissions, gemini's --approval-mode=yolo, copilot's --yolo, and so on), while --acp exposes the containerized agent as an Agent Client Protocol server for editor integration. Project-specific dependencies are added by committing a FROM-less Dockerfile fragment under .vibepod/overlay/, which is auto-built into a cached, content-addressed image layer. During execution VibePod records local metrics and HTTP traffic; vp logs start/stop/status manages the dashboard container (default image vibepod/datasette:latest), which renders per-agent traffic, usage over time, Claude token metrics, and agent-to-agent comparisons. vp skills add installs reusable prompt recipes, and the vp config commands manage configuration files and allowed directories.
- A platform team wants several engineers to try Claude, Codex and Gemini side by side without each person installing and configuring a different agent toolchain.
- A developer under security or compliance constraints needs agents confined to a container with controlled filesystem and network access rather than running directly on the host.
- Someone deciding which agent is worth paying for opens
vp logs startand compares token consumption and request traffic across agents in the local dashboard. - A Zed user wants the isolated agent inside the editor's AI panel, achieved by registering
vp run <agent> --acpas a custom agent server. - A project needs extra tooling inside the agent image; instead of maintaining a fork, the team commits a Dockerfile fragment under
.vibepod/overlay/and lets VibePod build a cached per-project layer. - A Podman user on Linux wants the same agent launching workflow that Docker users get, without switching container runtimes.
How do you install or deploy this agent?
VibePod is published on PyPI, Homebrew, and conda-forge. Pick one:
pip install vibepodbrew install vibepod/vibepod/vibepodconda install -c conda-forge vibepod
# or
mamba install -c conda-forge vibepod
pixi global install vibepodA working Docker or Podman installation is required on the host; the first run pulls the agent image from the vibepod namespace on Docker Hub.
How do you use this agent?
Basic invocation:
vp run <agent>
# e.g.
vp run claude
vp run codex
vp run vibe # alias of devstralPass agent flags after -- so VibePod does not parse them as its own options:
vp run <agent> -- <agent-args>Skip approval prompts where the agent supports it:
vp run claude --ikwidEditor integration (Zed example; run vp config allow-dir /path/to/project first, since the editor's stdin is a pipe and the interactive prompt cannot run):
{
"agent_servers": {
"VibePod Claude": {
"type": "custom",
"command": "vp",
"args": ["run", "claude", "--acp"],
"env": {}
}
}
}Local analytics dashboard:
vp logs start
vp logs status
vp logs stopOverride a default image:
VP_IMAGE_CLAUDE=vibepod/claude:latest vp run claudeWhat are this agent's strengths and limitations?
- A single
vp run <agent>entry point spans more than a dozen coding agents, collapsing install, isolation and measurement into one CLI. - Container isolation via Docker or Podman is the default path, not an add-on, so agents execute inside a boundary rather than directly on the host.
- Metrics, HTTP traffic and token data are collected and stored locally and viewed through
vp logs start; no cloud upload is involved. .vibepod/overlay/lets a project commit aFROM-less Dockerfile fragment, from which VibePod builds a cached, content-addressed image layer automatically.--acpmakes the containerized agent usable from editors that speak Agent Client Protocol, such as Zed, without giving up isolation or proxy metrics.
- Requires a working Docker or Podman runtime, plus network access to pull
vibepod/*images from Docker Hub; without a container runtime it cannot run. --ikwidappends approval-skipping or sandbox-bypass flags on agents that support it (for example--dangerously-skip-permissions), which materially raises risk if used carelessly.--ikwidis not universal: the README explicitly lists opencode, auggie, tau, jcode, freebuff and dsh as not supported.- The repository describes itself as an initial v1 implementation with a limited surface: run, stop, list, config, and version.
- Editor integration has a non-obvious prerequisite:
vp config allow-dirmust be run once beforehand because the editor's stdin is a pipe and the interactive prompt cannot run. - Dashboard token metrics are documented for Claude specifically; token measurement for other agents is not described.
How does this agent compare with similar options?
The README does not name competing tools; it describes unifying existing agents (Claude Code, Gemini CLI, OpenAI Codex, GitHub Copilot CLI, OpenCode, Mistral Vibe/Devstral, Augment Auggie, Pi, Agy, Tau, Jcode, Freebuff, Qwen, dsh, Hermes) under one CLI, so no third-party comparison is offered here.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| VibePod — Containerized AI Coding Agent Runner This agent | 50 · Major gaps | CLIFree + model costs | ★ 190 | 3d ago | Python | Codex · Claude Code |
| AgentSight | 77 · Some gaps | CLIFree | ★ 771 | 14d ago | C | Claude Code |
| Agency Orchestrator: One Sentence to Orchestrate an AI Expert Team | 61 · Some gaps | CLIFree + model costs | ★ 2.4k | 3d ago | TypeScript | Codex · Claude Code · OpenAI API · Claude API |
| NanoClaw | 58 · Major gaps | CLIFree + model costs | ★ 31k | today | TypeScript | ChatGPT · Codex · Claude Code · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
README states metrics are collected and stored locally and never sent to the cloud, giving decent data_flow_transparency (2). However --ikwid appends --dangerously-skip-permissions / --yolo / --dangerously-bypass-approvals-and-sandbox for many agents, a high-privilege mode with no documented risk warning or confirmation, so least_privilege and user_confirmation score 1. Container isolation is a positive, but workspace/config mounts and proxy traffic capture lack sensitive-data detail in the visible files, so sensitive_data_handling is 1. Dependencies are lower-bounded with no lockfile or hashes, so dependency_security is 1. External effects (image pulls, container starts, proxy) are described but rollback/cleanup guarantees are absent, so external_effects and rollback are 1. Attribution is clear (MIT, author, org, image namespace), source_attribution 2.
pyproject and README agree on command set, image namespace, and agent aliases (vibe=devstral), so self_consistency is 2. Dependencies are public PyPI packages with lower bounds but no lock or availability verification, so dependency_availability is 1. Integration tests include detailed failure diagnostics (exit codes, logs, cleanup retries), so failure_messages is 2.
README covers many agents, install channels, ACP editor integration, overlays, and skills, so audience_and_scenarios is 2. capability_boundaries is reasonably defined via the IKWID support table (which agents are unsupported) and ACP support list, scoring 2. trigger_precision: --ikwid and --acp semantics are explained but guidance on when not to use them is missing, scoring 1. environment_fit covers Docker/Podman and a macOS/Windows/Linux CI matrix, scoring 2.
Information architecture is clear (features, install, quick start, status, analytics, image namespace), scoring 2. Install notes cover pip/brew/conda, scoring 2. Naming is stable (vp/vibepod entry points, fixed image namespace), scoring 2. Examples are plentiful, scoring 2. known_limitations is only scattered (unsupported IKWID agents, ACP needs allow-dir first) with no consolidated section, scoring 1. license is a full MIT text, scoring 3. versioning_changelog has only a version number and no CHANGELOG, scoring 1. maintenance_responsibility lacks an explicit maintainer commitment or security disclosure channel, scoring 1.
output_usability: CLI commands, dashboard, and log commands are clear, scoring 2. marginal_value: unified multi-agent container running plus local analytics is a genuine increment, scoring 2. cost_benefit: pulling many images, running containers and a proxy has unquantified resource cost versus benefit, scoring 1.
claim_traceability: README claims mostly point to external docs and repos, hard to trace within visible files, scoring 1. cross_source_corroboration: README, pyproject, and CI partially corroborate commands and images, but core behavior lacks source corroboration, scoring 1. fact_inference_separation: README is largely marketing assertions (zero config, just works) not clearly separated from verifiable facts, scoring 1.
- --ikwid appends approval/sandbox-skipping flags (e.g. --dangerously-skip-permissions, --yolo) for many agents; this is a high-privilege mode with no documented risk warning or confirmation, so evaluate before use.
- Dependencies are lower-bounded with no lockfile or hashes, so build reproducibility and supply-chain safety cannot be confirmed from the visible files.
- Local storage location, retention policy, and sensitive-data handling for metrics and HTTP traffic capture are not described in the visible files.
- No CHANGELOG and no explicit security disclosure or maintenance responsibility, leaving long-term maintenance and vulnerability response unclear.
- README is largely marketing assertions with little source-level corroboration; static review cannot verify actual runtime behavior.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
What's Changed * Custom providers by @nezhar in https://github.com/VibePod/vibepod-cli/pull/185 * Add vp skills cache clear command by @nezhar in https://github.com/VibePod/vibepod-cli/pull/186 * Provider import export by @nezhar in https://github.com/VibePod/vibepod-cli/pull/187 * Mount custom volumes from agents.<agent>.volumes and vp run -v/--volume by @nezhar in https://github.com/VibePod/vibepod-cli/pull/188 * Send a VibePod User-Agent for model discovery and provider file fetches by @nezhar in https://github.com/VibePod/vibepod-cli/pull/190 …View on GitHub ↗ -
Release notes excerpt
What's Changed * Add example overlay for pi agent to use mcp adapter by @nezhar in https://github.com/VibePod/vibepod-cli/pull/180 * Run skills engine through the Docker SDK instead of the docker binary by @nezhar in https://github.com/VibePod/vibepod-cli/pull/177 * chore: bump version to 0.23.1 by @nezhar in https://github.com/VibePod/vibepod-cli/pull/182 Full Changelog: https://github.com/VibePod/vibepod-cli/compare/0.23.0...0.23.1View on GitHub ↗ -
Release notes excerpt
What's Changed * docs: add DeepSeek Harness screenshot to README and agent docs by @nezhar in https://github.com/VibePod/vibepod-cli/pull/160 * Log profile name on sessions by @nezhar in https://github.com/VibePod/vibepod-cli/pull/163 * chore: bump version to 0.22.0 by @nezhar in https://github.com/VibePod/vibepod-cli/pull/167 Full Changelog: https://github.com/VibePod/vibepod-cli/compare/0.21.0...0.22.0View on GitHub ↗
FAQ
What do I need installed before running VibePod?
vibepod installed via pip, Homebrew, or conda-forge. The first vp run <agent> pulls the matching image from the vibepod namespace on Docker Hub, such as vibepod/claude:latest.Does the collected telemetry leave my machine?
What does --ikwid do, and what are the risks?
--dangerously-skip-permissions for claude, --approval-mode=yolo for gemini, and --yolo for copilot. That gives the agent more freedom inside the container and should be evaluated against your risk tolerance; opencode, auggie, tau, jcode, freebuff and dsh do not support it.How do I use VibePod from my editor?
--acp to expose it as an Agent Client Protocol adapter, then register vp as a custom agent server in your editor's configuration (in Zed, under agent_servers in settings.json). Note that you must run vp config allow-dir /path/to/project once beforehand, because the editor's stdin is a pipe and cannot answer the interactive prompt.Can I use my own images instead of the defaults?
VP_IMAGE_<AGENT> environment variable, for example VP_IMAGE_CLAUDE=vibepod/claude:latest vp run claude. The dashboard and skills engine images are overridden separately with VP_DATASETTE_IMAGE and VP_SKILLS_ENGINE_IMAGE.