Fluxo de revisão do Claude Code: o novo painel de diferenças em tela cheia em 2.1.260

O que mudou no Claude Code 2.1.260

A principal adição para revisar alterações de código feitas por IA é o painel de diff em tela cheia. As notas da versão 2.1.260 descrevem um painel ao lado da conversa que mostra alterações sem commit enquanto o Claude edita. O /diff comando ativa ou desativa o painel.

Isso oferece um espaço para inspecionar o diff à medida que ele muda, mantendo a conversa visível. Um hábito útil de revisão é comparar essas alterações com sua solicitação: quais arquivos devem mudar, qual comportamento deve mudar e quais restrições devem continuar sendo respeitadas?

Abra o painel de diff em tela cheia

Mude a renderização da conversa atual para tela cheia e, em seguida, ative ou desative o painel:

/tui fullscreen
/diff

O modo de tela cheia é anterior a esta versão. A versão 2.1.110 introduziu /tui e a tui configuração; /tui fullscreen altera a renderização dentro da mesma conversa. Esses detalhes anteriores estão registrados nas registro de alterações fixado em uma versão.

Essa distinção é importante ao descrever a atualização: o Claude Code 2.1.260 introduziu o painel de diff em tempo real, enquanto o comando usado para entrar em tela cheia já existia.

As notas de versão pertinentes não estabelecem uma largura mínima do terminal, abertura automática do painel, atalhos de navegação ou comportamento de filtragem de arquivos. Comece pelos dois comandos documentados em vez de depender de controles que não haviam sido confirmados até a data de corte da publicação.

Para uma orientação mais ampla, o central de guias do Claude Code oferece um ponto de partida para o fluxo de trabalho mais amplo.

Um fluxo de trabalho prático de revisão no Claude Code

Use três pontos de verificação separados: defina a alteração pretendida, inspecione o diff resultante e solicite uma revisão automatizada. As permissões devem acompanhar esses pontos de verificação porque regem a confirmação de ações de ferramentas.

A sequência a seguir é um método de trabalho recomendado. Ela combina os comandos estabelecidos no registro de alterações sem tratar o novo painel como uma interface de aprovação.

1. Defina o escopo antes de editar

Dê ao Claude uma tarefa bem delimitada e critérios de revisão claros. Descreva o comportamento esperado, as restrições relevantes e tudo o que precisa de atenção especial.

Por exemplo, uma solicitação para alterar o tratamento de erros deve identificar a resposta esperada a uma falha. Durante a revisão, use esse requisito para avaliar se as alterações tratam a falha de maneira consistente.

Mantenha a solicitação restrita o suficiente para que você consiga explicar por que cada arquivo alterado faz parte do diff. Se uma edição parecer não ter relação com a tarefa, peça ao Claude que explique sua conexão com ela antes de prosseguir.

2. Inspecione as alterações à medida que aparecem

Abra o modo de tela cheia e alterne /diff. À medida que o Claude edita, compare as alterações ainda não incluídas em um commit com o escopo que você definiu.

Uma ordem prática de inspeção é:

1. Verifique se os arquivos alterados fazem parte da tarefa.
2. Leia o comportamento alterado e as premissas relacionadas a ele.
3. Procure omissões, escopo inesperado ou raciocínio pouco claro.
4. Peça ao Claude que resolva preocupações específicas e, em seguida, inspecione o diff atualizado.

Trate isso como uma conversa contínua. Uma solicitação de acompanhamento precisa deve identificar o comportamento alterado que preocupa você e o resultado que você esperava.

O painel mostra edições já aplicadas que ainda não foram incluídas em um commit. Sua finalidade documentada é dar visibilidade a essas alterações; as notas de versão não estabelecem controles de aprovação por trecho.

3. Solicite uma revisão e avalie os resultados

Quando as alterações estiverem prontas para outra inspeção, use /review ou /code-review. Avalie os resultados com base no diff real e nos seus requisitos originais.

Para cada correção sugerida, pergunte se ela identifica um problema concreto, se a alteração proposta se encaixa na tarefa e se amplia o escopo. Em seguida, inspecione novamente todas as edições resultantes.

Isso cria um ciclo de revisão: inspecionar, solicitar revisão, resolver os problemas encontrados e verificar novamente o código alterado. Evite tratar um diff visível ou uma resposta de revisão automatizada como evidência suficiente por si só.

O que /diff, /review e /code-review de fato

Os comandos têm finalidades diferentes. /diff controla o painel em tempo real; /review invoca o comando de revisão por meio de um alias.

O notas da versão 2.1.223, datadas de 6 de agosto de 2026, estabelecem que /review passou a ser um alias de /code-review. Esse comportamento já estava presente antes da chegada do painel de diff em tela cheia.

Revise o diff atual

O documento de referência estabelece que /review e /code-review pode revisar o diff atual. Uma solicitação básica de revisão é:

/review

A partir de 2.1.223, invocar /code-review sem um nível de esforço reutiliza o último nível informado. Se quiser explicitar a escolha do nível de esforço, use:

/code-review high

Não presuma que omitir o nível de esforço o redefine para um padrão fixo. O comportamento documentado é reutilizar a seleção anterior.

Revise um pull request específico

As notas de versão apresentam esta sintaxe para pull requests:

/code-review <level> <pr#>

Aqui, <level> e <pr#> são marcadores de posição para o nível de esforço e o número do pull request. Portanto, o mesmo comando de revisão abrange tanto o diff atual quanto um pull request especificado.

Para materiais relacionados à linha de comando, consulte referência da CLI do Claude Code.

Entenda a revisão aprofundada na nuvem

O comando documentado para solicitar uma revisão aprofundada na nuvem é:

/code-review ultra

Separadamente, a versão 2.1.260 aumentou o tempo de espera para revisões demoradas na nuvem por meio de /ultrareview e claude ultrareview de 30 para 45 minutos.

Mantenha a formulação precisa: trata-se de um aumento no limite de espera desses comandos, não de uma promessa de que uma revisão terminará em 45 minutos. As notas de versão também não fornecem um preço específico para revisões, portanto não fundamentam uma estimativa de custo para esse fluxo de trabalho.

Revise alterações e aprove ações separadamente

“Revisar antes de aprovar” pode descrever dois momentos diferentes: verificar uma ação proposta por uma ferramenta antes de permiti-la ou inspecionar uma edição antes de decidir que ela está pronta para ser mantida.

O histórico de alterações documenta /permissions como uma forma de exigir confirmação para ferramentas específicas:

/permissions

Use essa configuração quando seu fluxo de trabalho exigir uma etapa de confirmação para uma ferramenta específica. Em uma solicitação de confirmação, avalie a ação proposta com base na tarefa e nas suas restrições.

O painel de diff em tela cheia ocupa outro ponto na sequência. Ele exibe alterações ainda não incluídas em um commit que já foram aplicadas enquanto o Claude edita. Inspecionar essas alterações ajuda você a decidir o que precisa de mais explicações, correções ou revisão.

Mantenha os pontos de verificação explícitos

Uma lista de verificação útil para revisão separa as perguntas:

• Antes de aprovar o uso da ferramenta: A ação proposta é apropriada para esta tarefa?
• Após a edição: As alterações aplicadas correspondem ao comportamento solicitado?
• Após a revisão automatizada: Quais problemas encontrados exigem correção ou investigação adicional?
• Antes de manter o resultado: Você verificou as alterações finais com base nos seus requisitos?

Essa distinção impede que uma solicitação de aprovação se torne um substituto para a revisão de código. Ela também impede que o painel de diff seja descrito como um controle para autorizar edições antes que elas ocorram.

As notas da versão 2.1.260 não estabelecem um botão “aceitar todas as alterações” nem controles de aceitar/rejeitar por trecho. Descreva /diff como um painel de inspeção e tome decisões sobre o código resultante por meio do seu processo de revisão.

Correções na reversão e verificação da restauração

A versão 2.1.260 também inclui duas correções relevantes para desfazer edições. As notas de versão identificam relatos incorretos de sucesso quando faltavam backups de pontos de verificação, além de rastreamento desatualizado de leitura de arquivos após /rewind.

A primeira correção afeta /rewind e --rewind-files. Anteriormente, eles podiam relatar sucesso incorretamente, embora a ausência de backups de pontos de verificação significasse que nenhum arquivo havia sido restaurado.

A segunda correção resolve o rastreamento desatualizado de leitura de arquivos após /rewind. Essas são correções específicas; elas não estabelecem que toda edição sempre possa ser restaurada em qualquer condição.

Verifique o estado após a reversão

Quando uma revisão levar você a desfazer o trabalho, inclua a verificação dos arquivos resultantes no processo de recuperação. Confirme que as alterações relevantes foram restauradas antes de pedir ao Claude que continue.

Essa recomendação decorre da falha corrigida pela versão: uma mensagem de sucesso nem sempre significava que a restauração havia ocorrido. Embora 2.1.260 corrija esse relato incorreto, inspecionar o resultado continua sendo um ponto de verificação útil.

A reversão também tem uma finalidade diferente da revisão automatizada. A revisão ajuda a avaliar alterações; a reversão é relevante quando você decide desfazer edições. O painel em tela cheia permite inspecionar as alterações ainda não incluídas em um commit, enquanto as correções documentadas de reversão dizem respeito à restauração e ao rastreamento subsequente de leitura de arquivos.

Principais conclusões

• O Claude Code 2.1.260, lançado em 3 de setembro de 2026, introduziu um painel de diff em tempo real ao lado da conversa no modo de tela cheia.
• Use /tui fullscreen para entrar na renderização em tela cheia e /diff para alternar o painel que mostra alterações ainda não incluídas em um commit.
• /review é um alias de /code-review; o comando pode revisar o diff atual ou um pull request especificado.
• /permissions rege a confirmação para ferramentas específicas. O painel de diff exibe edições aplicadas, e suas notas de versão não estabelecem controles de aceitação por trecho.
• A versão 2.1.260 corrige relatos enganosos de sucesso na reversão e aumenta o tempo de espera para revisões demoradas /ultrareview e claude ultrareview na nuvem para 45 minutos.

Perguntas frequentes

Como abro o painel de diff em tela cheia do Claude Code?

Execute /tui fullscreen na conversa e, em seguida, use /diff para alternar o painel em tempo real. O Claude Code 2.1.260 introduziu o painel, que mostra alterações ainda não incluídas em um commit ao lado da conversa enquanto o Claude edita.

Qual é a diferença entre /diff e /review?

/diff alterna o painel em tela cheia para inspecionar alterações ainda não incluídas em um commit. /review é um alias de /code-review, que revisa o diff atual ou um pull request; esse alias foi estabelecido na versão 2.1.223.

Posso aprovar alterações individuais no painel?

As notas da versão 2.1.260 não estabelecem controles de aceitar/rejeitar por trecho nem um botão “aceitar todas as alterações”. Elas estabelecem que o painel exibe alterações ainda não incluídas em um commit, enquanto /permissions permite exigir confirmação para ações específicas de ferramentas.

O que /code-review ultra faz, e por quanto tempo a revisão na nuvem pode ser executada?

/code-review ultra solicita uma revisão aprofundada na nuvem. Separadamente, a versão 2.1.260 aumentou o tempo de espera para revisões demoradas por meio de /ultrareview e claude ultrareview para 45 minutos, em vez de 30 minutos; esse limite de espera não garante um prazo de conclusão.