Mistral AI's open source coding agent as a mixin — the `uv`-installed CLI and its managed inter...
2.9K
Mistral AI's open source coding agent as a mixin — the `uv`-installed CLI and its managed interpreter in an overlay, with the Mistral API key injected by the sandbox proxy and the ~/.vibe state volume. Layer it onto a shell base and run `vibe-start`.
| Name | Required | Default | Description |
|---|---|---|---|
agent | Optional | auto-approve | Vibe agent to start: a builtin (ask, plan, accept-edits, auto-approve) or a custom agent declared in ~/.vibe/agents/NAME.toml. |
version | Optional | 2.25.5 | Mistral Vibe release to install |
[email protected]| Type | Required | Description | |
|---|---|---|---|
com.docker.sandbox/network-policy@1 | Required | — | |
com.docker.sandbox/credential@1 | Optional | Mistral API key (https://console.mistral.ai/api-keys) | |
com.docker.sandbox/volume@1 | Required | Vibe state — config, sessions, logs, custom agents | |
com.docker.sandbox/lifecycle@1 | Required | — | |
com.docker.sandbox/agent-context@1 | Required | — | |
sbx run <agent> --kit sbx/vibe-mixin:latestRun the following command to install sbx on your machine.
brew install docker/tap/sbxwinget install Docker.sbxNote
Experimental: Sandbox Kit v3This kit uses the experimental Sandbox Kit specification, specifically v3. The format and runtime behavior may change before v3 is stable.
Mistral Vibe as a mixin — the same
agent as the vibe workload kit, packaged as an overlay you layer
onto a shell base instead of running as the sandbox's own image.
sbx run --kit ./vibe-mixin/ <shell-workload>
sbx run --kit ./vibe-mixin/ --kit-arg agent=plan <shell-workload>
Or from a git URL targeting this repo:
sbx run --kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=vibe-mixin" <shell-workload>
The base workload keeps its own launch command, so nothing attaches the TUI for you:
vibe-start # vibe --trust --agent "$VIBE_AGENT"
uv-installed mistral-vibe tool venv and its managed interpreter,
copied out of a build stage on the same base the workload uses.
uv tool install has no --prefix and bakes absolute paths into every
shebang, so the install runs unmodified at /home/agent and the resulting
trees are copied — the shape the migration guide prescribes for an
unrelocatable install./usr/local/bin/vibe (a shim, because ~/.local/bin is not on PATH on
every base) and /usr/local/bin/vibe-start.mistral credential, the ~/.vibe state volume, and
the startup hook that re-owns its mount root.VIBE_ENABLE_TELEMETRY, VIBE_ENABLE_AUTO_UPDATE and
GIT_TERMINAL_PROMPT as a /etc/profile.d snippet: a mixin's image config
is not the composed image's, so ENV would be dropped at assembly.The proxy injects the mistral key only on api.mistral.ai, as in the
workload kit. chat.mistral.ai and
console.mistral.ai remain allowed without injection. Requests using the
placeholder key there may return HTTP 401, so admin-managed configuration
and account or plan lookups may be unavailable locally and on Cloud.
vibe-startv2's sandbox.entrypoint was not just "run the binary" — it carried
--trust and --agent "${{ kit.args.agent }}". A mixin sets no entrypoint,
so those flags would have nowhere to live, and the kit's agent arg would
have nothing to read it. The launcher is where they went: it is the v2
entrypoint, spelled as a script, reading the arg from the VIBE_AGENT
variable the create-phase arg exports.
vibe-start
is a script on PATH, not the sandbox's launch argv.filename: is workload-only; this kit
contributes a body through contentFile.sbx@1. Both describe how the host drives the
workload's own entrypoint, which here is the base's. The workload kit
declares prompt: ["-p", "{{.Prompt}}"]; from a shell you type
vibe-start -p "..." yourself.