Support & document both DooD and DinD docker-isolation workflows (DooD = zero-copy/zero-disk image reuse for disk-constrained hosts)

[konard]

Summary

Hive Mind's Docker isolation (--isolation docker) and the konard/hive-mind-dind image currently assume a DinD model (nested daemon seeded by box host-image passthrough). On disk-constrained hosts that model is unusable, because passthrough copies the multi-GB image into the nested daemon's separate store (we measured ~19.5 GB duplicated on a host with ~41 GB free). The same image can run in DooD mode (share the host daemon) with zero copy / zero extra disk, and it works today — but Hive Mind neither documents nor explicitly supports it. This issue asks Hive Mind to support and document both DooD and DinD isolation workflows at all levels (image, isolation-runner, deploy guidance, docs).

Background (confirmed)

• src/isolation-runner.lib.mjs launches isolation via $ --isolated docker --image <ref> …, i.e. it runs docker run against whatever daemon the bot process's docker talks to. In a DinD container that's the nested daemon; if the bot mounts the host socket as its runtime (DooD), the very same code runs the task on the host daemon — which already has the image, so it's reused with no pull and no copy.
• resolveDockerIsolationImageTag() makes a task request the exact HIVE_MIND_DOCKER_ISOLATION_IMAGE_TAG (e.g. konard/hive-mind-dind:2.0.13). For zero-copy reuse the host must hold that concrete tag, not just :latest.
• box-dind supports DooD out of the box (DIND_SKIP_DAEMON=1 + host socket as /var/run/docker.sock); the entrypoint skips the nested daemon and the docker CLI then targets the host daemon. (Filed companion issue on box to document/support this and the --group-add <host-docker-gid> socket-access requirement, plus the lack of a zero-copy passthrough.)

What we verified works (DooD)

Running the bot container with -v /var/run/docker.sock:/var/run/docker.sock, -e DIND_SKIP_DAEMON=1, and --group-add <host-docker-gid>:

• the bot's docker info reaches the host daemon;
• docker image inspect konard/hive-mind-dind:2.0.13 is present on that daemon → a --isolation docker task reuses it with zero copy, zero pull, zero extra disk;
• each task still runs in its own container (process/fs/network isolation); only the daemon is shared.

This is the only no-copy option on hosts whose free disk can't hold a second copy of the image.

Requested changes

1. Isolation runner / image — make isolation mode explicit and support both:
   • DinD (current): nested daemon + passthrough. Keep, but it requires disk for the duplicated image.
   • DooD (new, recommend as default on disk-constrained hosts): bot shares the host daemon; tasks reuse the host image. No deep code change is needed (the runner already does a plain docker run), but please document/support it explicitly — e.g. honor an isolation-mode/DOCKER_HOST signal and a verbose note that "docker" here is the host daemon, and adapt the post-launch diagnostics (lines that currently say "nested daemon"/warn about passthrough re-pull) so they don't false-warn in DooD.
2. Concrete-tag guidance — document that the host (or nested daemon) must hold the exact HIVE_MIND_DOCKER_ISOLATION_IMAGE_TAG, never the floating latest, or the task re-pulls. (We pin the resolved version in our deploy.)
3. Docs — a "Docker isolation: DinD vs DooD" page covering the tradeoff (per-task daemon isolation vs zero-copy/zero-disk), the run recipe for each, the --group-add socket requirement, and the fact that one image supports both modes by run flags.
4. Deploy guidance — update DOCKER.md / deploy docs to recommend DooD where disk is tight and to show how to verify the image is reused (host daemon reachable + concrete tag present) rather than silently re-pulled.

Reproduction / evidence

Confirmed end-to-end with a deploy-docker.mjs that deploys the bot in DooD mode against Docker 29.5 (containerd snapshotter). Verification step passes: "DooD docker access OK: bot reaches the host daemon" + "konard/hive-mind-dind:2.0.13 is already present on the host daemon (zero-copy, no pull on first task)". Happy to share the full script and logs. Related: #1914, #1946.

[konard]

Concrete DooD failures found while implementing this (two auth-mount bugs)

After filing this issue we wired a real DooD deploy and ran actual solve tasks. The image reuse worked (zero copy), but isolation tasks then hit two consecutive failures, both the same root cause: getDockerIsolationAuthMounts() builds the task's bind-mount sources from the bot's homedir (/home/box/...), which only resolve correctly when the task daemon shares the bot's filesystem (DinD). In DooD the task runs on the host daemon, where those source paths don't exist, so Docker auto-creates them as empty directories — breaking file mounts and producing empty config.

Failure 1 — .claude.json / .gitconfig mount: directory-onto-file

Failed to run in docker: docker: Error response from daemon: failed to create task for container:
... error mounting "/home/box/.claude.json" to rootfs at "/home/box/.claude.json":
... not a directory: Are you trying to mount a directory onto a file (or vice-versa)?

buildDockerIsolationStartArgs emits --volume /home/box/.claude.json:/home/box/.claude.json. The source is resolved on the host (DooD), doesn't exist, Docker creates an empty dir, then fails to bind it onto the container's file .claude.json. The task dies before it starts.

Failure 2 — git identity empty

After fixing the mount type, the task started but solve failed pre-flight:

❌ Git identity not configured
   user.name:  (not set)
   user.email: (not set)
   Related error: "fatal: empty ident name (for <>) not allowed"

getDockerIsolationAuthMounts() mounts host ~/.gitconfig → task ~/.gitconfig. The host /home/box/.gitconfig doesn't exist (it's only inside the bot image), so the task got an empty dir and no identity. Note maybeAddMount's existsSync check passes because it runs inside the bot (where the file exists), but the source resolves on the host at run time — so the existence check doesn't protect DooD.

Why DinD didn't hit either

In DinD the task runs on the nested daemon, which shares the bot container's filesystem, so /home/box/.claude.json and /home/box/.gitconfig are the real files. The exact same --volume args only work because of that shared FS. This is the core DooD-support gap.

Deploy-side workaround we applied (works today, no upstream change needed)

• Mount the git identity as a persistent host file and symlink the task's mount sources on the host to the bot's real config under /root/.hive-mind/* (Docker follows symlink mount sources, so file/dir types match and real credentials flow through).
• Specifically: host symlinks /home/box/.config/gh, /home/box/.claude, /home/box/.claude.json, /home/box/.codex, /home/box/.gitconfig → the real persisted config; and .gitconfig added as a bind-mounted host file so gh-setup-git-identity persists it.

Suggested upstream fix

In DooD, mount sources must be host paths, not the bot's container paths. Options:

1. Resolve auth-mount sources against a configurable host-side config root (e.g. HIVE_MIND_HOST_CONFIG_DIR) when running DooD, instead of os.homedir().
2. Or document that DooD deployers must expose the bot's ~/.config/gh, ~/.claude, ~/.claude.json, ~/.codex, ~/.gitconfig at the same host paths with matching file/dir types, and make maybeAddMount's existence check meaningful for the host (it currently checks the bot FS).
3. Pre-flight: detect DooD (docker context points at host daemon) and validate the mount sources resolve to the right type on the host before launching, with an actionable error instead of the raw Docker mount failure.

Evidence (logs, --list output, docker inspect mounts) available; reproduced on Docker 29.5 (containerd snapshotter) with konard/hive-mind-dind:2.0.13, bot in DooD mode.