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.
Per-dimension scores and reasoning
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.
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.
What 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 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 claudeHow 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.
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.