Deixe o OpenCode corrigir o erro enquanto você mantém sua árvore de trabalho

Você está no meio de uma alteração quando alguém relata uma falha no interpretador de datas. Quer continuar editando seus arquivos e dar uma tarefa separada ao agente de programação. Assim que os dois começam a editar o mesmo diretório, até uma correção pequena fica difícil de separar do que já estava em andamento.

Em 6 de novembro, o OpenCode 2.2.6 acrescentou uma opção de árvore de trabalho às execuções por script na linha de comando. O OpenCode é um agente de programação de código aberto, com interface de terminal interativa e um comando separado para enviar um prompt por script. Com a opção nova, o script pode iniciar o OpenCode em uma árvore de trabalho Git separada, atribuir um nome se quiser e deixar o diretório original livre. A mesma versão acrescentou compartilhamento opcional para conexões compatíveis do Model Context Protocol (MCP). A combinação traz duas perguntas antes de começar. Quais arquivos o agente pode mudar? Quais serviços pode usar? Versão OpenCode v2.2.6 · Documentação da CLI do OpenCode

A configuração mais útil combina uma tarefa bem delimitada, um ponto de partida previsível, um lugar para inspecionar as mudanças e permissões explícitas para tudo que sai do projeto.

A captura do terminal do projeto OpenCode mostra um patch e uma sessão na interface. O material oficial da marca na versão ilustra o terminal. A imagem acompanha um aviso de licença MIT. O Telli.sh redimensionou a captura e acrescentou margens.

Um diretório separado oferece um diff confiável

Uma árvore de trabalho Git dá a cada tarefa seus próprios arquivos e índice. Ilustração original do Telli.sh.

As árvores de trabalho ligam mais de um diretório a um repositório Git. Cada árvore vinculada tem arquivos, índice e revisão em uso próprios. A maior parte dos dados do repositório é compartilhada. Assim, você pode examinar o patch do agente separadamente enquanto suas edições originais ficam onde estavam. Isso também muda o código que o agente vê. Alterações sem commit no primeiro diretório não aparecem no segundo só porque ambos pertencem ao mesmo repositório. Documentação de git worktree

A versão de 6 de novembro documenta três formas de escolher o comportamento. Use opencode run -w ou opencode run --worktree para uma árvore nova e --worktree=<name> para atribuir um nome. A versão também diz que a opção não pode ser combinada com --continue ou --session. Uma execução limpa precisa de um contexto novo. Se o relatório de erro já tem uma conversa longa, leve os passos relevantes de reprodução e o resultado esperado ao prompt novo. Versão OpenCode v2.2.6 · Implementação e exemplos de worktree

Pense no diretório separado como o lugar da revisão. Antes de começar, anote o branch e o commit que o agente deve usar. Depois, confira o commit e o estado da árvore criada. Se um teste depende de um arquivo não rastreado ou de uma mudança que só existe no editor, a diferença na base explica uma aparente contradição entre as execuções. Um patch pode estar correto na versão mais antiga e ser inadequado para o branch que você vai publicar.

Teste uma alteração pequena antes de delegar uma maior

Comece com um repositório seu e uma tarefa objetiva. Um teste de ano bissexto que falha é um experimento inicial melhor que uma atualização ampla, porque o resultado esperado é fácil de verificar. Corrigir um link antigo e conferir uma rota também é uma tarefa bem delimitada. Em ambos os casos, descreva explicitamente o comportamento que deve mudar e como vai verificá-lo.

1. Registre o estado inicial. No diretório atual, use git status --short e git rev-parse HEAD. Guarde a saída com o relatório de erro. Se já existe uma execução de referência bem-sucedida, registre como reproduzi-la. Use opencode --version para confirmar que a versão tem a opção nova. Versão OpenCode v2.2.6

2. Dê ao agente uma tarefa em uma árvore com nome. Inclua a reprodução e o teste desejado no prompt. O exemplo usa um interpretador de datas fictício e supõe que já exista um teste específico. Pedir para deixar mudanças sem commit facilita a revisão. Imponha limites mais fortes pelas permissões e pelo ambiente de execução.

   ShellExecutar no Terminal

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. Encontre o diretório novo antes de revisar. Rode git worktree list no repositório original e use o caminho informado. No diretório novo, confira git status --short, git diff e git diff --cached. O último comando importa se o agente preparou algo para commit. Examine arquivos não rastreados separadamente. Repita os testes no diretório do agente e confira se cobrem 29 de fevereiro em ano bissexto e em ano em que a data é inválida. Documentação de git worktree

4. Traga só o trabalho revisado. Mantenha a proposta separada até poder aplicar o commit ou patch revisado ao branch certo. Confira de novo o estado do diretório original. Preserve a árvore do agente até registrar o que precisa e verificar se não há alterações pendentes que queira guardar. A lista de árvores do Git facilita identificar a tarefa de cada diretório. Documentação de git worktree

O mesmo padrão ajuda quando surgem dois problemas sem relação. Dê a cada um um escopo pequeno e compare os dois diffs antes de integrar. A separação evita que uma alteração não preparada do teste de um agente apareça no outro diretório. As correções ainda podem entrar em conflito ao chegar ao mesmo branch, especialmente se ambas mexerem em uma função compartilhada. A integração e a regressão final continuam no fluxo normal de revisão.

Decida quem pode fazer o quê fora do repositório

Duas árvores de trabalho podem rodar na mesma conta do sistema. Podem ter acesso ao mesmo ambiente, aos mesmos gerenciadores de credenciais e à mesma rede. A opção de árvore define onde a execução começa e separa as alterações de trabalho de rotina. Use limites próprios de ambiente ou conta quando a tarefa exigir mais isolamento. Uma solicitação de permissão controla as ferramentas que a respeitam. O sistema operacional ou ambiente de execução determina o que o processo de fato alcança.

Separe o local das mudanças das aprovações de ferramentas e do acesso em execução. Ilustração original do Telli.sh.

A documentação de permissões da V2 descreve regras ordenadas para ações individuais. Os efeitos incluem allow, ask e deny, e vale a última regra que corresponde à ação. Um exemplo oficial pede confirmação para comandos de shell e depois permite comandos comuns de inspeção e nega envios ao remoto. Se pretende rodar sem alguém para aprovar, teste o comportamento de ask nesse fluxo antes de colocá-lo em uma tarefa recorrente. Defina proibições claras na configuração e use credenciais temporárias e restritas aos serviços de que o trabalho precisa. Documentação de permissões do OpenCode

Uma tarefa só de documentação permite testar essas camadas de maneira simples. Deixe o agente alterar uma seção em um projeto de exemplo. Dê a ele um provedor autorizado e dispense credenciais de produção. Rode o script e confira se o patch toca apenas o arquivo esperado. Se a automação futura precisar de um remoto ou de um sistema de chamados, justifique cada capacidade e verifique suas permissões separadamente.

Compartilhar a conexão faz sentido quando os projetos já têm os mesmos limites

O MCP permite ao agente usar ferramentas de outros programas, como uma busca de documentação ou um sistema de chamados. Na versão de 6 de novembro, pool: true permite que diretórios atendidos pelo mesmo servidor OpenCode reutilizem uma conexão quando as configurações relevantes coincidem. A documentação oficial da V2 especifica que o compartilhamento vale para a revisão de protocolo 2026-07-28. Se o servidor negociar uma revisão anterior, mantém as conexões separadas. Também é preciso mais do que apontar dois projetos para o mesmo endereço. Configurações remotas e contas autenticadas devem coincidir. Em servidor local, a correspondência inclui comando, ambiente e diretório de trabalho. Versão OpenCode v2.2.6 · Documentação de compartilhamento MCP do OpenCode

Imagine duas árvores que consultam a mesma documentação interna com a mesma conta. Compartilhar pode evitar configurações de conexão duplicadas se o serviço aceitar a revisão relevante. Primeiro, confira se os diretórios devem ter acesso ao mesmo material e se a integração oferece só as capacidades necessárias. Se uma árvore precisa apenas de documentação pública e a outra abre chamados internos, conexões distintas tornam os limites mais claros.

Um servidor local pode depender do diretório atual. Um processo iniciado em cada pasta pode ter contexto local diferente, mesmo com o mesmo comando. A documentação diz que compartilhar conexões locais entre projetos exige um diretório de trabalho fixo e que uma conexão compartilhada não tem raízes. É por isso que vale começar por um serviço somente de leitura que deixe claro seu escopo. Se a ferramenta muda conforme o repositório que a chama, meça essa diferença antes de adotar uma conexão compartilhada. Documentação de compartilhamento MCP do OpenCode

Execuções por script também precisam terminar

O OpenCode 2.2.6 acrescentou --archived para sessões de script ou CI começarem arquivadas e ficarem fora das listas comuns. Isso muda a apresentação da sessão. Guarde o resultado da tarefa, o caminho da árvore e os testes onde as pessoas que revisam possam achá-los. Use a opção depois de ter uma maneira confiável de encontrar o patch mesmo com a lista comum vazia. As notas de 6 de novembro dizem que --continue ignora sessões arquivadas. Versão OpenCode v2.2.6

A mesma versão muda o ciclo de vida da execução por script. Ela espera comandos em segundo plano, subagentes e trabalhos de imagem iniciados pelo prompt antes de sair. As notas dizem que a espera não tem limite interno. Um servidor de desenvolvimento ou monitor de arquivos pode manter a tarefa aberta. Em um teste automatizado, prefira comandos que terminem após a verificação e dê um limite de tempo à etapa de CI. Diferencie uma execução cancelada, um teste que falhou e um agente que relatou sucesso. Se o tempo expirar, confira o estado real das mudanças antes de reiniciar ou integrar. Versão OpenCode v2.2.6

Com o piloto funcionando, avalie a economia de tempo para além da mensagem de conclusão do agente. Quanto leva para preparar uma execução limpa? Quanto tempo a revisão leva para entender e verificar a mudança? Com que frequência alguém precisa corrigir uma edição fora do escopo ou investigar uma ferramenta travada? Compare tarefas parecidas, incluindo tempo de preparação e revisão. A árvore separada vale mais quando mantém o patch pequeno o bastante para alguém assumir responsabilidade por ele.

Uma cópia limpa deixa a responsabilidade visível

A utilidade da opção é dar à pessoa que revisa um ponto claro de partida. Ela consegue ver a base, inspecionar a alteração e repetir o teste enquanto a outra pessoa continua trabalhando. Deixe igualmente explícitas as permissões de execução e de compartilhamento de conexões. A melhor entrega é um patch pequeno que mostra onde começou, o que mudou e quais evidências sustentam a integração.

Fontes

• Captura oficial do terminal do OpenCode e licença do repositório

• Versão OpenCode v2.2.6, 6 de novembro de 2026

• Documentação da CLI do OpenCode

• Permissões do OpenCode V2

• Compartilhamento de conexões MCP do OpenCode

• Manual de git worktree

---

Para manter um registro pesquisável das decisões e dos experimentos por trás do trabalho, crie uma conta no Telli.sh.