Continuity is not reproducibility.
VS Code 1.138 adds local Dev Container execution for agent sessions in the Agents window. With the setting enabled, a folder that has a supported Dev Container configuration exposes a Use Dev Container action; Docker is required, and the feature is rolling out gradually. The release also expands Codex support across subscriptions and apps, can turn a workspace-less quick chat into a folder or isolated-worktree session, and adds optional cleanup for merged sessions.[1]
These are different kinds of movement. A conversation can move between surfaces. A job can move from a bare host into a defined container. A quick chat can acquire a workspace. Product UI tends to compress all of that into “continue,” but operators should not. State portability, filesystem attachment, and runtime placement carry different failure modes.
The chat remembers what you meant. The environment decides what the meaning can touch.
The host owns the session. The project should own the shop floor.
Microsoft’s Agent Host architecture puts long-running session state in a dedicated process rather than tying it to one editor window. Its Agent Host Protocol sends a snapshot followed by ordered actions so multiple clients can converge on the same session view. The host can be local or remote, and harnesses retain their own loops and capabilities behind adapters.[2]
That is a useful control-plane boundary. It is not a runtime manifest. The host can remember the conversation while the wrong Node version, missing system package, surprise shell profile, broad home-directory mount, or ambient credential quietly changes the work. Persistent state makes a drifted environment more persistent, not less drifted.
A dev container is policy you can diff.
The Development Container Specification describes a repeatable development environment with execution metadata, lifecycle commands, users, environment variables, mounts, ports, host requirements, and tool customizations. A definition can be image-, Dockerfile-, or Compose-based. Source normally stays outside the container and is mounted in, which preserves in-flight edits when a container fails to start.[3]
That is the makeover: move setup lore out of one senior engineer’s shell history and into a file the repository can review. But do not confuse “defined” with “safe.” A dev container can request privileged mode, capabilities, mounts, environment variables, forwarded ports, and lifecycle commands. Reproducible authority can still be excessive authority.
Pin the tiny tricks too.
Will Keleher’s field note on small programming tricks makes the human version of the same argument: a fuzzy history search, git log -S, a database probe, or one company-specific recovery command can save disproportionate time. He suggests one trick a day—small enough to absorb, useful enough to spark discussion.[4]
Put the durable ones in the environment or its documentation. If the agent needs a formatter, database client, or diagnostic command, declare it. If a trick is intentionally host-only, say so. The goal is not to containerize taste. It is to stop pretending accidental workstation history is a dependable build input.
Route first. Then grant.
Before launching a session, name the execution route, exact definition or host identity, source mount, runtime user, network posture, credential source, and proof command. A container is usually better for project-shaped work; a remote host may be right for specialized hardware or private services; the bare host is still useful for a tiny, inspected task. The correct answer is not always “container.” The correct answer is always explicit.
The bay below replaces a vague environment picker with a route plus four independent declaration locks. It runs nothing and measures nothing. Its gauge is an openly labeled planning proxy, and even all four locks only produce a template ready receipt.