Flujo de revisión de código de Claude Code: el nuevo panel de diferencias a pantalla completa en 2.1.260

Qué cambió en Claude Code 2.1.260

La principal novedad para revisar cambios de código de IA es el panel de diferencias en pantalla completa. Las notas de la versión 2.1.260 describen un panel junto a la conversación que muestra los cambios sin confirmar a medida que Claude edita. El /diff comando permite mostrarlo u ocultarlo.

Esto te ofrece un lugar donde inspeccionar las diferencias a medida que cambian sin perder de vista la conversación. Un hábito útil de revisión es comparar esos cambios con tu solicitud: ¿qué archivos deberían cambiar, qué comportamiento debería cambiar y qué restricciones deberían seguir cumpliéndose?

Abre el panel de diferencias en pantalla completa

Cambia la visualización de la conversación actual al modo de pantalla completa y, después, activa el panel:

/tui fullscreen
/diff

El modo de pantalla completa es anterior a esta versión. La versión 2.1.110 introdujo /tui y el tui ajuste; /tui fullscreen cambia la visualización dentro de la misma conversación. Estos detalles anteriores están documentados en las registro de cambios de la versión específica.

La distinción importa al describir la actualización: Claude Code 2.1.260 introdujo el panel de diferencias en tiempo real, mientras que el comando utilizado para entrar en pantalla completa ya existía.

Las notas de versión aplicables no establecen un ancho mínimo de terminal, la apertura automática del panel, atajos de navegación ni el comportamiento del filtrado de archivos. Empieza con los dos comandos documentados en lugar de depender de controles que no se habían confirmado antes de la fecha de corte de la publicación.

Para una orientación más general, la centro de guías de Claude Code ofrece un punto de partida para el flujo de trabajo relacionado.

Un flujo de trabajo práctico de revisión en Claude Code

Utiliza tres puntos de control separados: define el cambio previsto, inspecciona las diferencias resultantes y solicita una revisión automatizada. Los permisos deben acompañar a esos puntos de control porque regulan la confirmación de las acciones de herramientas.

La siguiente secuencia es un método de trabajo recomendado. Combina los comandos establecidos en el registro de cambios sin tratar el nuevo panel como una interfaz de aprobación.

1. Define el alcance antes de editar

Asigna a Claude una tarea acotada y criterios de revisión claros. Describe el comportamiento esperado, las restricciones pertinentes y cualquier aspecto que requiera especial atención.

Por ejemplo, una solicitud para cambiar la gestión de errores debe identificar la respuesta prevista ante un fallo. Durante la revisión, usa ese requisito para evaluar si las modificaciones abordan el fallo de forma coherente.

Limita el alcance de la solicitud lo suficiente como para poder explicar por qué cada archivo modificado forma parte del diff. Si una modificación parece ajena a la tarea, pide a Claude que explique su relación con ella antes de continuar.

2. Inspecciona los cambios a medida que aparecen

Abre el modo de pantalla completa y activa o desactiva /diff. Mientras Claude edita, compara los cambios sin confirmar con el alcance que definiste.

Un orden práctico de inspección es:

1. Comprueba si los archivos modificados corresponden a la tarea.
2. Lee el comportamiento modificado y los supuestos que lo rodean.
3. Busca omisiones, ampliaciones inesperadas del alcance o razonamientos poco claros.
4. Pide a Claude que aborde los problemas concretos y, después, inspecciona el diff actualizado.

Trata esto como una conversación continua. Una petición de seguimiento precisa debe identificar el comportamiento modificado que te preocupa y el resultado que esperabas.

El panel muestra modificaciones ya aplicadas y sin confirmar. Su finalidad documentada es dar visibilidad a esos cambios; las notas de la versión no establecen controles de aprobación por bloque.

3. Solicita una revisión y evalúa los hallazgos

Cuando los cambios estén listos para otra inspección, usa /review o /code-review. Evalúa los hallazgos frente al diff real y tus requisitos originales.

Para cada corrección sugerida, pregúntate si identifica un problema concreto, si el cambio propuesto encaja con la tarea y si amplía el alcance. Después, vuelve a inspeccionar las modificaciones resultantes.

Esto crea un ciclo de revisión: inspeccionar, solicitar una revisión, resolver los hallazgos y volver a comprobar el código modificado. Evita considerar que un diff visible o una respuesta de revisión automatizada constituyen, por sí solos, evidencia suficiente.

Qué /diff, /reviewy /code-review sí

Los comandos tienen finalidades distintas. /diff controla el panel en tiempo real; /review invoca el comando de revisión mediante un alias.

El notas de la versión 2.1.223, con fecha del 6 de agosto de 2026, establecen que /review pasó a ser un alias de /code-review. Este comportamiento ya existía antes de la llegada del panel de diff en pantalla completa.

Revisa el diff actual

El resumen establece que /review y /code-review puede revisar el diff actual. Una solicitud básica de revisión es:

/review

A partir de 2.1.223, invocar /code-review sin un nivel de esfuerzo reutiliza el último nivel introducido. Si quieres elegir el esfuerzo de forma explícita, usa:

/code-review high

No des por hecho que omitir el nivel de esfuerzo lo restablece a un valor predeterminado fijo. El comportamiento documentado consiste en reutilizar la selección anterior.

Revisa una solicitud de incorporación de cambios específica

Las notas de la versión indican esta sintaxis para las solicitudes de incorporación de cambios:

/code-review <level> <pr#>

Aquí, <level> y <pr#> son marcadores de posición para el nivel de esfuerzo y el número de la solicitud de incorporación de cambios. Por tanto, el mismo comando de revisión abarca tanto el diff actual como una solicitud de incorporación de cambios específica.

Para consultar material relacionado con la línea de comandos, consulta el referencia de la CLI de Claude Code.

Comprende la revisión profunda en la nube

El comando documentado para solicitar una revisión profunda en la nube es:

/code-review ultra

Por otra parte, la versión 2.1.260 aumentó el tiempo de espera de las revisiones prolongadas en la nube mediante /ultrareview y claude ultrareview de 30 a 45 minutos.

Mantén una redacción precisa: se trata de un aumento del límite de espera para esos comandos, no de una promesa de que una revisión terminará en 45 minutos. Las notas de la versión tampoco proporcionan un precio específico para las revisiones, por lo que no permiten estimar el coste de este flujo de trabajo.

Revisa los cambios y aprueba las acciones por separado

«Revisar antes de aprobar» puede describir dos momentos distintos: comprobar una acción propuesta de una herramienta antes de permitirla, o inspeccionar una modificación antes de decidir que está lista para conservarse.

El registro histórico de cambios documenta /permissions como una forma de exigir confirmación para herramientas específicas:

/permissions

Usa esa configuración cuando tu flujo de trabajo requiera un paso de confirmación para una herramienta concreta. Ante una solicitud de confirmación, evalúa la acción propuesta en función de la tarea y tus restricciones.

El panel de diff en pantalla completa ocupa un punto distinto de la secuencia. Muestra cambios sin confirmar que ya se han aplicado mientras Claude edita. Inspeccionar esos cambios te ayuda a decidir qué necesita más explicaciones, correcciones o revisiones.

Mantén explícitos los puntos de comprobación

Una lista de comprobación útil para la revisión separa las preguntas:

• Antes de aprobar el uso de una herramienta: ¿Es adecuada la acción propuesta para esta tarea?
• Después de editar: ¿Coinciden los cambios aplicados con el comportamiento solicitado?
• Después de la revisión automatizada: ¿Qué hallazgos requieren una corrección o una investigación adicional?
• Antes de conservar el resultado: ¿Has comprobado los cambios finales frente a tus requisitos?

Esta distinción evita que una solicitud de aprobación se convierta en un sustituto de la revisión de código. También evita que el panel de diff se describa como un control para autorizar modificaciones antes de que se realicen.

Las notas de la versión 2.1.260 no establecen un botón de «aceptar todos los cambios» ni controles para aceptar o rechazar cada bloque. Describe /diff como un panel de inspección y toma decisiones sobre el código resultante mediante tu proceso de revisión.

Correcciones de la función de retroceso y comprobación de la restauración

La versión 2.1.260 también incluye dos correcciones relacionadas con deshacer modificaciones. Las notas de la versión señalan notificaciones incorrectas de éxito cuando faltaban copias de seguridad de los puntos de control, además de un seguimiento desactualizado de las lecturas de archivos después de /rewind.

La primera corrección afecta a /rewind y --rewind-files. Antes, podían informar incorrectamente de que la operación había tenido éxito, aunque la ausencia de copias de seguridad de los puntos de control significaba que no se había restaurado ningún archivo.

La segunda corrección aborda el seguimiento desactualizado de las lecturas de archivos después de /rewind. Son correcciones específicas; no establecen que todas las modificaciones puedan restaurarse siempre en cualquier circunstancia.

Verifica el estado después de retroceder

Cuando una revisión te lleve a deshacer trabajo, incluye la comprobación de los archivos resultantes en el proceso de recuperación. Confirma que los cambios pertinentes se hayan restaurado antes de pedir a Claude que continúe.

Esta recomendación se deriva del fallo corregido por la versión: un mensaje de éxito no siempre había significado que se hubiera producido la restauración. Aunque 2.1.260 corrige esa notificación incorrecta, inspeccionar el resultado sigue siendo un punto de comprobación útil.

Retroceder también tiene una finalidad distinta de la revisión automatizada. La revisión ayuda a evaluar los cambios; retroceder resulta pertinente cuando decides volver al estado anterior a las modificaciones. El panel de pantalla completa permite inspeccionar los cambios sin confirmar, mientras que las correcciones documentadas de la función de retroceso se refieren a la restauración y al seguimiento posterior de las lecturas de archivos.

Puntos clave

• Claude Code 2.1.260, publicado el 3 de septiembre de 2026, introdujo un panel de diff en tiempo real junto a la conversación en el modo de pantalla completa.
• Usa /tui fullscreen para activar la visualización en pantalla completa y /diff para activar o desactivar el panel que muestra los cambios sin confirmar.
• /review es un alias de /code-review; el comando puede revisar el diff actual o una solicitud de incorporación de cambios específica.
• /permissions regula la confirmación para herramientas específicas. El panel de diff muestra modificaciones aplicadas, y sus notas de la versión no establecen controles de aceptación por bloque.
• La versión 2.1.260 corrige las notificaciones engañosas de éxito al retroceder y aumenta el tiempo de espera de las revisiones prolongadas en la nube de /ultrareview y claude ultrareview a 45 minutos.

Preguntas frecuentes

¿Cómo abro el panel de diff en pantalla completa de Claude Code?

Ejecuta /tui fullscreen en la conversación y, después, usa /diff para activar o desactivar el panel en tiempo real. Claude Code 2.1.260 introdujo el panel, que muestra los cambios sin confirmar junto a la conversación mientras Claude edita.

¿Cuál es la diferencia entre /diff y /review?

/diff activa o desactiva el panel de pantalla completa para inspeccionar los cambios sin confirmar. /review es un alias de /code-review, que revisa el diff actual o una solicitud de incorporación de cambios; ese alias se estableció en la versión 2.1.223.

¿Puedo aprobar cambios individuales en el panel?

Las notas de la versión 2.1.260 no establecen controles para aceptar o rechazar cada bloque ni un botón de «aceptar todos los cambios». Establecen que el panel muestra los cambios sin confirmar, mientras que /permissions permite exigir confirmación para acciones específicas de las herramientas.

¿Qué hace /code-review ultra y cuánto tiempo puede durar la revisión en la nube?

/code-review ultra solicita una revisión exhaustiva en la nube. Por separado, la versión 2.1.260 aumentó el tiempo de espera para las revisiones de larga duración realizadas mediante /ultrareview y claude ultrareview de 30 a 45 minutos; este límite de espera no garantiza un tiempo de finalización.