Install Docker CLI in codex-universal image

[krzemienski]

🐳 Feature Request — Install Docker CLI (and Compose v2) in codex-universal

Why this matters

Modern production services rarely run directly on the host:

• Micro-services are packaged as Docker images.
• Integration tests spin up service meshes with docker compose.
• CI pipelines rely on container isolation to mirror prod.

When Codex checks out a repo that contains a Dockerfile or a docker-compose.yml, it currently fails at the first docker build … or docker compose up because the base image lacks the Docker CLI. That forces users to:

1. Rewrite build scripts to fall back to plain Python commands.
2. Mount a host socket in hackshell mode, losing reproducibility.
3. Skip container-level integration tests entirely.

What this change does

Add a single line to the Dockerfile:

RUN apt-get update -qq  && apt-get install -y --no-install-recommends docker.io

(On distros where Compose v2 is packaged separately, also add docker-compose-plugin.)

This provides:

• docker client — so the repo can docker build .
• docker compose — for multi-container test stacks (Postgres, Redis, etc.)

No daemon is started; the CLI simply talks to a socket that the Codex runtime can mount (/var/run/docker.sock) or to any rootless daemon the user chooses. The security posture is unchanged while container workflows become possible.

Use-cases enabled

Scenario in repo	Current behaviour	Behaviour after fix
make test builds an image and runs pytest in it	docker: not found	Image builds → tests run
npm run dev spins up API & DB with Compose	fails immediately	Both containers start, enabling end-to-end tests
Mono-repo loop building multiple Dockerfiles	crashes on first build	All images build; Codex can parse logs

Scope & impact

• Zero breaking changes for repos that never call Docker.
• Adds ≈ 25 MB compressed to the image (Ubuntu docker.io package).
• No need for privileged mode; standard socket pass-through suffices.

Alternatives considered

• DIND sidecar — heavier, requires --privileged.
• Podman / Buildah — different CLI, breaks existing scripts.
• Kaniko / img — build-only, doesn’t address docker compose.

Installing the canonical Docker CLI is the simplest, least intrusive path to parity with real-world dev environments.

Proposed acceptance criteria

• Inside the codex-universal container, docker --version and docker compose version exit 0.
• A sample repo containing docker-compose.yml launches successfully inside the sandbox.
• Image size increase ≤ 30 MB.

---

Enabling basic Docker tooling lets Codex build, test, and reason about the vast majority of repositories that expect it.

[Fakamoto]

YES PLEASE

[raphaeltm]

Was very excited to start using this until I realized it was a lot less useful for me because every single project I work on uses docker compose 😦

Potentially relevant stuff to make this work:
https://github.com/devcontainers/features/tree/main/src/docker-in-docker (since this is similar to a devcontainer)
https://docs.docker.com/engine/security/rootless/

[Znomon]

Yeah this is frustrating, i would need to re-spin my workflow to integrate this cause docker is everywhere.

Codex is still quite helpful, but I need to checkout its branch and test all its changes manually because the workflow doesnt match.

We will get there. but definitely. bump