Worktree é mais adequado como um diretório de execução pontual

Recentemente, a prática comum era preparar uma worktree e abrir o Codex / Claude Code nesse diretório. Como os modelos mais antigos tinham contexto e memória limitados, se você deixasse que eles criassem uma worktree diretamente no main workspace, era fácil confundir o diretório atual com o diretório da worktree após a compressão do contexto, acabando por alterar as coisas de forma errada.
Porém, essa abordagem também tem um efeito colateral: ela acaba transformando a worktree numa área de trabalho de longo prazo. O problema é que a worktree já está vinculada a um branch, e com o tempo, você inevitavelmente enfrentará problemas como trocar de branch, sincronizar branches e limpar branches extras.
Muita gente também não distingue bem a diferença entre worktree e clone independente. A vantagem não é apenas “mais um diretório”, mas que, na essência, continuam sendo o mesmo repositório, compartilhando o git object library, com baixo custo de cópia, sem precisar fazer uma nova clonagem pela rede. Isso é especialmente útil para repositórios grandes. Portanto, se você só quer uma pasta temporária para execução paralela, a worktree é uma solução adequada. Só quando você precisa de um repositório de objetos completamente independente, por exemplo, para mapear para Docker ou uma sandbox de máquina virtual, um clone local é mais apropriado.
Pelo menos para o atual Codex / Claude Code, esse problema já não é tão grave. Agora, prefiro trabalhar diretamente no diretório principal, deixando que ele crie a worktree conforme necessário, fazer as alterações, mesclar de volta e depois remover a worktree. Assim, fica mais alinhado com a proposta original da worktree: um diretório temporário de execução de baixo custo, e não um espaço de trabalho secundário de longo prazo.
Para ir um passo além, atualmente estou tentando uma abordagem onde mantenho um workspace global, com todos os projetos do Codex abertos nesse diretório, e deixo que ele gerencie automaticamente clones e worktrees de acordo com regras. Assim, a memória global fica mais contínua, e se precisar modificar vários projetos ao mesmo tempo, ele sabe como fazer as alterações uma a uma, e depois testar tudo junto.