Docker inside a session: compose, databases and image builds

Some tasks need Docker: running a database for tests, docker compose up, building images. Tick Docker inside the Sandbox when creating a session, or turn it on for all new sessions in Settings, and the box gets its own Docker daemon. Images and containers created inside survive Stop/Resume and disappear with the session.

There are two ways this can run, and Sessionboxer picks automatically:

• With Sysbox installed on your machine (sysbox-ce package from its releases page), the box stays a normal, unprivileged container. Recommended.
• Without Sysbox, the box has to run as a privileged container, which means the agent could break out of it onto your machine. Sessionboxer still lets you do it, but shows a ⚠ on the Global settings button, explains it next to the option, and marks such sessions in the sidebar and header. Only use this with agents and tasks you trust, or install Sysbox.

Which addresses the Docker inside the box uses: its daemon carves docker0 and every docker compose network out of Global settings → Environment → Addresses for Docker inside Sandboxes, 192.168.240.0/20 by default — the top of 192.168.x, which home routers (192.168.0–2.x), Docker Desktop (192.168.65.x), company networks and Kubernetes (10.x), WSL2 and Docker itself (172.16–31.x), Tailscale and WARP (100.64–127.x) all stay clear of. Anything that lives inside that block is unreachable from the box (No route to host, because the box takes it for a neighbour on its own bridge), so if your network does use 192.168.240–255.x pick another block from the field's suggestions (10.213.0.0/16, 100.64.0.0/16) or type your own; empty means Docker's own default, 172.17.0.0/16 and up, which hides company or VPN hosts in that range (a private Argo CD at 172.17.74.12, say). Changes apply to sessions created afterwards (Stop → Resume keeps the old daemon's networks). See Troubleshooting for how to tell this apart from a certificate problem.