VS Code agents can now work inside your remote Dev ContainerVS Code agents can now work inside your remote Dev Container

The agent needs the project’s actual environment

An agent running commands on my laptop is not really working on the project when the application lives on a server, a virtual machine, or WSL. It can inspect the code, but it may hit a different PHP version, miss an extension, use another Composer setup, or fail to reach services that only exist in the homelab. The issue is not the model itself; it is the gap between where it works and where the application actually runs.

VS Code 1.139 adds a practical way to close that gap. From the desktop Agents window, an agent session can run inside the Dev Container for a project hosted over SSH, Tunnel, or WSL. File operations and commands then run in the repository’s configured container instead of on the computer where I opened VS Code. (code.visualstudio.com)

Why this matters in a homelab

This fits well with Laravel projects that live on a homelab server. When the Dev Container already defines PHP, Composer, Node, and project dependencies, the agent can use that same toolchain to install packages, run tests, or inspect a migration. I do not need to reproduce the full stack on my laptop just to ask an agent to do some work.

It is also useful when the project depends on services running alongside the container, such as a database, Redis, or a local mail service. The Dev Container and its network still need to be configured so the application can reach those services, exactly as they would when I work on the project myself. The agent does not gain automatic access to the whole homelab; it only gets the environment and permissions available to the container.

The minimum setup

This feature is restricted to the desktop Agents window and requires an experimental setting. I can enable it through the Settings interface or make it explicit in my VS Code configuration. The documented setting is:

{
  "chat.agentHost.devContainer.enabled": true
}

The repository also needs a Dev Container configuration at .devcontainer/devcontainer.json or .devcontainer.json. Docker must be installed, running, and available on the PATH of the machine that contains the project folder; when the project is remote, Docker must run on that remote host rather than on the laptop. (code.visualstudio.com)

Starting a session

I open the Agents window, create a new session, and select the remote project folder. In the workspace picker, I expand the folder options and choose Use Dev Container before sending the first prompt. VS Code adds the - Dev Container suffix to the workspace label, which makes it clear where commands will run. (code.visualstudio.com)

For a remote project, the related connection must already be configured in the Agents window. The documented options cover SSH, Tunnel, and WSL hosts, but the host must also advertise Dev Container support before the option becomes available. If the menu entry is missing, enabling the setting alone will not fix it; the connection, Docker installation, and repository configuration all need checking. (code.visualstudio.com)

The fine print

This is still experimental and may change or be removed in a later release. It is not a general feature for every VS Code window either: it is currently available in the desktop Agents window. I would treat it as a useful workflow to evaluate rather than a finished infrastructure component. (code.visualstudio.com)

Dev Container sessions work directly in the container workspace and cannot be combined with New Worktree. The option is also unavailable for unsupported hosts or project folders nested inside another remote environment. When a container fails to start, the workspace-specific Dev Containers channel in the Output view is the right place to begin troubleshooting. (code.visualstudio.com)

There is a more practical concern too: an agent that can run tests can also run commands that consume resources, modify development data, or talk to services reachable from the container. Before enabling automatic approvals, I would review mounts, environment variables, credentials, and the network access granted to that Dev Container. The real isolation boundary depends on how the environment is built, not on the feature name.

One less gap between request and validation

The important part is not simply that an agent can open a remote terminal. It is that it can work from the same reproducible environment definition as the project, including its versions and dependencies. For a homelab hosting several projects, that means fewer duplicated setups and fewer laptop-specific variations to maintain.

This does not replace reviewing changes, running relevant tests, or protecting services that contain important data. It does make agent-assisted work more credible when the code lives somewhere other than the machine in front of me. If the Dev Container already describes the project environment properly, it can now describe the agent environment as well. (code.visualstudio.com)

Source: GitHub Copilot weekly releases — September 21

Official documentation: Visual Studio Code 1.139