O GitHub Copilot deixou de operar apenas onde existe código, terminal ou integração estruturada. Em 1º de outubro, o GitHub colocou em public preview um recurso de computer use no Copilot CLI e no aplicativo do Copilot para macOS e Windows. Quando habilitado, o agente pode ler o conteúdo visível, clicar, digitar, rolar, arrastar e atravessar etapas entre diferentes aplicativos.

A mudança abre uma porta importante para processos presos a sistemas legados ou interfaces gráficas que não oferecem API, linha de comando ou servidor MCP. Um fluxo de despesas, por exemplo, pode exigir copiar informações de um navegador, preencher campos em um programa antigo e atualizar uma apresentação. O Copilot passa a executar essas interações pela interface, como faria uma pessoa diante da tela.

Isso amplia o alcance da automação. Não torna a interface uma API confiável.

A última milha dos sistemas sem integração

O próprio GitHub recomenda preferir APIs, MCPs, comandos de terminal, ferramentas de arquivos ou automação dedicada quando essas opções existem. A razão é simples: controles estruturados entregam dados mais previsíveis. Uma interface visual pode mudar de posição, abrir uma janela inesperada ou responder em outro ritmo.

Na documentação oficial sobre computer use, o GitHub reconhece que o agente pode selecionar o controle errado, inserir texto no lugar incorreto, repetir uma ação ou não conseguir continuar. Versões diferentes do aplicativo, estado das janelas e tempo de carregamento também podem alterar o resultado.

Computer use cobre a última milha de um processo. Ele não elimina a fragilidade de automatizar uma tela que pode mudar.

Na prática, o recurso pode ser útil quando integrar o sistema corretamente seria impossível ou desproporcional. Para processos frequentes, críticos ou de grande volume, porém, a automação visual deve ser tratada como uma escolha arquitetural com custo de manutenção, não como substituto universal para integração.

Aprovação ajuda, mas o escopo importa mais

O computer use vem desabilitado por padrão. O usuário precisa ativá-lo com /computer on no CLI ou nas configurações do aplicativo. O Copilot pode pedir autorização antes de controlar um programa, e administradores de organizações podem bloquear o recurso por política. No macOS, ele também depende das permissões de Acessibilidade e Gravação de Tela.

Há três decisões práticas antes de liberar o acesso:

  • quais aplicativos o agente pode controlar;
  • quais dados podem aparecer nas janelas observadas;
  • quais ações precisam de confirmação humana imediatamente antes da execução.

O usuário pode salvar uma aprovação com “Always allow”, compartilhada localmente entre CLI e aplicativo naquele computador. Isso reduz interrupções, mas também permite novas ações sem uma pergunta adicional. O GitHub orienta evitar essa opção em programas com informações sensíveis ou ações de alto impacto.

Uma tela de folha de pagamento, um sistema financeiro ou uma ferramenta que envia mensagens não deve receber o mesmo tratamento de um editor de apresentação. A permissão técnica pode ser idêntica. O risco de uma ação errada, não.

O controle humano não começa no botão de aprovação. Começa na escolha dos aplicativos, dos dados visíveis e das consequências permitidas.

O teste certo é pequeno e reversível

O GitHub sugere descrever o resultado esperado, os aplicativos envolvidos e as restrições relevantes. Para uma adoção responsável, eu acrescentaria um ambiente de teste, dados não sensíveis e uma tarefa cuja reversão seja simples. Também vale observar se o agente reconhece estados inesperados em vez de insistir no próximo clique.

O recurso aproxima o Copilot de uma automação de trabalho mais ampla, inclusive fora do desenvolvimento. A oportunidade é real para empresas que ainda dependem de software sem integração moderna. O limite também é real: quanto maior a autoridade sobre a tela, maior precisa ser a disciplina sobre permissões, supervisão e recuperação de erros.

Fontes: anúncio do GitHub sobre computer use e documentação de capacidades, permissões e riscos.