import InfoBox from '../components/InfoBox.astro';
import PullQuote from '../components/PullQuote.astro';

The repository development container had grown organically through months of incremental additions, accumulating bespoke orchestration files, custom lifecycle scripts, and fragmented tool definitions. Maintaining that custom setup began competing with application work. The workbench has now been migrated to a standardized single-container scaffold, consolidating the development environment around a unified Dockerfile and configuration format while preserving every project-specific service, custom egress firewall rule, and toolchain integration through explicit project-owned extension points.

<InfoBox title="Standardized scaffolds with project blocks" variant="note">
The shared container model replaces ad-hoc orchestration with a single-container pattern, providing common security defaults while leaving designated hook blocks for project services, toolchains, and environment credentials.
</InfoBox>

## Accommodating project services

Moving away from a multi-container compose architecture meant bringing the database directly into the main development container as a local backing service. An in-container PostgreSQL instance now boots during container initialization, automatically verifying a bootstrap marker to seed schema migrations on a fresh volume. Bringing the database inside the primary container eliminated container networking quirks and simplified volume mounts, while explicit port forwarding keeps the local development server accessible to host browsers without exposing internal network plumbing.

Restoring the project specialized tooling relied on the scaffold extension points. Pinned package versions, browser automation binaries, and model context protocol launchers were rewired into dedicated lifecycle blocks. Along the way, the migration corrected a subtle permissions trap: earlier installation scripts had temporarily resorted to running global package installations through administrative privilege, but repointing the global package prefix allowed assistant tools and project dependencies to install cleanly under the unprivileged workspace user account.

<PullQuote>Standardizing the container architecture allowed four distinct assistant toolchains to share one secure sandbox.</PullQuote>

## Four assistants in one sandbox

The most visible change inside the upgraded workbench is the expanded suite of developer assistants. Building on [prior work harmonizing permission postures across tools](/posts/three-aliases-one-posture#dropping-the-phantom-boundaries), the container now hosts four distinct command-line coding assistants side by side: Claude Code, OpenAI Codex, Google Antigravity, and GitHub Copilot CLI. Each tool operates within the same default-deny network sandbox, requiring targeted egress firewall allowances for installer redirect domains and API endpoints while sharing access to project MCP wrappers and local test runners.

Consolidating the devcontainer into a standard scaffold establishes a stable baseline as multi-agent development becomes the default pattern for the project. With common infrastructure, local services, and security boundaries cleanly separated from project extensions, adding new assistant tools or upgrading underlying runtimes is now a localized configuration change rather than an orchestration overhaul.