Devin CLI by Cognition as a mixin -- the CLI and its auth wrapper in an overlay, with the passthr...
129
Devin CLI by Cognition as a mixin -- the CLI and its auth wrapper in an overlay, with the passthrough Devin credential, its rendered credentials.toml, and the config and MCP seeds. Layer it onto a shell base and run `devin`.
| Name | Required | Default | Description |
|---|---|---|---|
version | Optional | 3000.10.31 | Devin CLI release to install |
[email protected]| Type | Required | Description | |
|---|---|---|---|
com.docker.sandbox/network-policy@1 | Required | — | |
com.docker.sandbox/credential@1 | Optional | Devin account credential captured during in-sandbox login | |
com.docker.sandbox/lifecycle@1 | Required | — | |
com.docker.sandbox/agent-context@1 | Required | — | |
sbx run <agent> --kit docker/sbx-kit-devin-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.
The mixin form of the devin kit: Cognition's Devin CLI in an
overlay that lands on a shell workload, instead of a whole sandbox of its own.
A kind: mixin kit carrying the Devin CLI and its auth wrapper as a
filesystem delta, with the same declarations the workload makes — the
passthrough devin credential and the credentials.toml it renders, the
*.devin.ai / Codeium allow list, the auto_update: false config seed, and
the MCP-gateway registration hook.
setup.sh is a per-user installer with no --prefix that resolves its target
from a manifest it fetches itself, so devin-mixin.dockerfile runs the same
install the workload runs, in a build stage on the workload's own base — same
pinned versioned script, same || true around the TTY-less devin setup,
same version assertion, same devin-cli rename — and copies
/home/agent/.local into a FROM scratch overlay.
The pin rides along too: DEVIN_VERSION is the descriptor's version arg and
is expanded into provides: ["devin@<version>"], and it must stay equal to
the workload's, since the two shapes provide one name. See ../devin/README.md
for how the pin reaches an installer that reads no version. The copy is the whole per-user prefix rather than bin alone because
the installer's layout is a version directory plus a "current" symlink plus
launchers, and devin-cli deliberately points at the symlink target so
devin update keeps moving it.
devin-entrypoint.sh is a copy of the workload kit's wrapper. A kit directory
is its own build context, so an overlay cannot COPY out of a sibling's — it
must stay byte-identical to ../devin/devin-entrypoint.sh.
$ sbx create --kit <shell-workload> --kit ./devin-mixin
$ devin --permission-mode dangerous --respect-workspace-trust=false
ENTRYPOINT: the base workload's stays, so the
two flags the standalone kit's entrypoint carries have to be passed by hand.archive.ubuntu.com,
security.ubuntu.com, ports.ubuntu.com and download.docker.com and runs
an apt-get update startup hook. Both stay with it: they describe the base
image's apt configuration, which an overlay does not own and cannot know.com.docker.sandboxes.start-docker because it owns a base that carries an
engine. An overlay setting it would ask for Docker mode over a base that may
have nothing to run.AGENTS.md profile, sbx@1 and the sandbox identity, and the
platform floor — bash, the agent user, git, a CA store.devin and devin-mixin both provide devin, so they are alternatives:
composing the two together is refused, one capability having one provider.
Pulls:
71
Last week