Mistral AI's open source coding agent as a mixin — the `uv`-installed CLI and its managed inter...
53
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 docker/sbx-kit-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.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.