Visual Studio Code 1.139 shipped to the Stable channel on September 23, 2026, and Microsoft confirmed it quietly changes how AI coding agents work. Until this release, an agent session in the Agents Window could only run inside a Dev Container on your local machine, as Microsoft shipped it in 1.138. Now it can run inside a Dev Container hosted over SSH, a Remote Tunnel, or WSL, two additional environments beyond the local folder, which means the agent gets the exact toolchain, package versions, and system libraries your project actually needs instead of whatever happens to be installed on your laptop, provided Docker itself is installed and running on whichever host actually builds the container.
This tutorial walks through the full setup: updating VS Code, wiring up a devcontainer.json built for agent workloads, connecting to a remote host, and running a constrained multi-file agent session with a real test loop. By the end you will have a working project, a checklist of pitfalls that trip up most developers on their first try, and a troubleshooting table for when the container refuses to attach. Expect to spend about 60-75 minutes end to end, most of it waiting on the first container build.
The setup covers thirteen concrete steps, from updating VS Code and installing the right extension pack through writing a devcontainer.json and Dockerfile suited to agent workloads, connecting over SSH or WSL, and running a full plan-review-test-approve loop with a real Node.js project. Along the way you will hit five recurring pitfalls that account for most first-attempt failures and a nine-item troubleshooting table for when the container build stalls or the agent silently falls back to local execution.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why This Matters for Teams Running Agentic Coding Workflows
The shift matters because agent-driven coding has moved past single-file autocomplete into multi-file, multi-step tasks that run for minutes at a time, sometimes installing dependencies, running migrations, or executing whole test suites without a human watching every keystroke. Running that kind of session against a developer’s bare host environment has always been a gamble: the agent might discover a Python version mismatch, a missing system library, or a stale cached dependency that produces a false pass or false fail. None of that is the agent’s fault, it is a byproduct of every developer’s machine looking slightly different.
Dev Containers solve that by pinning the entire toolchain to a Dockerfile checked into source control, so the agent, the developer, and the CI runner all execute against an identical environment. What changed with VS Code 1.139 is that this consistency no longer requires the container to live on the same machine as the editor. A team standardizing on agentic workflows can now keep one well-provisioned build server, point every developer’s VS Code at it over SSH or a tunnel, and get identical agent behavior across a fleet of laptops with wildly different specs, without asking anyone to install Docker Desktop locally at all.
What VS Code 1.139 Actually Changes for Dev Container Agents
Agent sessions in local Dev Containers were already available in VS Code 1.138, released September 16, 2026. That update let an agent build, test, and edit code using a project’s own Dockerfile and devcontainer.json instead of the host machine’s global environment. The gap was that it only worked when the container ran on the same computer as the editor.
VS Code 1.139 removes that restriction. Agent sessions launched from the Agents Window can now attach to a Dev Container running over any of three remote host types Microsoft added in this release: Remote-SSH, VS Code’s Remote Tunnels, or WSL. In practice, this means a developer on a Windows laptop with 16GB of RAM can point an agent at a Dev Container running on a beefier Linux build server, and the agent inherits that server’s compilers, databases, and installed SDKs, provided Docker is running on that remote host, since Microsoft lists Docker as a hard requirement for these remote agent sessions. The same release adds session cleanup in preview, which marks combined sessions as completed and lets you delete stale sessions after a waiting period instead of letting them pile up in the sidebar.
The practical upside is reproducibility. An agent that edits code, runs a build, and executes tests inside a container defined by devcontainer.json is working against the same environment every teammate and every CI runner uses. An agent editing files against your host’s ad hoc Python install or a globally installed Node version is not.
There is also a resource argument that matters once you factor in what agent sessions actually cost in compute. Building a container image, running a full test suite, and spinning up a local database for integration tests is heavier than most laptops handle gracefully while their owner is also running a browser, Slack, and a video call. Offloading that to a shared build server with more cores and more RAM means the agent’s build and test cycle finishes faster, and the developer’s machine stays responsive for everything else they are doing at the same time.
Local Agents vs Remote Dev Container Agents: What Changed
The table below lays out the difference between the two modes so you can decide which one fits your workflow before you start configuring anything.
| Capability | Local Dev Container Agent (1.138) | Remote Dev Container Agent (1.139) |
|---|---|---|
| Host requirement | Docker Desktop or equivalent on the same machine as VS Code | SSH host, Remote Tunnel, or WSL distro, container runs remotely |
| Hardware ceiling | Limited to local CPU, RAM, and disk | Limited to remote host specs, can be a shared build server |
| Toolchain source | Project’s own Dockerfile, local build | Project’s own Dockerfile, built on the remote host |
| Typical latency | Near-instant file edits and test runs | Adds network round-trip, noticeable on large diffs |
| Best fit | Solo developers, laptops with spare capacity | Teams sharing a build server, low-spec client machines, WSL-only dependencies |
Prerequisites and Version Requirements
Before you start, confirm every tool below is installed and at the right version. Skipping the version check is the single most common reason this setup fails on the first attempt.
| Tool | Minimum version | Why it matters |
|---|---|---|
| Visual Studio Code | 1.139 (Stable) | Remote Dev Container agent sessions require this build or newer |
| Dev Containers extension | Latest from Marketplace | Parses devcontainer.json and manages the container lifecycle |
| Remote-SSH or Remote Tunnels extension | Latest from Marketplace | Required only if your Dev Container runs on a remote host over SSH or a tunnel |
| WSL extension | Latest from Marketplace | Required only if your Dev Container runs inside a WSL distro on Windows |
| Docker Engine or Docker Desktop | Recent stable release | Must be running on whichever host actually builds the container |
| GitHub Copilot or equivalent agent extension | Latest from Marketplace | Provides the Agents Window and the underlying coding agent |
| Git | 2.40 or newer | Needed inside the container for the agent to commit and diff changes |
You will also need SSH key access to the remote host if you are not using WSL, and enough disk space on that host for the container image, typically 2-6GB depending on your base image. If you are connecting over a Remote Tunnel instead of SSH, you need a Microsoft or GitHub account signed into VS Code on both ends.
One version detail worth double-checking: the Dev Containers extension and the agent tooling update independently of VS Code itself, so “latest from Marketplace” is not a one-time check. Extensions auto-update by default, but if your organization disables auto-update for managed installs, stale extension versions are a frequent cause of the remote-attach badge failing to appear even when VS Code itself is correctly on 1.139. If you hit that specific symptom later in this tutorial, this is the first place to look.
Step 1: Update VS Code to 1.139 Stable
Open the Command Palette with Ctrl+Shift+P (Cmd+Shift+P on macOS) and run Check for Updates. If you are on Linux using the apt or snap channel, update through your package manager instead, since the in-app updater is sometimes disabled on those builds. Confirm the version from Help > About, it should read 1.139.x. If your organization pins VS Code to an older build through a managed policy, you will need an exception before this workflow works, since the Dev Container agent APIs did not exist before 1.138.
Step 2: Install the Dev Containers and Remote Development Extension Pack
Open the Extensions view (Ctrl+Shift+X) and install the “Dev Containers” extension from Microsoft. Then install whichever remote transport you plan to use: “Remote – SSH” for a server you access by hostname, “Remote – Tunnels” if you want to avoid opening an inbound SSH port, or the “WSL” extension if your Dev Container will run inside a Windows Subsystem for Linux distro. You do not need all three, only the one matching your target host. If your own workflow also relies on custom extensions, see our walkthrough on publishing VS Code extensions to Open VSX for how extension distribution works outside the default Marketplace.
Step 3: Connect to Your Remote Host
For SSH, open the Command Palette and run Remote-SSH: Connect to Host, then enter your user and hostname, for example [email protected]. For a Remote Tunnel, run the tunnel setup on the host machine first with code tunnel from its terminal, then connect from your local VS Code through the Remote Explorer panel. For WSL, run WSL: Connect to WSL and pick your installed distro. In all three cases, VS Code opens a new window connected to that environment before you touch the Dev Container itself, this is a separate step from opening the container.
Which transport you pick changes your security posture. Remote-SSH requires an inbound-reachable host and a key pair you manage yourself, which is the standard choice for a build server already sitting inside a company network or VPN, and it is worth pairing with our guide on setting up a Tailscale zero-trust VPN if you want that host reachable without exposing a public SSH port at all. Remote Tunnels route through Microsoft’s relay infrastructure and authenticate with your Microsoft or GitHub account, which avoids opening an inbound port but means the connection depends on that relay’s availability. WSL sidesteps the network question entirely since everything happens on one Windows machine, but it only helps if your dependency problem is “this only builds on Linux,” not “my laptop is underpowered.” For a broader comparison of remote development approaches across editors, see our VS Code vs Cursor remote dev SSH setup guide.
Step 4: Write a devcontainer.json for Agent Workloads
Once connected to the remote environment, open your project folder and create a .devcontainer directory at the repository root. Inside it, add a devcontainer.json file. The example below is built for a Node.js API project and includes settings that matter specifically for agent sessions: forwarded ports for a local dev server, a postCreateCommand that installs dependencies before the agent ever touches the repo, and extensions that give the agent linting and type-checking feedback.
{
"name": "api-agent-container",
"build": {
"dockerfile": "Dockerfile"
},
"forwardPorts": [3000, 5432],
"postCreateCommand": "npm install",
"postStartCommand": "npm run db:migrate",
"customizations": {
"vscode": {
"extensions": [
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode",
"ms-vscode.vscode-typescript-next"
]
}
},
"remoteUser": "node",
"mounts": [
"source=${localWorkspaceFolderBasename}-node-modules,target=${containerWorkspaceFolder}/node_modules,type=volume"
]
}The named volume mount for node_modules matters more than it looks. Without it, every container rebuild reinstalls dependencies from scratch, which slows down every agent session that triggers a rebuild.
Step 5: Add a Dockerfile and Lock Your Toolchain
Next to your devcontainer.json, add a Dockerfile that pins exact versions rather than floating tags. Floating tags like node:lts are the fastest way to make an agent’s test run pass today and fail next week when the base image updates underneath you. If Dockerfile syntax is new to you, our Docker production stack tutorial covers the fundamentals this file builds on.
FROM node:22.11-bookworm
RUN apt-get update && apt-get install -y --no-install-recommends \
git \
postgresql-client \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /workspace
RUN npm install -g npm@10
USER nodeKeep this image minimal. Every extra package is something the agent can accidentally rely on that will not exist in your CI image if the two ever drift apart.
Step 6: Reopen the Repository in Its Dev Container
With the devcontainer.json and Dockerfile in place, open the Command Palette and run Dev Containers: Reopen in Container. VS Code builds the image on the remote host, which can take two to five minutes the first time depending on your base image size and the host’s network speed. Subsequent reopens reuse the cached layers and take a few seconds. Watch the bottom-right status bar, it shows “Opening Remote…” followed by the build log if you click into it.
If this is the first Dev Container ever built on that remote host, budget extra time for Docker to pull the base image layers from the registry, since a fresh node:22.11-bookworm pull can add another minute or two on a slow connection. After the first build, Docker’s layer cache on the remote host means later rebuilds only rerun the steps below whatever line in the Dockerfile actually changed, which is why keeping stable, rarely-changing instructions like package installs near the top of the file and volatile steps near the bottom keeps rebuild times short.
Step 7: Validate the Environment Before Launching an Agent
Do not hand control to an agent until you have confirmed the container actually has what you expect. Open the integrated terminal, which now runs inside the container, and check the runtime, package manager, and test command manually.
node --version
npm --version
psql --version
npm test -- --listTests
git statusIf any of those commands return “command not found,” fix the Dockerfile now, before you start an agent session. An agent that discovers a missing dependency mid-task will often improvise a workaround, like installing a package globally or skipping a test, and that workaround silently disappears the next time the container rebuilds.
Step 8: Open the Agents Window and Start a Session
Open the Agents Window from the Activity Bar and click “New Session.” VS Code 1.139 shows a badge indicating the session is attached to your Dev Container rather than the local filesystem, confirm that badge is present before continuing. If it is missing, the agent fell back to local execution, which usually means the container was not fully attached when the session started, close the session and retry after the container shows as connected in the status bar.
Give the session a short, specific first task rather than a broad one, both to confirm the plumbing works and to establish a baseline for how the agent behaves inside this particular container. Something like “list the current test coverage and flag any file with no corresponding test” is a good first task, it exercises the container’s test runner without touching any code, and gives you a fast signal that the environment, the toolchain, and the agent’s shell access all work together correctly. If you have not configured the agent extension itself yet, our GitHub Copilot setup guide covers that groundwork first, and as of October 13, 2026 that setup now includes Gemini 4 Argon, which GitHub took to general availability across eight Copilot clients and all four Copilot plan tiers and which GitHub reports outperformed every prior Gemini model on every coding benchmark it tested, making it worth selecting as the model backing this first agent task.
Step 9: Constrain the Agent With Repository Instructions
Unconstrained agents tend to touch more files than necessary. Add an instructions file at the repository root so every session, including ones started by teammates, inherits the same guardrails.
# AGENTS.md
- Run `npm test` after every change and paste the summary in your response.
- Never edit files under /migrations without explicit approval.
- Do not install new npm packages without listing them and the reason first.
- Keep diffs under 200 changed lines per task unless the task is explicitly a large refactor.
- All new endpoints must include a corresponding test file.These rules do not make an agent infallible, but they narrow the blast radius of a bad edit and give you a clear standard to hold the session to when you review its output.
Step 10: Require a Plan Before Multi-File Edits
Before approving any task that touches more than one file, ask the agent to describe its plan first: which files it intends to change, what tests it will run, and what it expects the diff to look like. This costs you thirty seconds of reading and saves you from discovering, three files in, that the agent misunderstood the task. Treat a plan that does not mention running tests as incomplete and send it back before approving execution.
Step 11: Approve Changes and Review the Diff
Once you approve a task, the agent edits files inside the container and VS Code surfaces the changes in the Source Control view exactly like a local edit would. Review the diff file by file rather than accepting the whole changeset at once. Pay particular attention to test files the agent modified or deleted, since a common failure mode is an agent “fixing” a failing test by weakening the assertion instead of fixing the underlying bug.
Step 12: Run Tests Inside the Container
After reviewing the diff, run the full test suite yourself inside the container terminal rather than trusting the agent’s self-reported summary.
npm run lint
npm run typecheck
npm test -- --coverageBecause the container matches your CI environment, a pass here is a much stronger signal than a pass on your host machine would be. If your CI pipeline uses the same devcontainer.json through the Dev Container CLI, you have effectively run a local CI check before pushing.
Step 13: Manage Session Cleanup and Container Lifecycle
VS Code 1.139 carries forward the session cleanup preview feature from 1.138. Completed agent sessions get marked as done automatically, and you can enable a setting to delete them after a waiting period instead of letting the Agents Window fill up with finished work. Separately, remember that the Dev Container itself stays running on the remote host until you stop it. If you are working on a shared build server, run Dev Containers: Stop Container from the Command Palette when you finish for the day so you are not holding resources another teammate needs.
Isolation and Blast Radius: How Much Should the Agent See
A Dev Container is a real sandbox boundary, not a cosmetic one, but it is not automatically a security boundary against a determined or badly-behaving agent unless you configure it that way. By default, the container shares the project’s source tree through a bind mount, can reach the network unless you restrict it, and runs with whatever permissions the remoteUser has, which is not root if you follow Step 5’s Dockerfile pattern. That is a reasonable default for most day-to-day work, but it is worth being deliberate about three things before you point an agent at a repository with real credentials anywhere in its history.
First, decide what the agent’s shell is allowed to run. Most agent extensions offer an allow-list or approval-per-command setting, and it is worth spending five minutes configuring it rather than accepting “run anything” defaults, particularly for a container attached to a shared build server other people also use. Second, decide what the agent’s shell can reach over the network. If your task genuinely does not need internet access, for example a pure refactor with no new dependencies, block outbound traffic at the container level and remove that entire class of risk for the session. Third, separate the container’s environment variables from your actual secrets. A .env file mounted into the container is visible to any command the agent runs, including a command it was not asked to run but decided to run anyway while debugging.
None of this is unique to VS Code’s implementation, it is the same reasoning security teams apply to any CI runner or build agent with shell access to a repository. The difference with an interactive coding agent is that the person approving each action is watching in close to real time, which is exactly why the plan-before-edit habit from Step 10 and the manual test verification from Step 12 matter as much as the container boundary itself. A sandbox limits what can go wrong technically, a human in the loop limits what actually does. For a look at how agent tool comparisons weigh cost and IDE integration more broadly, see our best AI coding assistants ranking.
Common Pitfalls When Running Agents in Dev Containers
Floating base image tags. Using latest or lts tags means the environment an agent tests against today can differ from what it tests against next week, producing test results that are not reproducible.
Skipping the environment validation step. Jumping straight to an agent session without manually confirming the runtime versions wastes an entire task cycle when the agent discovers a missing dependency mid-task.
No named volume for dependencies. Without a persistent volume for node_modules, vendor directories, or pip caches, every container rebuild reinstalls everything from scratch, turning a five-second reopen into a five-minute one.
Granting the agent unrestricted shell access. An agent with an unconstrained terminal can install packages, modify system files, or run destructive commands inside the container. Scope what commands are allowed before starting a session on anything that touches real data.
Mounting secrets directly into the container. Environment variables and credential files mounted into a Dev Container are visible to the agent and to anything the agent’s shell commands can reach. Use a secrets manager or short-lived tokens instead of baking API keys into devcontainer.json.
Forgetting the remote host needs Docker too. The container builds and runs on whichever machine you are remoted into, not your local laptop. If Docker is not installed and running on that remote host, the reopen step fails with a connection error that looks unrelated to the actual cause.
Treating the agent’s self-reported test summary as verified. Agents describe what they ran and what happened in natural language, and that description can drift from the actual exit code, especially across a long multi-step task. Rerun the test command yourself before approving a merge, the two minutes it costs is cheaper than a broken build reaching main.
Troubleshooting Guide
Most failures in this setup fall into one of three buckets: the container never finishes building, the container builds but the agent cannot attach to it, or the container and agent both work but produce results that do not match what you expect on your host machine. The table below covers the nine most common symptoms across all three buckets, roughly in the order you are likely to hit them the first time through this tutorial.
| Symptom | Likely cause | Fix |
|---|---|---|
| “Reopen in Container” is greyed out | Dev Containers extension not installed or disabled on the remote host | Install the extension inside the remote VS Code window, not just locally |
| Agents Window shows no container badge | Session started before the container finished attaching | Close the session, wait for “Dev Container: connected” in the status bar, then start a new session |
| Build hangs at “Starting container” | Docker daemon not running on the remote host, or insufficient disk space | SSH in separately and run docker info and df -h to confirm |
| SSH connection drops mid-build | Idle timeout on the SSH connection or an unstable network path | Add ServerAliveInterval 60 to your SSH config, or switch to a Remote Tunnel |
| Container builds but extensions do not load | Extensions listed under the wrong customizations key in devcontainer.json | Confirm extensions are nested under customizations.vscode.extensions, not top-level |
| Agent reports a passing test that actually failed | Agent ran tests against a stale cached container layer | Rebuild without cache using Dev Containers: Rebuild Without Cache, then rerun tests manually |
| WSL container works but SSH host does not | Port forwarding or firewall rules blocking the SSH host’s Docker socket | Confirm the remote firewall allows the local Docker socket connection VS Code uses internally |
| node_modules reinstalls on every reopen | No named volume configured for dependency directories | Add a mounts entry with a named volume as shown in Step 4 |
| Agent session silently falls back to local execution | Remote connection dropped after the session started | Check the Remote Explorer panel for connection status and restart the session once reconnected |
Advanced Tips for Production Dev Container Agent Workflows
Once the basic setup works, a few adjustments make this practical for daily use rather than a one-off demo. First, split your devcontainer.json into a base configuration and a docker-compose.yml when your project needs a database or cache alongside the app container, since Dev Containers support multi-service compose setups and an agent can then run integration tests against a real Postgres or Redis instance instead of mocks.
Second, if multiple developers share one remote build server, give each person’s Dev Container a unique container name and volume prefix tied to their username, otherwise simultaneous agent sessions from different people can collide on the same named volumes. Third, treat the devcontainer.json as the single source of truth for your CI image as well. The Dev Container CLI can build and run the same configuration in a GitHub Actions or GitLab CI job, which means the environment an agent tested code against locally is identical to the one that gates your merge.
Fourth, log every agent session’s diff to a file before merging, even a simple git diff > session-log.patch, so you have an audit trail of what an autonomous session actually changed independent of the commit history, which can get squashed. Finally, consider running the highest-risk agent tasks, ones that touch authentication, payments, or data migrations, inside a container with no outbound network access at all, restricting it to the resources explicitly declared in devcontainer.json’s forwardPorts and any proxy you control.
A sixth tip worth the setup time on larger repositories: pre-warm the container’s dependency cache with a scheduled job on the remote host rather than letting the first developer of the day pay the cold-build cost. A simple cron entry that runs docker compose build or triggers a Dev Container CLI build against the latest main branch each morning keeps the cached layers fresh, so the first “Reopen in Container” of the day is a cache hit instead of a five-minute wait. This matters more the larger your team gets, since a slow first build is the kind of friction that quietly pushes developers back toward running agents unsandboxed on their own machines, which defeats the entire point of this setup.
Complete Working Project: A Node.js API With a Sandboxed Agent
Putting the pieces together, here is a minimal but complete project layout you can copy directly. Create these four files at your repository root, then follow steps 6 through 12 above.
This layout intentionally keeps the surface area small so you can verify the whole pipeline, from container build to agent-driven edit to passing test, without debugging an unrelated part of a larger codebase. Once it works end to end, the same devcontainer.json and AGENTS.md pattern scale to a real project by adding services to a docker-compose.yml, expanding the forwardPorts list, and layering in whatever linting and type-checking extensions your stack actually uses. The core loop, plan, edit inside the container, review the diff, run tests inside the container, approve, does not change as the project grows.
project-root/
.devcontainer/
devcontainer.json
Dockerfile
AGENTS.md
package.json
src/
server.js
test/
server.test.jsUse the devcontainer.json from Step 4 and the Dockerfile from Step 5 as-is. Add a minimal package.json with an Express server and a Jest test suite, then reopen in container. A working session looks like this in the terminal output once the agent finishes a task:
$ npm test
PASS test/server.test.js
GET /health
returns 200 with status ok (14 ms)
POST /items
creates a new item and returns 201 (22 ms)
rejects a request missing the name field (9 ms)
Test Suites: 1 passed, 1 total
Tests: 3 passed, 3 total
Time: 1.842 sThat output, produced inside the container rather than on your host, is the signal that the agent’s work is trustworthy enough to review for a merge. From here, the workflow repeats: describe a task, require a plan, review the diff, run tests, approve.
For the official reference on the underlying container spec, see the Development Containers specification and the devcontainer.json reference. Microsoft’s own walkthrough of the base feature is at Developing inside a Container, and the release notes for the two versions covered in this tutorial are at VS Code 1.138 and VS Code 1.139. GitHub’s documentation on enabling an agent for a repository is at Enabling Copilot coding agent, and Docker’s setup guide is at Docker Desktop.
Frequently Asked Questions
Do I need GitHub Copilot specifically, or does this work with any agent extension?
The Agents Window and remote Dev Container attachment are VS Code core features, not exclusive to Copilot. Any extension that plugs into the Agents Window, including Copilot’s agent mode and other agent extensions in the Marketplace, can use a remote Dev Container once it is attached. If you do use Copilot, note that GitHub made Gemini 4 Argon generally available on October 13, 2026 across eight Copilot clients and all four plan categories, and GitHub reports it outperformed every prior Gemini model on every coding benchmark tested, so it is now a reasonable default model for the agent sessions this tutorial walks through.
Does the agent need internet access from inside the container?
Only if the task requires it, for example installing a new package or calling an external API. You can restrict outbound network access at the container or firewall level for tasks where you want the agent limited strictly to the codebase and its declared dependencies.
Is remote Dev Container agent support available in VS Code Insiders only, or Stable?
It shipped in the Stable channel with version 1.139 on September 23, 2026. It is not an Insiders-only or preview feature, though the session cleanup UI introduced alongside it in 1.138 is still labeled preview.
Can I use this with WSL instead of a remote SSH server?
Yes. Connect to your WSL distro first using the WSL extension, then reopen your project in its Dev Container from within that WSL window. The agent session attaches the same way it does over SSH or a tunnel.
What happens to an in-progress agent session if the remote connection drops?
The session pauses and VS Code shows a disconnected state in the Agents Window. Reconnecting to the remote host and reopening the container typically lets you resume, but any in-flight shell command the agent was running at the moment of disconnect should be re-verified rather than assumed to have completed.
Do I need Docker Desktop specifically, or does the Docker Engine on Linux work?
Either works. Docker Desktop is common on developer laptops, but a remote Linux build server typically runs Docker Engine directly without the desktop UI, and VS Code’s Dev Containers extension talks to either through the same Docker socket.
How much does running a Dev Container on a remote build server cost?
There is no VS Code or Dev Containers licensing cost involved, since both are free. Your cost is whatever compute you are already paying for on the remote host, whether that is an existing office build server or a cloud instance you provision separately.
Can two developers run agent sessions in the same Dev Container at once?
Not safely for the same container instance. Each developer should get their own container instance, even on a shared host, to avoid file lock conflicts and agents stepping on each other’s in-progress edits. Use unique container names per user as described in the advanced tips section.
Does this replace cloud-hosted agent sandboxes offered by some AI coding tools?
Not necessarily, they solve overlapping but distinct problems. A cloud-hosted agent sandbox typically runs entirely outside your infrastructure and hands you a diff to review. A remote Dev Container keeps the agent working against infrastructure you already control, whether that is an on-prem build server or a cloud instance in your own account, which matters for teams with compliance requirements around where code and credentials can travel.
