Checkpoints y /rewind en Claude Code: tu red de seguridad para ediciones arriesgadas

Dejas a Claude Code refactorizando treinta minutos, echas un vistazo a la pantalla, y el runner de tests arde en rojo. Hay tres ficheros rotos, ya no recuerdas exactamente qué prompt tocó qué, y git diff te enseña un muro de cambios. Justo para ese momento existen los checkpoints. Cada prompt que envías crea automáticamente una instantánea de tus ficheros, y con /rewind (o Esc dos veces) saltas a cualquier punto de la sesión. Yo ya lo uso diez veces al día y no quiero trabajar sin ello.

Aquí van los diez pasos para usar bien los checkpoints. Te ahorran el reflejo de hacer commit cada minuto y aun así puedes experimentar de forma agresiva.

Paso 1: Entender qué se registra (y qué no)

Claude Code crea un checkpoint de tus ficheros en cada prompt, pero SOLO de los ficheros que se tocan con las herramientas de edición de Claude. Si Claude ejecuta un comando de bash como rm file.txt o mv old.txt new.txt, eso es invisible para los checkpoints. Los cambios externos que haces tú en el editor también quedan fuera.

O sea: los checkpoints no sustituyen a git. Son un deshacer de sesión para las ediciones de la IA. Del historial a largo plazo se sigue encargando git. Si eso lo tienes claro, evitas el error clásico de principiante de "pues hago rewind" cuando un npm install ha roto algo. Lo de bash se queda roto.

Paso 2: Abrir el menú de rewind

Escribe /rewind o pulsa Esc dos veces con la línea de prompt vacía. Ojo: si todavía queda texto ahí, el primer Esc vacía el campo de entrada (el texto va al historial, lo recuperas con la flecha arriba). Solo con el segundo Esc en vacío se abre el menú.

El menú de rewind lista cada prompt que has enviado en la sesión, de arriba (antiguo) a abajo (nuevo). Las flechas arriba y abajo recorren los puntos, enter selecciona uno.

Paso 3: Restore code and conversation (el reinicio duro)

La opción por defecto. Devuelve tanto tus ficheros como el historial de chat al estado previo al prompt seleccionado. El prompt original vuelve a la línea de entrada, lo puedes editar y volver a mandar.

Ese es mi valor por defecto para "he mandado a Claude en la dirección equivocada hace diez minutos". Un clic, todo atrás, otro prompt, y seguimos. Ahorra 20 minutos de discusión con Claude sobre dónde entendió mal algo.

Paso 4: Restore code (ficheros atrás, conservar el chat)

Quieres recuperar el código porque un refactor ha roto algo, pero la conversación en realidad estaba bien. Coge "Restore code". Los ficheros vuelven atrás, el chat se conserva entero.

Útil cuando Claude ya ha reconocido el fallo en la conversación ("ah, he importado mal el módulo") y no quieres que rehaga el cambio desde cero. Ficheros atrás, y después le dices "vale, arregla el fallo del import pero deja lo demás".

Paso 5: Restore conversation (chat atrás, conservar el código)

La variante espejo. Quieres recortar el historial de chat porque lo has llenado sin querer de desvíos, pero el estado del código debe quedarse. Buena opción cuando Claude se ha pasado treinta minutos filosofando sobre el patrón de diseño equivocado y tú quieres conservar el último estado funcional de los ficheros.

En la práctica eso también es una forma de reiniciar el contexto sin perder el espacio de trabajo.

Paso 6: Summarize from here frente a summarize up to here

Las dos opciones de resumen son la función estrella cuando se te llena la ventana de contexto. Sustituyen partes del chat por un resumen generado por la IA y con eso hacen sitio.

• Summarize from here: todo lo ANTERIOR al prompt seleccionado se conserva con detalle, el prompt seleccionado y todo lo posterior se condensan en el resumen. Útil cuando has tenido una sesión de depuración salvaje y solo necesitas el plan inicial con detalle.
• Summarize up to here: la imagen espejo. Todo lo ANTERIOR al prompt seleccionado se condensa, a partir de ahí se conserva con detalle. Reinicio clásico de la fase de montaje: lo temprano se convierte en resumen, tus últimos 20 minutos de trabajo productivo quedan intactos.

Las dos variantes mantienen los mensajes originales en la transcripción de la sesión, así que Claude todavía puede referenciarlos si hace falta. Eso es más dirigido que /compact, que sencillamente lo aplana todo.

Paso 7: Conocer el truco del fork para experimentar

Si quieres probar una alternativa SIN tocar la sesión en marcha, el rewind es la opción equivocada. Coge el fork: claude --continue --fork-session. Con eso creas una rama de la sesión, y la original se queda intacta.

Patrón práctico: cuando dudo si un enfoque va a funcionar, hago fork de la sesión y pruebo el enfoque en el fork. Si no funciona, tiro el fork y sigo en la original. Si funciona, muevo los ficheros a mano (o lo convierto en la nueva sesión principal).

Paso 8: Aprovechar la persistencia de 30 días

Los checkpoints viven 30 días y sobreviven a los reinicios de sesión. Si terminas una sesión el lunes y vuelves a entrar el miércoles con claude --continue, todos los checkpoints siguen ahí. Puedes saltar días después al punto en el que el test A estaba en verde.

Rutina obligatoria: cuando llegues a un estado realmente crítico (tests en verde, listo para desplegar), haz igualmente un commit de git. Los checkpoints son una comodidad, no un sistema de copias de seguridad. 30 días se van rápido si te pones malo o te vas de vacaciones.

Paso 9: Combinación con el modo plan y los subagents

Donde los checkpoints se vuelven realmente fuertes: en combinación con el modo plan. El modo plan te deja aprobar un plan paso a paso antes de la ejecución. Si Claude luego se desvía durante la ejecución, haces rewind al punto ANTERIOR a la aprobación, corriges el plan y lo vuelves a lanzar.

Lo mismo vale para los subagents. Si un subagent construye una tontería en las profundidades, es más fácil hacer rewind del prompt principal que intentar reparar hacia atrás lo que ha producido.

Sobre el modo plan lee nuestro playbook Usar bien el modo plan, y sobre el montaje de subagents Tu primer subagent en 30 minutos.

Paso 10: Evitar los antipatrones

Tres errores que veo a menudo y que conviene evitar:

1. Usar el rewind como sustituto de git. Si lanzas comandos de bash para operaciones con ficheros (mv, rm, cp), eso no lo puedes deshacer con rewind. Tampoco las ediciones manuales en el editor. Para todo lo que no sean ediciones de ficheros hechas por Claude sigues necesitando git.
2. Olvidar que lo externo no se registra. Si una segunda sesión de Claude Code trabaja en paralelo sobre el mismo repo (yo lo hago a menudo con subtareas distintas), la sesión A no ve las ediciones de la sesión B en su propio checkpoint. En el peor caso haces rewind de un fichero que la sesión B está rellenando justo ahora.
3. Usar el resumen de forma demasiado agresiva. Las dos opciones de resumen condensan información. Lo que Claude considera "poco importante" para el resumen no tiene por qué serlo para ti. Si acabas de tomar una decisión de arquitectura sutil, no resumas justo por encima. Mejor /compact con instrucciones explícitas, o un fork.

Qué sigue

Cuando tengas los checkpoints asentados, el siguiente paso lógico es el flujo limpio de contexto. Mira Gestionar la ventana de contexto en Claude Code, donde profundizamos en /compact, los forks de sesión y la diferencia entre recuperación local e historial permanente.

Si quieres usar los checkpoints en un montaje de equipo (varias personas en el mismo repo), combínalo con nuestro playbook Claude Code en equipo. Ahí pone cómo compartir CLAUDE.md de forma limpia para que las sesiones se mantengan coherentes.

Source

Especificaciones verificadas contra la documentación oficial:

• Referencia de checkpointing
• Modo interactivo (atajos de teclado)
• Forks de sesión