Como agendar o agente do VS Code para rodar uma tarefa toda semana

Toda segunda-feira tem aquela tarefa chata que volta igualzinha: olhar o que mudou no repo, varrer issues novas, checar se algo quebrou no fim de semana

O VS Code 1.137 trouxe as automations em preview público, e elas agendam tarefas do agente por hora, por dia, por semana ou sob demanda. A versão chegou em 9 de setembro de 2026, com rollout gradual, e o changelog semanal do GitHub Copilot também descreve o recurso como public preview

Agora o aviso que precisa vir na primeira linha, não no rodapé: é preview, pode mudar antes de virar disponibilidade geral, e a própria documentação manda revisar a resposta e as alterações antes de confiar no output. Ou seja: o agente roda sozinho, mas o diff continua passando pelo seu olho 🙂

O que você precisa antes de criar a automation

Antes de sair clicando, confere essa lista curta:

• VS Code 1.137. Lançado em 9 de setembro de 2026, com rollout gradual. Se ainda não apareceu pra você, dá pra forçar via Check for Updates
• Acesso à assinatura do GitHub Copilot. A Agents window está em preview e precisa desse acesso pra rodar sessões de agente
• A configuração chat.automations.enabled ligada. Aqui tem uma pegadinha: ela vem desligada por padrão no Stable e ligada por padrão no Insiders
• Máquina ligada na hora agendada. Schedules apoiados no Agent Host exigem um processo do Agent Host rodando; os demais exigem uma janela do VS Code aberta. E automations locais não continuam depois que você fecha o app

Esse último item é o que mais frustra quem vem de cron de servidor. Não é um robô na nuvem esperando a hora, beleza? Se o notebook dormiu, a execução não acontece

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Passo a passo: criar uma automation semanal do agente

A ordem aqui importa, porque o painel de Automations simplesmente não aparece se a configuração estiver desligada

1. Habilite chat.automations.enabled no Settings editor. O erro comum deste passo é o clássico: abrir a sidebar, não achar Automations e concluir que a versão não tem o recurso. Antes de qualquer coisa, checa se a configuração está ligada
2. Abra a Agents window. Tem várias portas de entrada: o botão Open in Agents na title bar, o comando Chat: Open Agents window na Command Palette (Ctrl+Shift+P no Windows e Linux, Shift+Cmd+P no macOS), o link na welcome page, ou o terminal mesmo:

code --agents

3. Selecione Automations na sidebar da Agents window. É aqui que os cards de automation vivem
4. Escolha Create Automation ou um card em Start with a template. Existem templates pra acompanhar mudanças recentes, triagem de issues e caça a bugs, e eles já preenchem prompt e schedule iniciais. O erro comum: salvar o template do jeito que veio. A documentação é explícita em revisar e adaptar o prompt antes de salvar
5. Preencha Name descritivo e Prompt. No prompt, diga a tarefa, o escopo e o output esperado. Nome genérico tipo "automation 2" volta pra te assombrar no History
6. Escolha o agente e revise a Session configuration, incluindo modelo e opções de permissão. Presta atenção nessa parte: uma automation pode ler arquivos, rodar comandos e fazer alterações conforme as permissões do agente. Revisar o nível de permissão ANTES de agendar trabalho sem supervisão não é firula
7. Escolha o workspace onde o agente deve trabalhar, ou marque No workspace se a tarefa não precisa dos arquivos do projeto
8. Deixe o Schedule como Manual e selecione Create. A recomendação oficial é essa: testar em manual antes de tornar recorrente. O erro comum aqui é salvar direto como weekly e descobrir que o prompt estava ruim… uma semana depois
9. Selecione Run now no card da automation e confira a execução em History. Clicando numa run, ela abre a sessão correspondente, com resposta e alterações
10. Volte, escolha o Schedule semanal, mantenha Enabled marcado e selecione Save. Só agora ela virou recorrente

Um detalhe que evita confusão de fuso: schedules daily e weekly usam o fuso horário local do usuário

Como escrever o prompt de uma execução que roda sem você por perto

Prompt de chat e prompt de automation não são a mesma coisa. No chat você corrige no meio do caminho; na automation, o que estiver escrito é tudo que o agente vai ter

A orientação oficial de boas práticas do VS Code se aplica direto aqui:

1. Seja específico sobre inputs, outputs, APIs ou frameworks. Não deixe o agente adivinhar formato de saída
2. Referencie arquivos existentes e indique o padrão a seguir. É o jeito mais barato de dizer "faça parecido com isso"
3. Defina o escopo. Diga o que está dentro e, principalmente, o que está fora
4. Inclua casos de teste no prompt pra a IA verificar o próprio trabalho
5. Descreva explicitamente como o agente deve verificar o que fez. A doc de automations pede isso com todas as letras: o prompt deve descrever o objetivo e como o agente verifica seu trabalho

Prompt ruim (e esse é o tipo de pedido que estraga uma execução sem supervisão):

Melhore o projeto e corrija o que estiver errado

Prompt com escopo e critério de verificação:

Objetivo: listar as mudanças mergeadas no repositório desde a última execução

Escopo:
- olhe apenas o histórico de commits e os arquivos em src/
- não altere código, não crie arquivos fora de reports/

Output esperado:
- um resumo em markdown em reports/semana.md com: arquivo alterado, tipo de mudança e impacto provável
- máximo de 15 itens, agrupados por módulo

Como verificar antes de terminar:
- confirme que reports/semana.md existe e não está vazio
- confirme que todo arquivo citado no resumo realmente aparece no histórico
- se algum item não puder ser confirmado, marque como "não verificado" em vez de afirmar

Repara no que o segundo prompt faz: ele fecha o escopo, define onde escrever e dá ao agente uma forma de dizer "não sei" em vez de inventar. Esse padrão de pedido fechado é o mesmo que vale pra qualquer agente rodando tarefas sozinho, não só aqui

Quais tarefas valem a pena agendar (e quais não)

O filtro mais honesto vem da regra de permissões: se a automation pode alterar arquivos, o escopo precisa ser estreito. Tarefa de escopo aberto sem ninguém olhando é pedido de retrabalho

Os próprios templates oficiais dão a pista do que o recurso foi pensado pra fazer: acompanhar mudanças recentes, triagem de issues e caça a bugs. Repara que os três têm output verificável

Regra de bolso: se você não consegue escrever em uma frase como saberia que a tarefa deu certo, ela não está pronta pra rodar sozinha

E não confunda automation com paralelismo. Automation é "roda nessa hora"; quando o objetivo é dividir trabalho entre vários agentes no mesmo projeto, o problema é outro

Onde conferir o que o agente fez na execução agendada

Toda execução aparece em History. Selecionando uma run, abre a sessão correspondente, com o que o agente respondeu e o que ele mexeu

E aqui é a parte que não é opcional: a orientação oficial é revisar a resposta e quaisquer alterações antes de confiar no output da tarefa. Preview público não é piloto automático

O gerenciamento do dia a dia é bem direto:

• Editar: selecione o nome da automation, atualize prompt, target, session configuration ou schedule e clique em Save
• Desabilitar execuções futuras: edite, desmarque Enabled e Save. Tome cuidado: isso NÃO interrompe uma run que já está rodando
• Parar uma run ativa: use Stop na sessão em execução dentro do History
• Deletar: selecione Delete no card e confirme

Essa diferença entre desabilitar e parar é o tipo de detalhe que a gente descobre no pior momento possível, então já sabe: se a run está em andamento e você quer que ela pare agora, é Stop

O que mais veio no ciclo do VS Code 1.137

As automations não vieram sozinhas. O anúncio semanal do GitHub Copilot traz o pacote, e vale conferir a nota oficial

• Voice Mode (experimental): falar com o agente e interromper ou redirecionar enquanto ele trabalha no seu código
• Issues e pull requests do GitHub na Agents window (experimental): revisar detalhes ali mesmo
• Arquitetura Agent Host: um protocolo aberto que desacopla as sessões do workspace

Esse último item parece detalhe de bastidor, mas é exatamente o que explica a diferença de exigência entre os tipos de schedule: os apoiados no Agent Host precisam de um processo do Agent Host rodando, enquanto os demais precisam de uma janela do VS Code aberta

Conclusão

Dá pra agendar tarefa recorrente do agente no VS Code 1.137, e isso resolve bem aquele ritual de segunda-feira. O que não dá é tratar como serviço maduro: automations está em preview público e pode mudar antes do GA, a execução depende da sua máquina estar acordada com o processo certo rodando, e a revisão do que o agente alterou continua sendo trabalho humano

Próximo passo concreto, na ordem: liga chat.automations.enabled, cria uma automation em Schedule: Manual com uma tarefa pequena e de escopo fechado, dispara com Run now, lê a run inteira no History e só então promove pra weekly

Se o resultado da primeira run já te deu vontade de corrigir o prompt, ótimo: é pra isso que existe o modo manual 😀

até o próximo post!