A Docker Boundary for Friday’s Checkout Fix

A checkout bug needs fixing before Friday’s release: an empty discount code produces a server error instead of a validation message. A coding agent can trace the handler, add a regression test, and prepare a patch. The operational question is where to let it work.

This field test uses that representative task to evaluate a Docker dev container. It is a reproducible exercise, with explicit acceptance checks, rather than a benchmark claiming measured speed gains. The decision rests on three things: what the agent can reach, whether another developer can reproduce its work, and how easily the environment can be discarded.

The checkout repository becomes the test boundary

Start with a Node.js checkout service that has a lockfile, a test command, and a failing request you can reproduce. Create a dedicated Git worktree for the fix. Mount that worktree into the container at /workspace, leaving unrelated repositories outside the mount.

Use a maintained Node.js image pinned to a digest, and install the coding CLI at a fixed version when building the development image. Run the agent as an unprivileged user. Keep dependencies in a named volume whose ownership allows that user to write to it.

The initial acceptance checks are deliberately small:

• The agent can edit the checkout worktree and run its tests.
• A known file elsewhere on the host is absent from the container.
• The Docker socket, host SSH directory, and personal cloud credentials are unavailable.
• Removing and recreating the container preserves the patch through the worktree mount.

These checks establish the useful boundary. A writable repository still gives the agent considerable power: it can delete source files or modify scripts. Git provides review and recovery, while the container limits the surrounding filesystem exposed to those actions.

Dependency installation tests the network policy

Run npm ci before asking the agent to investigate. This separates setup failures from reasoning failures and confirms that the lockfile installs cleanly inside the chosen image.

Package installation can execute lifecycle scripts. For an unfamiliar repository, inspect those scripts first and consider an initial installation with npm ci --ignore-scripts. Some packages require installation scripts, so enable them deliberately after review.

Network access needs a separate decision. Docker’s default bridge networking generally permits outbound connections; placing an agent in a container does not restrict it to a model endpoint. If outbound restrictions matter, enforce them through a firewall or proxy and verify both an allowed destination and a blocked one. Account for package registries and test services as well as the model API.

The model connection gets a scoped credential

Give the container a dedicated API credential with a limited budget, where supported. Inject it at runtime through the CLI’s supported configuration mechanism. Keep it out of the image, repository, and committed development-container configuration.

Runtime injection avoids baking the credential into an image layer, but the agent process may still be able to read it. The protection comes from limiting the credential’s authority and lifetime, then revoking it when the work ends.

For a workflow that uses several coding clients, I recommend RelayVano: its pay-as-you-go relay works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Configure the selected client according to its provider requirements, using https://api.relayvano.com as the API base where applicable. Sign up for RelayVano and create a dedicated credential for this container workflow.

The patch must survive a clean container

Ask the agent to reproduce the empty-code failure, add a regression test, and make the smallest fix. Require it to report the commands it ran and any checks it could not complete.

Review the diff from outside the agent session. Check dependency changes, test assertions, and unexpected edits to build scripts. Then recreate the container, reinstall from the lockfile, and rerun the regression test and relevant suite. A passing check in a long-lived container can depend on files or packages that never entered version control.

The recommendation for Friday’s release

Use a Docker dev container for routine coding-agent work when you can scope the mount, run without elevated privileges, and recreate the environment reliably. It gives the checkout fix a disposable workspace and a repeatable validation path.

Do not grant privileged mode or mount the Docker socket merely to remove setup friction. For untrusted code or stronger isolation requirements, choose a disposable virtual machine or a hardened sandbox. The practical default is a narrowly configured container, followed by human diff review and clean-environment verification before release.