VS Code agora pode executar uma sessão de agente de IA dentro do Dev Container do seu projeto: o agente compila, testa e instala com as ferramentas do projeto, não com o que você tem em sua máquina. Chegou com VS Code 1.138 (16 de setembro de 2026), inicia-se com a ação Use Dev Container na janela de agentes (Agents window) e requer Docker.
Status em 21 de setembro de 2026: a documentação do VS Code marca a função como experimental e a configuração que a controla vem desativada por padrão. As notas da versão indicam que está sendo ativada gradualmente, então é possível que você ainda não a tenha ativa; você pode ativá-la manualmente (veja abaixo). A Agents window, o único lugar onde funciona, está em Preview.
Por que executar um agente de IA dentro de um Dev Container?
Porque um agente que roda em sua máquina usa seu Node, seu Python, seus compiladores e seus pacotes globais, e faz isso com as permissões de sua conta. Isso gera dois problemas.
O primeiro é a deriva de ambiente. O “funciona” do agente vale o que vale seu ambiente: se sua máquina tem Node 22 e o projeto fixa Node 20, o agente pode passar em testes que seu CI vai rejeitar.
O segundo é o escopo. A própria documentação de sandbox do VS Code adverte que os comandos de terminal do agente podem executar processos com as mesmas permissões do sistema operacional que sua conta de usuário.
Um Dev Container resolve o primeiro de raiz: o ambiente é definido no repositório, é igual para todo o time e o agente o herda. Também ajuda com o segundo, embora não completamente; a seção de segurança abaixo explica os limites.
O que é um Dev Container e o que vai em devcontainer.json?
Um Dev Container é um contêiner Docker descrito por um arquivo devcontainer.json dentro do seu projeto, que diz ao VS Code qual imagem, ferramentas e runtimes o ambiente de desenvolvimento deve ter. O formato é uma especificação aberta (containers.dev), então não te prende ao VS Code.
A configuração fica em .devcontainer/devcontainer.json, ou em .devcontainer.json na raiz do projeto. O exemplo mínimo da documentação do VS Code simplesmente aponta para uma imagem pré-compilada:
{
"image": "mcr.microsoft.com/devcontainers/go:1"
}
Não é necessário escrevê-lo à mão. A extensão Dev Containers (ms-vscode-remote.remote-containers) inclui o comando Dev Containers: Add Dev Container Configuration Files…, que gera o arquivo a partir de um modelo, de um Dockerfile existente ou de um arquivo Docker Compose.
Se você ainda não trabalha com contêineres no seu dia a dia, em yoDEV temos um guia anterior sobre ambientes de desenvolvimento consistentes com Docker.
Como usar Dev Containers com agentes de IA no VS Code?
Você precisa de Docker em execução, uma configuração de Dev Container na pasta e uma configuração ativada.
1. Verifique os requisitos. Docker instalado e em execução, com a CLI do Docker disponível no PATH. A pasta local deve conter .devcontainer/devcontainer.json ou .devcontainer.json.
2. Ative a configuração. Abra Settings, procure por chat.agentHost.devContainer.enabled e ative-a. É uma configuração de aplicação, não de workspace.
3. Abra a janela Agents. Você tem três opções:
- Clique em Open in Agents na barra de título.
- Execute Chat: Open Agents window na paleta de comandos.
- Execute
code --agentsem um terminal.
4. Inicie uma sessão dentro do contêiner.
- Selecione New.
- No seletor de workspace, expanda o menu da sua pasta e escolha Use Dev Container. O rótulo do workspace adiciona o sufixo “- Dev Container”.
- Se mudar de ideia antes de começar, escolha Use Local no mesmo menu.
- Escolha um harness, configure a sessão e digite seu prompt.
A partir daí, o Agent Host (o processo que executa o agente) roda dentro do contêiner, enquanto a janela Agents continua em sua máquina. De acordo com a documentação do Agent Host, as edições de arquivos e os comandos são executados no ambiente que contém o host.
Por que a opção “Use Dev Container” não aparece?
As causas mais prováveis são quatro:
- A configuração não está ativada. Devido ao lançamento gradual, pode ainda estar desativada em sua instalação.
- A pasta não tem uma configuração de Dev Container compatível.
- Docker não está em execução, ou sua CLI não está no
PATH. - Você está na visualização de chat normal. A ação existe apenas na janela Agents.
Se o contêiner não inicia, abra o painel Output e selecione o canal Dev Container do workspace: lá estão os registros de configuração e conexão.
Funciona com Claude e Codex, ou apenas com Copilot?
O Agent Host foi pensado para vários harnesses: sua documentação mostra adaptadores para Copilot, Claude e Codex. Os passos para Dev Containers apenas indicam que você escolha um harness disponível.
Em 21 de setembro de 2026, a documentação não detalha quais harnesses estão confirmados dentro de um contêiner, então teste o seu antes de depender dele.
Funciona no Windows?
Sim, através do Docker Desktop:
- Windows 10 Pro/Enterprise: Docker Desktop 2.0 ou superior.
- Windows 10 Home: Docker Desktop 2.3 ou superior com o backend WSL 2.
- Linux: Docker CE/EE 18.06 ou superior. O pacote snap do Docker no Ubuntu não é suportado.
Duas coisas não funcionam no Windows: imagens de contêineres Windows e Docker Toolbox.
Quais são as limitações?
- Sem worktrees. Uma sessão em Dev Container trabalha diretamente no workspace do contêiner e não pode ser combinada com New Worktree. Você perde o padrão de “deixar o agente trabalhar em uma cópia isolada da branch”.
- Uma única pasta. A janela Agents ainda não suporta sessões multi-root.
- Estado experimental. O comportamento e as configurações podem mudar entre versões.
Um Dev Container é uma sandbox para o agente?
A visão de Grego:
É uma fronteira real, mas não deve ser confundida com um cofre. Eu usaria essa função e, ao mesmo tempo, seria claro com minha equipe sobre o que ela oferece e o que não oferece.
O que oferece. A própria documentação de sandboxing da Microsoft coloca Dev Containers acima da sandbox de terminal, que é mais leve: deixa claro que o sandboxing de terminal não substitui o isolamento oferecido por sessões na nuvem ou Dev Containers. Os comandos do agente são executados contra o sistema de arquivos e as ferramentas do contêiner, não contra seu diretório pessoal, seus pacotes globais ou seus outros projetos.
O que não oferece.
- Seus arquivos de projeto ainda estão expostos. Uma pasta local aberta em um Dev Container normalmente é montada do seu disco (bind mount), então as edições do agente podem chegar aos seus arquivos reais. Somado ao fato de não haver opção de worktree, um mau turno do agente edita seu checkout, não uma cópia.
- Suas credenciais podem viajar com você. A documentação de Dev Containers indica que, se você usar um gerenciador de credenciais do Git, o contêiner provavelmente já terá acesso a elas. É uma conveniência para você, e também é acesso para o agente.
- A rede não fica restrita. Nada na configuração do Dev Container limita o tráfego de saída. A sandbox de terminal do VS Code tem controles próprios para isso, como
chat.agent.sandbox.allowNetworke uma lista de domínios permitidos. São camadas distintas, e você pode usar ambas.
Minha recomendação para equipes: que o Dev Container seja o local padrão onde os agentes são executados, porque a reprodutibilidade por si só o justifica. Faça commit antes de cada sessão do agente e trate o isolamento do contêiner como uma camada, não como todo o modelo de segurança. Desenvolvemos o padrão geral em Agentes de código precisam de sandboxing — não apenas bons prompts e em Containment-First Agents, e cobrimos a aposta da Microsoft em isolar agentes a nível de sistema operacional em A Sandbox da Microsoft para Agentes de IA Chega ao Kernel.
O que mais o VS Code 1.138 traz para agentes e Codex?
- Codex no VS Code, ampliado. Codex no Agent Host agora pode usar uma assinatura do GitHub Copilot ou do ChatGPT, e você pode alternar entre modelos sem perder a conversa. As sessões podem passar do app ChatGPT para VS Code, e Codex pode usar as ferramentas integradas, de extensões e MCP do VS Code. As configurações são
chat.agentHost.codexAgent.enabledechat.editor.codex.preferAgentHost. - Pull requests a partir de sessões de agente. Um único formulário permite editar o título e a descrição gerados, marcar o PR como rascunho e escolher opções de merge. A opção Agent Merge é experimental e depende de
chat.agentMerge.enabled. - Limpeza de sessões (Preview). As sessões cujos pull requests já foram mesclados podem ser marcadas como concluídas automaticamente e, se desejar, excluídas após um período de carência. Vem desativado por padrão.