Summary
An existing agent session can keep an obsolete DOCKER_HOST after an agent-box
update/configuration change enables the supervised rootless Docker daemon. The generated
unit environment and tmux global environment point at the correct socket, but the already
running harness and its tool calls keep the old process environment and cannot connect.
This contradicts the shipped guide's promise that DOCKER_HOST is already exported into
every session.
Reproduction observed on a live box
The long-lived Codex pane reported:
$ echo "$DOCKER_HOST"
unix:///run/user/1004/docker.sock
$ docker info
failed to connect to the docker API at unix:///run/user/1004/docker.sock:
dial unix /run/user/1004/docker.sock: connect: no such file or directory
The supervised service was healthy at the same time:
$ systemctl show agent-box-docker@claude.service -p Environment
Environment=HOME=/home/claude XDG_RUNTIME_DIR=/run/agent-box-docker/claude ...
$ test -S /run/agent-box-docker/claude/docker.sock
$ DOCKER_HOST=unix:///run/agent-box-docker/claude/docker.sock docker version \
--format '{{.Server.Version}}'
29.8.0
The generated environment and tmux server had already been corrected:
$ grep '^DOCKER_HOST=' /etc/agent-box/units/claude.env
DOCKER_HOST=unix:///run/agent-box-docker/claude/docker.sock
$ tmux show-environment -g DOCKER_HOST
DOCKER_HOST=unix:///run/agent-box-docker/claude/docker.sock
The stale value was therefore confined to the already-running harness process/pane. A new
tmux window inherited the current global value; the existing Codex process did not.
Expected
After an update adds or changes generated session environment, a live session should not be
left pointing at an endpoint that no longer exists. Possible fixes include restarting/resuming
affected harnesses, providing a compatibility socket, or detecting the mismatch and surfacing
an actionable restart notice.
Acceptance
Starting from a live session whose environment predates containers.enable, enable/update
the container integration without rebooting the box. The existing user-visible session can
then run docker compose against the supervised daemon without a command-scoped
DOCKER_HOST workaround.
Environment
- NixOS agent-box, running revision
894a9aed3dbb7ee583d9c0470401f653235a813c
agent-box@claude.service / tmux server active since 2026-09-16 12:44 PDT
- affected Codex pane active since 2026-09-16 13:48 PDT
- Docker client/server 29.8.0, API 1.56
Summary
An existing agent session can keep an obsolete
DOCKER_HOSTafter an agent-boxupdate/configuration change enables the supervised rootless Docker daemon. The generated
unit environment and tmux global environment point at the correct socket, but the already
running harness and its tool calls keep the old process environment and cannot connect.
This contradicts the shipped guide's promise that
DOCKER_HOSTis already exported intoevery session.
Reproduction observed on a live box
The long-lived Codex pane reported:
The supervised service was healthy at the same time:
The generated environment and tmux server had already been corrected:
The stale value was therefore confined to the already-running harness process/pane. A new
tmux window inherited the current global value; the existing Codex process did not.
Expected
After an update adds or changes generated session environment, a live session should not be
left pointing at an endpoint that no longer exists. Possible fixes include restarting/resuming
affected harnesses, providing a compatibility socket, or detecting the mismatch and surfacing
an actionable restart notice.
Acceptance
Starting from a live session whose environment predates
containers.enable, enable/updatethe container integration without rebooting the box. The existing user-visible session can
then run
docker composeagainst the supervised daemon without a command-scopedDOCKER_HOSTworkaround.Environment
894a9aed3dbb7ee583d9c0470401f653235a813cagent-box@claude.service/ tmux server active since 2026-09-16 12:44 PDT