Correção de "Missing HCS Services (hns, vmcompute, vfpext)" no Claude Cowork (2026)

O Claude Cowork falha no Windows quando a pilha de virtualização da qual ele depende não está em execução. Na prática, isso significa uma de três coisas: os componentes do Windows Host Compute Service estão ausentes ou parados (hns, vmcompute, vfpext), o CoworkVMService parou depois de uma reinicialização ou de suspensão, ou a máquina não consegue hospedar a VM, quase sempre por ser Windows Home, onde muitos usuários relatam falhas porque o Home não tem a pilha completa do Hyper-V. Cada caso tem uma correção diferente, e os três podem ser verificados em menos de cinco minutos.

Ainda não instalou? Comece pelo guia de instalação do Claude Cowork para Windows.

Detalhando melhor, essas três causas se dividem em cinco modos de falha distintos: (1) o CoworkVMService para depois de reinicialização ou suspensão, (2) o bug de detecção de plataforma "yukonSilver" marca sistemas compatíveis como não suportados, (3) a edição Windows Home não tem a pilha completa do Hyper-V, o que, segundo muitos usuários do Home, quebra o Cowork, (4) conflitos de rede com VPNs ou Docker na faixa 172.16.0.0/24 e (5) instalações corrompidas do antigo instalador Squirrel. Cada um tem uma correção diferente.

O Cowork chegou ao Windows em 10 de fevereiro de 2026 e ficou disponível para todos os assinantes pagantes (GA) em 9 de abril de 2026. Se você ainda não o instalou, nosso guia de instalação do Claude Cowork no Windows explica a instalação limpa e os três requisitos que ninguém menciona de início. O repositório do Claude Code no GitHub acumula bugs específicos do Windows desde o lançamento: erros enigmáticos de "yukonSilver not supported", abas do Cowork ausentes em máquinas totalmente compatíveis e um serviço de VM que resiste à remoção. Mapeamos os principais modos de falha e o que realmente resolve cada um. Sem enrolação.

Uma coisa que vale saber antes de depurar qualquer coisa: o Cowork agora roda no desktop, na web (claude.ai), no iOS, no Android e no Chrome. As sessões na nuvem continuam quando o notebook está fechado. As sessões no desktop ainda precisam do app aberto para acessar arquivos locais. Todo bug desta página vive na VM local do app para Windows, então, se a sua tarefa não precisa de arquivos deste PC, rodar o Cowork na web contorna todos eles.

O Cowork quebrou depois da atualização do Windows de setembro de 2026

As atualizações de segurança do Windows de 8 de setembro de 2026 (KB5124008 para o Windows 11 24H2 e 25H2, KB5124012 para o 26H1) quebraram o compartilhamento de pastas Plan9 para VMs Linux gerenciadas pelo Host Compute Service. A nota de problema conhecido da Microsoft cita o Claude Cowork e o WSL como apps afetados: a VM inicia normalmente, mas as pastas compartilhadas do Windows não aparecem dentro dela, e os apps podem informar que "no Plan9 drive shares were mounted" (nenhum compartilhamento Plan9 foi montado).

No Cowork, o changelog da Anthropic descreve os sintomas como tarefas que falham ou um workspace que não inicia quando o Cowork roda no seu PC. As sessões na nuvem e o Claude Code (incluindo a aba Code) não foram afetados, e reiniciar ou reinstalar o Claude não ajuda, porque a causa está no Windows.

A correção: a Microsoft lançou atualizações fora de ciclo em 14 de setembro de 2026 que resolvem o problema, e a Anthropic marcou o caso como resolvido no mesmo dia:

1. Abra Configurações → Windows Update e clique em Verificar se há atualizações. A correção é instalada automaticamente, mas pode estar aguardando uma reinicialização.
2. Instale tudo o que for oferecido e depois use Reiniciar (não Desligar).
3. Pressione Win + R, digite winver e confirme que o número do seu build é igual ou superior ao da coluna "Build corrigido".
4. Abra o Cowork e inicie uma tarefa local novamente.

Você não precisa desinstalar a atualização de segurança de setembro para resolver isso; a atualização de 14 de setembro (ou qualquer atualização cumulativa posterior) já contém a correção. O Claude Desktop v1.52386.0 (10 de setembro) também deixou de apagar e reinstalar o workspace quando encontra esse bug e passou a apontar a atualização do Windows como causa, e a v2.110.0 (15 de setembro) fez a tarefa parar com um erro claro quando o seu drive não pode ser acessado, em vez de parecer que iniciou. Se você viu o workspace se reconstruindo repetidamente, atualize também o Claude Desktop.

Se o seu build está atualizado e o Cowork ainda não alcança seus arquivos, o problema é outro desta página; comece pela reinicialização do CoworkVMService.

Solução: Missing HCS Services (hns, vmcompute, vfpext)

Se o Cowork informa um serviço HCS ausente (ou serviços HCS ausentes), significa que o Host Compute Service e seus componentes de rede não estão em execução ou não estão instalados. O HCS é a API de baixo nível que o Hyper-V e os contêineres do Windows usam para criar e gerenciar VMs leves, exatamente o que o sandbox do Cowork usa como base. O VMCompute (vmcompute) hospeda a camada de computação, o HNS (hns) fornece a rede virtual de que o sandbox precisa, e o VFPExt (Virtual Filtering Platform Extension) é o driver de filtragem de pacotes do qual o HNS depende. Se eles não existem ou não iniciam, o Cowork não consegue montar seu ambiente e geralmente falha em silêncio ou exibe um erro de montagem/boot.

Primeiro, verifique se os serviços existem e estão em execução (PowerShell como Administrador):

Get-Service vmcompute
Get-Service hns
# VFPExt is a driver, not a normal service - check it the same way:
Get-Service vfpext -ErrorAction SilentlyContinue

Se algum retornar "Cannot find any service" (não foi possível encontrar nenhum serviço), o recurso subjacente não está instalado. Corrija assim:

1. Abra Painel de Controle → Programas → Ativar ou desativar recursos do Windows (ou execute optionalfeatures).
2. Ative Hyper-V, Plataforma do Hipervisor do Windows e Contêineres.
3. Clique em OK e reinicie quando solicitado: os serviços só são registrados depois de uma reinicialização.
4. Execute Get-Service vmcompute de novo e confirme que o Status mostra Running.

Se os serviços agora existem, mas aparecem como Stopped, configure-os para iniciar automaticamente e inicie-os:

Set-Service vmcompute -StartupType Automatic
Start-Service vmcompute
Get-Service vmcompute   # confirm Status = Running

Por fim, nada disso funciona se a virtualização de hardware estiver desativada. VT-x (Intel) ou AMD-V (AMD) precisa estar ativado na BIOS/UEFI: reinicie entrando nas configurações do firmware, ative a virtualização, salve e volte ao Windows antes de verificar os serviços novamente.

Se só o vfpext estiver ausente

Get-Service vfpext retornando "Cannot find any service" enquanto vmcompute e hns estão presentes é um caso que merece destaque. O VFPExt (Virtual Filtering Platform Extension) é o driver de filtragem de pacotes que o HNS carrega para rotear o tráfego de entrada e saída da VM do sandbox. Ele vem junto com o conjunto de recursos Hyper-V / Contêineres, então, se você ativou o Hyper-V mas pulou os Contêineres, pode acabar com o hns presente e o vfpext nunca carregado, e a VM do Cowork inicia sem rede funcional. Ative Contêineres em Ativar ou desativar recursos do Windows, reinicie e verifique de novo com Get-Service vfpext -ErrorAction SilentlyContinue. Se ainda não carregar em uma máquina que já tem esses recursos ativados, repare a pilha em um prompt elevado e reinicie:

DISM /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V-All /All

Aba do Cowork cinza ou sem resposta ao clique

Se a aba do Cowork está visível, mas cinza e não responde a cliques, sua conta é elegível: o app só não consegue chegar a uma VM local pronta. Esse é o caminho do HCS, não uma falha de interface: vmcompute ou hns está ausente ou parado, ou o CoworkVMService morreu depois de uma reinicialização ou suspensão. Execute as verificações com Get-Service vmcompute acima e depois inicie o serviço da VM com sc start CoworkVMService. Uma aba cinza quase nunca significa instalação quebrada: significa que a pilha de virtualização ainda não está no ar.

Tente isto primeiro: reinicie o CoworkVMService

Antes de qualquer outra coisa, verifique se o serviço em segundo plano do Cowork está realmente em execução. O CoworkVMService vem com tipo de inicialização Manual, o que significa que ele para depois de reinicializações, atualizações do Windows e ciclos de suspensão/retomada. Quando para, o Cowork trava ou não consegue se conectar, mesmo com todo o resto aparentemente normal. Esse é o problema mais comum do Cowork no Windows e o mais rápido de resolver.

Abra o PowerShell como Administrador e execute:

sc start CoworkVMService

Se isso resolver o Cowork até a próxima reinicialização, faça a mudança valer para sempre configurando o serviço para iniciar automaticamente (atenção ao espaço depois do =):

sc config CoworkVMService start= auto

Se o sc start retornar "service not found", pule para as seções sobre instalação abaixo: sua instalação do Cowork pode estar quebrada. Caso contrário, reinicie o Claude Desktop e verifique a aba do Cowork.

"Claude's Workspace Service Isn't Running"

Esse é o mesmo problema acima, só com outra redação em algumas versões da caixa de erro. O "workspace service do Claude" é o CoworkVMService.

Se você vir essa mensagem, abra o PowerShell como Administrador e execute:

Restart-Service CoworkVMService

Se o serviço parou depois de uma reinicialização, de suspensão/retomada ou de uma atualização do Windows, isso é esperado: o CoworkVMService vem com tipo de inicialização Manual, então não sobrevive a reinicializações por conta própria. Para torná-lo persistente:

Set-Service CoworkVMService -StartupType Automatic

Depois reinicie uma vez. O erro não deve voltar.

Verifique seu sistema antes de depurar

A Anthropic oferece um verificador de prontidão do Cowork para download, indicado no artigo "Get started with Claude Cowork" da central de ajuda da Anthropic (um utilitário separado, que não faz parte do Claude Desktop). Execute-o primeiro: ele informa se a sua máquina tem os componentes do Hyper-V de que o Cowork precisa. Ressalva: no Windows 11 Home, ele pode informar "pronto" por engano, porque o Windows 11 ainda se identifica internamente como 10.0 e o verificador identifica o sistema errado (GitHub #50621). Se o verificador diz que está pronto, mas o Cowork não carrega, execute Get-Service vmms no PowerShell: se esse serviço não existir, você está no Home, e as peças do Hyper-V que faltam são o provável motivo de o Cowork não iniciar.

As cinco maneiras de o Cowork quebrar no Windows

Os problemas não são aleatórios. Eles se dividem em cinco tipos distintos, e saber qual deles você está enfrentando já é metade do caminho.

1. A aba ausente (bug yukonSilver)

Você instala o Claude Desktop, abre e a aba do Cowork simplesmente não está lá. Só aparece "Chat". Esse é o bug "yukonSilver not supported", registrado nas issues #25136, #32004 e #32837 do GitHub. A detecção interna de plataforma do Claude marca incorretamente o seu sistema como incompatível, mesmo com todos os recursos de virtualização ativados.

2. O spinner de configuração infinito

A aba do Cowork aparece, mas, ao clicar nela, surge "Setting up Claude's workspace" (configurando o workspace do Claude) com uma barra de carregamento parada entre 80 e 90%. Ela nunca termina. Usuários relataram deixá-la rodando por mais de 12 horas sem nenhum progresso. Nenhuma mensagem de erro. Só girando.

3. A falha de conexão com a API

O workspace inicia, mas não consegue alcançar a API do Claude. Você recebe "Cannot connect to Claude API from workspace" (não é possível conectar à API do Claude a partir do workspace) ou o equivalente em japonês. Foi um bug do dia do lançamento no Windows 11 Home e voltou a aparecer várias vezes desde então.

4. O conflito de rede

O Cowork usa uma faixa de rede fixa no código (172.16.0.0/24) para o NAT interno. Se a sua rede doméstica, uma VPN corporativa ou outra ferramenta de VM usar a mesma faixa, a VM do Cowork não consegue acessar a internet. Pior: isso pode quebrar a rede do seu WSL2 e do Docker no processo.

5. A regressão de atualização

As atualizações automáticas já introduziram regressões que quebraram o Cowork mais de uma vez, dos dois lados. A atualização de segurança do Windows de 8 de setembro de 2026 quebrou o acesso do Cowork aos seus arquivos até a correção da Microsoft em 14 de setembro (detalhes acima). Do lado do Claude, o exemplo mais relatado foi a v1.1.5749, de 9 de março de 2026, que quebrou instalações que funcionavam e exigiu uma versão de correção para se recuperar. Desde então, a Anthropic lançou várias atualizações; se você está preso em uma versão ruim conhecida, atualizar para a versão atual do Claude Desktop costuma resolver.

A aba do Cowork sumiu ou desapareceu do app para desktop?

Três sintomas diferentes são relatados da mesma forma, e têm causas diferentes. Identifique primeiro o seu:

• A aba nunca apareceu. É um problema de primeira execução: versão, feature flag ou elegibilidade do plano. Siga as três verificações abaixo.
• A aba estava lá e desapareceu. Quase sempre é uma regressão de atualização ou uma mudança de plano. O Cowork é removido da interface quando o app atualiza para um build em que a detecção de plataforma falha, ou quando uma assinatura vence ou é rebaixada.
• A aba está visível, mas cinza ou sem resposta ao clique. O app vê sua conta como elegível, mas a pilha da VM local não está pronta. Esse é o caminho do HCS/CoworkVMService, não um bug de interface: vá para a solução dos serviços HCS acima.

"Não vejo o Cowork no meu app para desktop"

Pesquisando por por que o Claude Cowork não aparece ou Cowork não aparece? Se a aba nunca apareceu, é um problema de primeira execução (o build do seu Claude Desktop, uma feature flag ou a elegibilidade do plano), não um bug da pilha da VM. Siga as três verificações abaixo em ordem; se a aba continuar sem aparecer em uma máquina Pro ou Enterprise com todas elas satisfeitas, é o bug de detecção de plataforma yukonSilver tratado acima.

Se a aba do Cowork nunca aparece, e você já descartou o bug de detecção de plataforma yukonSilver acima, faça três verificações rápidas antes de uma depuração mais profunda:

1. Atualize o app. O Cowork só vem nos builds recentes do Claude Desktop. Abra Settings → About, instale qualquer atualização disponível e depois feche o app por completo e abra de novo (reiniciar em segundo plano não basta).
2. Confirme que o recurso está ativado. Verifique Settings → Features (Beta/Labs em alguns builds) e confirme que o Cowork está ativado para a sua conta.
3. Verifique a elegibilidade do plano. O Cowork é restrito a planos pagos. Se você está no plano gratuito, a aba não aparece, independentemente da versão: faça upgrade para um plano elegível e depois reabra o app.

A aba desapareceu depois de funcionar bem

Se o Cowork funcionava e depois sumiu, verifique nesta ordem:

1. O app atualizou recentemente? Abra Settings → About e anote o build. A regressão da v1.1.5749, documentada abaixo, removeu a aba de máquinas que vinham rodando o Cowork sem problemas. Voltar ao build anterior a restaura.
2. Seu plano mudou? Um cartão vencido, um downgrade ou um assento removido de um workspace Team revogam o acesso ao Cowork imediatamente, e a aba desaparece sem nenhuma mensagem explicativa.
3. Você trocou de conta? A elegibilidade ao Cowork é por conta, não por instalação. Entrar com uma conta gratuita na mesma máquina esconde a aba até você voltar para a outra.
4. O Windows atualizou? Uma atualização de recursos pode redefinir os Recursos do Windows, desativando em silêncio a Plataforma de Máquina Virtual ou o Hyper-V. Verifique de novo com Get-Service vmcompute antes de supor que o problema é do app.

Se tudo isso estiver certo e a aba continuar ausente, revise as seções sobre yukonSilver e Windows Home acima.

A zona cinzenta do Windows Home

É aqui que a coisa fica confusa.

O Claude Cowork roda dentro de uma máquina virtual leve na sua máquina Windows. É assim que ele cria o ambiente isolado para acesso a arquivos e execução de código. O documento "Deploy Claude Desktop for Windows" da Anthropic diz que o Claude Desktop "requires the Virtual Machine Platform to use Cowork" (exige a Plataforma de Máquina Virtual para usar o Cowork), e o Windows 11 Home tem a Plataforma de Máquina Virtual. O documento não cita nenhuma exigência de edição do Windows, nem a favor nem contra. Se o Cowork está pedindo que você ative a Plataforma de Máquina Virtual, nossa correção da Plataforma de Máquina Virtual mostra como ativá-la, a verificação da BIOS e os passos específicos do Home.

O problema? A edição Home tem a Plataforma de Máquina Virtual e a Plataforma do Hipervisor do Windows, mas não o Hyper-V completo: não há o serviço vmms (Hyper-V Virtual Machine Management) nem a pilha completa de HCS/Contêineres. Quando o Cowork falha no Home, essas peças ausentes são o que os usuários apontam. A VM falha em silêncio ou exibe um erro enigmático "Plan9 mount failed: bad address" (falha na montagem Plan9: endereço inválido).

Muitos usuários do Windows Home abriram issues no GitHub (#27906, #31991 e #45883, entre outras) depois de passar horas investigando falhas do Cowork no Home. Um usuário observou explicitamente que "subscribed to Max specifically to use this feature" (assinou o Max especificamente para usar este recurso) e só encontrou o problema depois de pagar.

Um pedido de documentação (issue #27906 do GitHub) pedia que a Anthropic declarasse com clareza que o Home não é suportado. Essa issue está fechada, mas não há nenhuma declaração visível da Anthropic confirmando que o Home não é suportado, nem outra dizendo que é.

A verificação mais rápida é abrir o PowerShell e executar Get-Service vmms. Se o serviço não for encontrado e o Cowork não iniciar, suas opções para o app de desktop se resumem a fazer upgrade para o Windows 11 Pro. Não confie apenas no verificador de prontidão da Anthropic: o GitHub #50621 documenta que ele informa "pronto" por engano no Windows 11 Home, porque o Windows 11 ainda se identifica internamente com a versão 10.0 e o verificador classifica o sistema errado.

Não consegue ativar a Plataforma de Máquina Virtual, ou não quer fazer upgrade? Use o Cowork na web para pular o Hyper-V por completo. Desde 7 de julho de 2026, o Cowork roda em claude.ai no navegador (e no iOS, no Android e no painel lateral do Chrome) como uma sessão na nuvem, na infraestrutura da Anthropic. Nada roda no seu PC, então a edição do Windows, o Hyper-V e o CoworkVMService deixam de importar. A contrapartida: as sessões na nuvem só leem e gravam arquivos em pastas do seu computador enquanto o app de desktop estiver aberto, então o trabalho com arquivos locais ainda precisa do app de desktop. Para todo o resto, o navegador é a correção mais rápida no Windows Home.

O bug yukonSilver not supported e por que sua máquina Pro ainda falha

Fique comigo, porque este é especialmente frustrante.

Mesmo que você use o Windows 11 Pro com todos os recursos de virtualização ativados (Hyper-V, VMP, WHP, WSL2), a aba do Cowork ainda pode sumir por completo. Os logs mostram "yukonSilver not supported (status=unsupported)" seguido da rotina de limpeza do pacote da VM rodando no lugar do boot real da VM.

"yukonSilver" é o codinome interno do Claude para a configuração de VM no Windows. O bug está na lógica de detecção de plataforma: ela classifica incorretamente sistemas Windows 11 Pro x64 totalmente compatíveis como não suportados.

Mas esse nem é o problema real. O instalador também cria um serviço do Windows chamado CoworkVMService, e esse serviço às vezes se torna impossível de remover. Executar sc.exe delete CoworkVMService como Administrador retorna "Access denied" (acesso negado). O serviço bloqueia reinstalações limpas e cria uma falha circular em que você não consegue consertar o problema nem recomeçar do zero.

A solução alternativa documentada pela depuração da comunidade: executar manualmente Add-AppxPackage como o usuário de destino para instalar corretamente o pacote MSIX na sua conta. É um comando do PowerShell que a maior parte do público-alvo do Cowork (pessoas que não são desenvolvedoras) jamais descobriria sozinha.

Squirrel vs. MSIX: qual instalador você tem?

A Anthropic trocou o instalador .exe Squirrel do Claude Desktop no Windows por um pacote MSIX/Microsoft Store por volta de 10 a 13 de fevereiro de 2026. Se você instalou o Claude Desktop antes disso, tem a versão Squirrel, e o botão "Reinstall" dentro do app pode falhar em silêncio (registrado nas issues #25162, #25385 e #26457 do GitHub; código de erro 0x80073CFA em alguns logs). A solução é desinstalar manualmente por "Adicionar ou remover programas" e depois baixar o MSIX novo na página oficial de download do Claude. Observe que as instalações MSIX também exigem que "Sideload apps" / "Trusted App Installs" do Windows esteja ativado: sem isso, a instalação do MSIX falha antes de começar.

Como disse um desenvolvedor que depurou o problema: "Cowork is marketed at the people least equipped to debug it when it breaks." (O Cowork é vendido justamente para quem tem menos condições de depurá-lo quando quebra.)

Se você tem enfrentado dores de cabeça de infraestrutura parecidas com agentes de IA e quer algo que funcione de cara, nossa comparação entre implantações auto-hospedadas e gerenciadas do OpenClaw mostra por que algumas equipes estão abandonando de vez as configurações locais. E se os erros que você persegue têm a ver com uso e não com instalação, veja o que fazer quando aparece o aviso de rate limit reached no Claude Cowork.

O bug de rede que quebra o Docker também

Aqui vai o que ninguém conta sobre a rede do Cowork no Windows.

O Cowork cria o seu próprio switch virtual e a sua própria rede NAT no Hyper-V. Ela é separada da rede do WSL2 e separada da rede do Docker Desktop. Três inquilinos diferentes dividindo o mesmo hipervisor, cada um com a sua própria tubulação.

A falha específica: o Cowork cria uma rede HNS (Host Network Service) chamada "cowork-vm-nat", mas às vezes não cria a regra WinNAT correspondente. A rede HNS existe, mas não há tradução de NAT. A VM inicia, mas fica sem acesso à internet.

E, em um bug particularmente divertido, a rede virtual do Cowork já foi relatada como causa de quebra permanente da conectividade de internet do WSL2 até você encontrar e apagar manualmente a configuração de rede problemática usando as ferramentas de diagnóstico HNS do PowerShell.

A correção, descoberta por membros da comunidade, consiste em encerrar todos os processos do Claude, matar a VM do Cowork via hcsdiag, remover a rede HNS quebrada e recriá-la em uma sub-rede sem conflito, como 172.24.0.0/24 ou 10.200.0.0/24.

São três comandos do PowerShell para quem sabe o que está fazendo. Para quem só queria organizar a pasta Downloads com IA, é um muro.

O que realmente corrige cada bug (referência rápida)

Aba do Cowork ausente (bug yukonSilver)

Primeiro, verifique se você está no Windows Home (Get-Service vmms não retorna nada), já que as peças do Hyper-V ausentes no Home são uma causa comum de falhas do Cowork. Se você está no Pro ou no Enterprise e ainda não vê a aba, desinstale o Claude Desktop por completo, remova o serviço remanescente e limpe os arquivos residuais antes de reinstalar:

sc.exe stop CoworkVMService
sc.exe delete CoworkVMService
Remove-Item -Recurse "$env:APPDATA\Claude"
Remove-Item -Recurse "$env:LOCALAPPDATA\Packages\Claude_*"

Depois reinstale do zero a partir da página oficial de download do Claude.

Spinner de configuração infinito

Há duas causas comuns aqui. Primeiro, o próprio download da VM. Olhe em %APPDATA%\Claude\vm_bundles\: se o diretório estiver vazio ou incompleto, o download foi interrompido e uma reinstalação limpa geralmente resolve.

Segundo, o bug do caminho de armazenamento entre drives (GitHub #36642, #30584, #37754). O Cowork grava o rootfs.vhdx em C:\Windows\Temp primeiro e depois tenta renomeá-lo para o local final. Se a opção "Onde o novo conteúdo é salvo" do Windows envia os dados do usuário para um drive que não é o C:, essa renomeação atravessa dispositivos e o Node.js lança EXDEV: cross-device link not permitted. Sintoma: o spinner trava para sempre, sem nenhum erro visível. Correção: abra Configurações → Sistema → Armazenamento → Configurações avançadas de armazenamento → Onde o novo conteúdo é salvo, volte "Novos aplicativos" para o drive C: e tente de novo.

Se o spinner persistir no Windows Home e Get-Service vmms não encontrar nada, as peças do Hyper-V ausentes no Home são a causa provável. Para o app de desktop, isso normalmente significa fazer upgrade para o Pro, mas o Cowork na web em claude.ai dispensa a VM local por completo em qualquer tarefa que não precise de arquivos locais.

Falha de conexão com a API

Desative a VPN temporariamente (feche por completo, não apenas desconecte). Verifique se a sua rede usa a faixa 172.16.0.0/24. Se o Chat funciona e o Cowork não, o problema é a pilha de rede da VM, não a sua internet. Atualize para o Claude Desktop mais recente: a v1.1.4328 ou superior tratou especificamente os primeiros bugs de conexão com a API.

Conflito de rede

Verifique se a rede HNS do Cowork existe, mas a regra de NAT não:

Get-NetNat
Get-HnsNetwork | Where-Object {$_.Name -eq "cowork-vm-nat"}

Se o Get-NetNat estiver vazio, mas a consulta HNS retornar um resultado, você está no estado de "regra de NAT ausente". Remova a rede quebrada e recrie-a em uma sub-rede sem conflito, como 172.24.0.0/24 ou 10.200.0.0/24.

Regressão de atualização (v1.1.5749)

Se o Cowork quebrou depois da atualização de 9 de março, não há correção do lado do usuário. Atualize para a versão mais recente do Claude Desktop: a Anthropic lançou várias correções desde então.

Se tudo isso soa como muita depuração de infraestrutura para uma ferramenta que deveria "simplesmente funcionar", é porque é mesmo. Esse é o tipo de atrito operacional que criamos o BetterClaw para eliminar. Seu agente roda em infraestrutura gerenciada: sem VMs locais, sem Hyper-V, sem conflitos de NAT. Pro a $49/month para 5 agentes, BYOK, primeiro deploy em cerca de 60 segundos.

Cowork vs. um agente gerenciado: escolha o que combina com o seu trabalho

O app de desktop do Cowork roda uma VM Hyper-V local, e é por isso que toda peculiaridade de edição do Windows, conflito de rede e regressão de atualização vira um possível ponto de falha. Desde 7 de julho de 2026, essa VM só entra no caminho do trabalho local: o Cowork agora roda no desktop, na web (claude.ai), no iOS, no Android e no Chrome. As sessões na nuvem continuam quando o notebook está fechado. As sessões no desktop ainda precisam do app aberto para acessar arquivos locais. Se você precisa de um copiloto para os seus próprios arquivos, essa contrapartida faz sentido.

Se você precisa de um agente que viva em plataformas de mensagens, seja compartilhado por uma equipe e rode no modelo que você escolher, a arquitetura tem que ser diferente. Nossa comparação entre OpenClaw e Claude Cowork detalha exatamente quando o Cowork faz sentido e quando você precisa de um agente baseado em servidor. O BetterClaw, uma plataforma de agentes de IA sem código, executa seu agente em infraestrutura na nuvem, com Telegram, Discord e Slack integrados. Sem VM local, sem Hyper-V, sem PowerShell numa terça à noite. O Pro custa $49/month para 5 agentes, BYOK, primeiro deploy em cerca de 60 segundos. Comece com o BetterClaw.

Perguntas frequentes

Por que o Claude Cowork não funciona na minha máquina Windows?

Principais causas: o CoworkVMService parou depois de reinicialização ou suspensão, a edição Windows Home sem a pilha completa do Hyper-V (muitos usuários do Home relatam falhas), o bug de detecção de plataforma "yukonSilver", conflitos de rede com VPNs ou Docker em 172.16.0.0/24, ou uma instalação corrompida do antigo pacote Squirrel. Verifique a sua edição do Windows, depois o estado do serviço da VM e, por fim, as issues do GitHub do Claude Code para o seu erro exato.

Como corrijo "missing HCS services: hns, vmcompute, vfpext" no Claude Cowork?

Esses são os componentes do Windows Host Compute Service de que a VM do sandbox do Cowork precisa. Abra Ativar ou desativar recursos do Windows, ative Hyper-V, Plataforma do Hipervisor do Windows e Contêineres, e reinicie para que os serviços sejam registrados. Confirme com Get-Service vmcompute e Get-Service hns em um PowerShell elevado. Se eles existirem, mas aparecerem como Stopped, execute Set-Service vmcompute -StartupType Automatic; Start-Service vmcompute. Se só o vfpext estiver ausente, o recurso a ativar é Contêineres.

Como reinicio o CoworkVMService no Windows?

Abra o PowerShell como Administrador e execute sc start CoworkVMService para iniciá-lo na sessão atual. Para que ele sobreviva a reinicializações, execute sc config CoworkVMService start= auto (atenção ao espaço depois do =). O serviço vem com tipo de inicialização Manual, então para depois de reinicializações, atualizações do Windows e ciclos de suspensão/retomada. Essa é a correção mais comum do Cowork no Windows.

O Claude Cowork funciona no Windows 11 Home?

É uma zona cinzenta. O requisito documentado pela Anthropic é a Plataforma de Máquina Virtual, que o Windows 11 Home tem, e ela não cita nenhuma exigência de edição. Na prática, muitos usuários do Home relatam falhas no Cowork porque o Home não tem o Hyper-V completo (vmms) e partes da pilha HCS. O verificador de prontidão da Anthropic pode informar o Home como "pronto" por engano (ele identifica o sistema errado), então não confie só nele: execute Get-Service vmms no PowerShell. Se ele não existir e o Cowork não iniciar, faça upgrade para o Windows 11 Pro para usar o app de desktop, ou use o Cowork na web em claude.ai, que roda na nuvem e dispensa a VM local por completo (o acesso a arquivos locais ainda exige o app de desktop).

Como corrijo o erro "yukonSilver not supported" no Claude Cowork?

É um bug de detecção de plataforma do lado do Claude, ainda aberto em maio de 2026. A solução alternativa: desinstale o Claude Desktop por completo, pare e apague o CoworkVMService pelo PowerShell elevado, limpe %APPDATA%\Claude e a pasta %LOCALAPPDATA%\Packages\Claude_* e reinstale do zero a partir do download oficial.

O Claude Cowork no Windows é estável o bastante para uso diário em 2026?

O Cowork chegou à disponibilidade geral em abril de 2026, mas o Windows ainda é a plataforma mais irregular. O bug yukonSilver continua aberto, o comportamento de inicialização Manual do CoworkVMService pega os usuários a cada reinicialização, e regressões de atualização aparecem periodicamente. Serve para trabalho com arquivos locais se o seu sistema for compatível, e, para tarefas que não tocam em arquivos locais, o Cowork na web evita a pilha do Windows por completo. Para cargas de trabalho em que ficar fora do ar significa perder trabalho, um agente gerenciado é mais confiável.