VibePod CLI 0.23: containerized agents inside your editor

2026-09-12 · Release · CLI · Agents · Editors

The agent moves into the AI panel

Until now a VibePod agent lived in a terminal. With vp run <agent> --acp, VibePod acts as an Agent Client Protocol adapter instead: the editor launches vp as a subprocess, speaks JSON-RPC to it, and renders the agent in its own AI panel. Nothing about the run changes — container isolation, credential profiles, project overlays, the MITM proxy and local metric collection all stay active.

PyCharm's AI panel showing VibePod Claude answering a question about a file in the open project. — A containerized Claude answering in PyCharm's AI panel, started by `vp run claude --acp`.

{
  "agent_servers": {
    "VibePod Claude": {
      "type": "custom",
      "command": "/absolute/path/to/vp",
      "args": ["run", "claude", "--acp"],
      "env": {}
    }
  }
}

Use an absolute path — GUI applications do not inherit your shell PATH. -w is usually unnecessary: Zed, PyCharm and the VS Code ACP Client start the agent in the open project, and vp run takes its working directory as the workspace, so one entry serves every project. Allow the directory once beforehand, because the editor's stdin is a protocol pipe rather than a TTY:

vp config allow-dir /absolute/path/to/project

Questions VibePod would normally ask on the terminal are sent as ACP forms and answered in the chat instead of failing the launch.

Eleven agents, two kinds of adapter

opencode, copilot, auggie, jcode, gemini, qwen, devstral and hermes run an adapter that is already in the image, so they start offline and immediately. claude, codex and pi fetch theirs with npx, which needs the package registry reachable through the proxy filter and adds startup latency. For the claude and codex adapters VibePod points CLAUDE_CODE_EXECUTABLE and CODEX_PATH at the image's own binary, so the version the image pins is the one that runs. Any other agent can be wired up through agents.<agent>.acp_command, which is also how you pin an npx adapter to a version.

Hermes joins as a developer preview

Hermes is Nous Research's self-improving agent: it keeps cross-session memory and writes its own skills, and it is not primarily a coding TUI. It runs as hermes (vp h) from vibepod/hermes:latest, which is built on the official nousresearch/hermes-agent image and pins one of its CalVer release tags.

The Hermes Agent banner in a VibePod container, listing its available tools and skills. — Hermes starting in its container, listing the tools and skills it found.

vp run hermes              # classic Python REPL
vp run hermes -- --tui     # the Ink TUI
vp task create hermes "summarize this repository"

Three things are worth knowing before the first run. Hermes has no usable provider until you run hermes setup once inside the container; it persists to the mounted config directory. Global LLM wiring is not supported, so set llm.enabled: false — VibePod rejects the launch rather than silently starting a different model. And the pinned image needs its own runtime user, so rootless Podman is rejected up front instead of crashing mid-boot; run Hermes on rootful Docker or Podman.

Its write sandbox is honored rather than worked around: VibePod sets HERMES_WRITE_SAFE_ROOT to /opt/data:/workspace so the project mount is writable, appends the host workspace path under --acp, and extends whatever value you configure instead of replacing it. Skills installed with vp skills are mounted and picked up automatically, and hermes-acp means Hermes works in an ACP editor like the rest.

Upgrading

Nothing to migrate by hand.

python -m pip install --upgrade vibepod

Release details