Run a case inside an isolated Docker container instead of directly on the host. Any number of Codeman sessions can share one container (it is scoped to the case, not the session), so a whole project lives in a sandbox with its own network, resource caps, and filesystem, and you can export the container to move it to another machine.
Docker mode is a location overlay on cases, the direct analog of remote SSH cases: where a remote case runs a local tmux pane doing ssh host into a durable remote tmux server, a docker case runs a local tmux pane doing docker exec -it into a durable in-container tmux server. It is not a separate SessionMode, so claude / shell / opencode / codex / gemini all work inside the container.
The container needs a base image with the agent toolchain (node, the CLIs, git, tmux). Build it locally once:
node scripts/build-agent-image.mjs # builds codeman/agent:base
# options: --engine docker|podman --image <ref> --no-cacheThe image is secret-free: credentials are delivered at runtime (bind mounts or docker exec --env), never baked in, so exports never leak them.
On the New case → Create New tab there's a 🐳 Run in an isolated Docker container checkbox. Checking it alone is enough: Codeman creates the case folder in ~/codeman-cases/<name>, spins up a hardened container with sensible defaults (auto-provisioning a shared default host), and starts the session inside it. No host/image/network fields to fill in.
Click the checkbox's Container settings to optionally tweak the predefined defaults, including a Template picker:
| Template | Memory | CPUs | GPUs |
|---|---|---|---|
| Small | 2 GB | 1 | none |
| Medium (default) | 4 GB | 2 | none |
| Large | 8 GB | 4 | none |
| GPU | 8 GB | 4 | all (needs the NVIDIA container toolkit) |
Disk is elastic — the container's storage grows automatically as data flows in; there is no fixed cap (bounded only by host disk). Any tweaked setting creates a dedicated per-case host so it never changes the shared default.
App → New case → Docker tab:
- Case Name / Workspace Path: the workspace is a real HOST directory bind-mounted into the container at the same path. Codeman scaffolds
CLAUDE.md+.claude/settings.local.json(hooks) into it, and file previews / attachments work on the real bytes. - Host ID: a reusable docker host profile (image, network, resources). Reuse the same ID across cases to share settings.
- Network:
bridge(internet on, default),none(fully isolated), or acustombridge. - Advanced: memory / CPU caps, Mount host credentials (on = your existing
~/.claudelogin just works; off = a sealed sandbox you log into inside the container), Resume last conversation on relaunch.
Then run it like any case (Run Claude / Run Shell / …). The first launch creates the container (codeman-case-<name>); subsequent sessions attach to the same one.
Equivalent API:
curl -X POST localhost:3000/api/docker-hosts -d '{"id":"local","label":"Local","image":"codeman/agent:base"}'
curl -X POST localhost:3000/api/cases/docker-link -d '{"name":"sandbox","hostId":"local","hostWorkspacePath":"/home/you/projects/sandbox"}'
curl -X POST localhost:3000/api/quick-start -d '{"caseName":"sandbox","mode":"claude"}'- Reconnect after a Codeman restart lands back in the same live agent (the in-container tmux survives).
- Container stop / host reboot restarts the container and resumes the last conversation from the bind-mounted transcript. Claude sessions launch with a pinned conversation id (
--session-id <sessionId>, with a--resumefallback when the transcript already exists), and the case remembers its last conversation (lastClaudeSessionId), so a relaunch after the container was stopped, rebooted, or recreated continues where it left off. - Killing one session only kills that session's in-container tmux session; the shared container stays up for sibling sessions.
- Editing the docker host config (image, memory, network, ...) is detected on the next launch: the desired config hash is compared against the container's
codeman.confighashlabel, and a mismatch refuses the launch with a "config changed, recreate?" confirm. Confirming callsPOST /api/docker-cases/:name/recreate(refused while sessions of the case are live), which removes the container so the next launch recreates it with the new config; the workspace and the conversation survive. - Deleting the case
docker rm -fs the container (the bind-mounted workspace on the host survives). An instance-scoped boot reaper removes containers whose case is gone.
Every container runs hardened: --cap-drop ALL, --security-opt no-new-privileges, non-root (--user <hostUid>:0 so workspace files stay host-owned), --pids-limit, --memory == --memory-swap, --init. Never --privileged, never the docker socket. The default convenient profile bind-mounts host credential dirs read-write so the common login just works (creds stay on the host, never captured by docker commit); the sealed profile (mountCredentials:false + network:none) is the opt-in for genuinely untrusted work.
Rootless engines without cgroup-v2 systemd delegation cannot enforce resource caps; linking such a host warns that caps are advisory.
Export (from the Docker tab, or POST /api/docker-cases/:name/export): choose
- Full image + workspace:
docker committhe container to an image,docker saveit, tar the workspace, and a manifest, all into one portable<case>-<ts>.codeman-container.tgz(the whole toolchain, installed packages, and files). Runs in the background; you are notified when the bundle is ready. - Workspace only: just the project files (fast, small).
The container is paused across the capture so the image and workspace are consistent; a full /var/lib/docker is guarded against with a free-space precheck; the intermediate image is always cleaned up.
Import (POST /api/docker-cases/import, or the Manage tab): copy the .tgz onto the new machine's ~/.codeman/docker-exports/, then import it into a new case. The manifest and per-member SHA-256 checksums are validated, the workspace tar is extracted with a path-traversal guard, and the image is docker loaded and re-tagged into a quarantined namespace (codeman/imported-<case>:<ts>) so it never overwrites a local tag. The destination supplies its own credentials, so nothing secret crosses machines.
GET /api/docker-exports lists bundles; GET /api/docker-exports/:filename downloads one; DELETE removes one.
In-container hooks (permission events, hook-based idle/stop/task notifications) POST to CODEMAN_API_URL, which is derived as https://host.docker.internal:<port> (host.docker.internal → the docker bridge gateway, e.g. 172.17.0.1, via --add-host …:host-gateway). For that callback to succeed, the Codeman server must be listening on an interface the container can reach.
- If Codeman binds loopback-only (
127.0.0.1, the default and the production systemd config), a container reaching172.17.0.1:<port>cannot connect, so by default in-container hooks do not fire. The session still works fully: idle/stop detection falls back to output-based detection through thedocker execPTY (which always works), and claude runs with--dangerously-skip-permissionsso there are no permission prompts to forward anyway. - To enable in-container hooks on a loopback-only server, set
CODEMAN_DOCKER_BRIDGE_HOOKS=1(env). Codeman then starts a SECOND listener bound to the docker bridge gateway (172.17.0.1, auto-detected; override withCODEMAN_DOCKER_BRIDGE_HOST) that serves only the hook endpoints (/api/hook-event,/api/status-telemetry) and delegates them into the same secret-gated pipeline. The bridge is host-internal (containers + host, not the LAN), and every other path returns403, so this does not widen your network exposure. AddEnvironment=CODEMAN_DOCKER_BRIDGE_HOOKS=1to the systemd unit and restart. - Alternatively, bind
0.0.0.0withCODEMAN_PASSWORDset (exposes on the LAN too).
The host-gateway mapping, CODEMAN_API_URL derivation, host-guard allowlist, and hook-secret mount are all wired correctly; CODEMAN_DOCKER_BRIDGE_HOOKS closes the last gap for loopback-only servers.
- Requires Docker (or Podman) with a reachable daemon; tmux must be present in the base image (a hard prerequisite, probed at link time).
- Per-session
envOverrides/effort/ per-CLI config are rejected for docker cases (they do not cross into the container); configure the container via the docker host's per-mode command override instead. - macOS Docker Desktop takes a dedicated uid path (the baked image uid; memory caps are subject to the VM ceiling).
Design + rationale: docker-cases-plan.md.