A Cursor lançou o Self-Hosted Machines, que permite às equipes rodar a parte de execução de ferramentas dos seus agentes de programação na nuvem em máquinas geridas por elas mesmas. Só o ambiente de execução é deslocado: o loop do agente, o raciocínio e o planejamento continuam na nuvem da Cursor, que também segue responsável por iniciar e agendar as tarefas.
A conexão funciona ao contrário: a máquina da empresa instala a CLI da Cursor, executa agent worker start e, a partir dela, estabelece uma conexão HTTPS de saída permanente com a nuvem da Cursor. A Cursor afirma explicitamente que a plataforma nunca inicia uma conexão de entrada para dentro da rede da empresa. Para as equipes de segurança, isso é um canal de mão única, só de saída, que não exige abrir portas de entrada no firewall.
Por que trazer a execução de volta
A Cursor cita três cenários. No primeiro, o agente precisa de acesso direto a repositórios de código, serviços internos e bancos de dados dentro da rede da empresa, algo que uma máquina virtual hospedada não alcança. No segundo, é necessário hardware específico, como uma GPU para treinamento ou um Mac para compilar aplicativos iOS. No terceiro, o sistema operacional ou o pipeline de build é pesado demais para caber em uma imagem padrão na nuvem.
Esses três casos afetam principalmente grandes empresas. Equipes pequenas e médias não encontram grandes obstáculos ao usar sandboxes hospedados, enquanto o setor financeiro, a saúde e a indústria de grande porte costumam ter exigências de conformidade que simplesmente proíbem que o código saia para infraestrutura de terceiros. Até agora, esses clientes simplesmente não podiam deixar os agentes entrarem.
Dois formatos e uma lista de parceiros
A configuração tem dois níveis: My Machines conecta um único notebook ou uma única máquina virtual a uma conta pessoal; Pools é uma fila nomeada voltada para equipes e empresas, que escala a capacidade automaticamente conforme o volume de solicitações. Esse segundo modo corresponde a cenários em que dezenas ou centenas de pessoas compartilham o mesmo conjunto de máquinas de build.
Do lado dos sandboxes, a Cursor se associou a vários fornecedores, incluindo AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace e Vercel. Essa lista de nomes deixa clara a posição do lançamento: a Cursor não pretende construir seu próprio ambiente de execução isolado, e sim deixar essa camada nas mãos de quem já faz isso, concentrando-se no agendamento dos agentes e nos modelos. A Namespace oferece algo particular: consegue subir um Mac real para cada sessão de agente na nuvem.
Os workers Linux e Mac também abrem o controle do navegador: basta instalar o Chrome ou as dependências do Chromium na máquina para que o agente consiga abrir uma página sozinho e verificar as alterações.
Um número que fala por si
A Cursor revela que mais de 60% dos pull requests mesclados internamente já são criados por agentes na nuvem. O número aparece em um texto sobre implantação corporativa, com uma intenção clara: provar primeiro que a própria empresa usa a tecnologia, antes de pedir que os clientes entreguem suas máquinas.
Do ponto de vista do produto, a Cursor vem avançando há um ano rumo à camada de agendamento: primeiro levou os agentes para a nuvem, depois resolveu a velocidade de inicialização, e agora trata de onde a execução acontece. A disputa entre ferramentas de programação deixou de girar em torno da qualidade do autocompletar e passou a girar em torno de quem é dono do ambiente de execução — quem conseguir oferecer ao mesmo tempo "experiência gerenciada" e "código que não sai da rede" vai ficar com o orçamento dos grandes clientes.
Fontes: blog oficial da Cursor, CocoLoop, documentação pública dos fornecedores de sandbox; a proporção de 60% de merges internos, o modo de conexão e a lista de fornecedores seguem as declarações oficiais da Cursor.