embabel sandbox

The container code-mode runs in, and how to make it yours.

embabel sandbox show     # which image, why, and where it came from
embabel sandbox build    # build sandbox/Dockerfile and use it
embabel sandbox reset    # back to the shipped image

The shipped sandbox carries the runtimes code-mode executes — Python with the data stack, Node and TypeScript, git, jq, sqlite, graphviz — and nothing else. Every appliance downloads it before anybody has run a line of code, so a JDK, Maven, Prolog and PlantUML were removed: roughly 900MB that most installs never used.

If your work needs them, the appliance builds a sandbox for you:

cp sandbox/Dockerfile.example sandbox/Dockerfile
$EDITOR sandbox/Dockerfile          # uncomment the JDK block, add what you need
embabel sandbox build
embabel down && embabel up

Extend, do not rewrite. The example starts FROM the shipped image, so you inherit whatever it gains — a new runtime, a security update — instead of maintaining a fork that quietly falls behind. A full rewrite is still yours to make; it is just not what this encourages.

The build writes EMBABEL_SANDBOX_IMAGE into .env, which is the one name that moves both halves: the pre-pull in infra.yml and the container the app launches for a session. Setting one without the other pulls a sandbox nobody uses and then fetches a different one mid-chat.

Nothing is pushed anywhere — the image is tagged locally and stays on your machine.

A single world can override this further with sandboxDockerimage in its config/world.yml, which wins over the appliance-wide setting: the narrower scope means it.