You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Rewrite build scripts to fall back to plain Python commands.
Mount a host socket in hackshell mode, losing reproducibility.
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.
Uh oh!
There was an error while loading. Please reload this page.
π³ Feature Request β Install Docker CLI (and Compose v2) in codex-universal
Why this matters
Modern production services rarely run directly on the host:
docker compose
.When Codex checks out a repo that contains a
Dockerfile
or adocker-compose.yml
, it currently fails at the firstdocker build β¦
ordocker compose up
because the base image lacks the Docker CLI. That forces users to: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 candocker 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
make test
builds an image and runs pytest in itdocker: not found
npm run dev
spins up API & DB with ComposeScope & impact
docker.io
package).Alternatives considered
--privileged
.docker compose
.Installing the canonical Docker CLI is the simplest, least intrusive path to parity with real-world dev environments.
Proposed acceptance criteria
codex-universal
container,docker --version
anddocker compose version
exit 0.docker-compose.yml
launches successfully inside the sandbox.Enabling basic Docker tooling lets Codex build, test, and reason about the vast majority of repositories that expect it.
The text was updated successfully, but these errors were encountered: