Checkpoints (puntos de control): Tu red de seguridad para deshacer cambios

📚 Navegación de la serie: El artículo anterior 36 Comandos slash (barra diagonal) te ayudó a estructurar tus accesos rápidos y comandos, en los cuales presentamos la opción /rewind. En este artículo explicaremos en detalle esta característica: los checkpoints (puntos de control) son "capturas previas a la edición" que Claude Code guarda de forma automática para deshacer cambios y volver al estado anterior. Veremos cómo se crean, cómo restaurar el estado, qué elementos se guardan (y cuáles no) y cómo se coordinan con git.

Se suele decir que los checkpoints son tu "píldora del día después". Con esta red de seguridad, puedes dejar trabajar a Claude sin temor. Pero seamos honestos: si lo usas como sustituto de git, tarde o temprano fallará.

Imagina a un desarrollador que empieza a usar Claude Code. Al saber de la existencia de /rewind, se relaja y deja que Claude modifique decenas de archivos a la vez, incluyendo comandos de consola como rm o mv para limpiar directorios. A la tercera iteración nota que el rumbo no es el correcto e intenta volver atrás con /rewind... pero aunque parte del código se restaura, los archivos eliminados con rm no aparecen. Sorprendido, se pregunta: "¿No decían que permitía deshacer?".

Sí, deshace cambios, pero solo aquellos realizados por Claude a través de sus herramientas de edición, no las consecuencias de comandos de consola ejecutados en tu disco duro, y mucho menos el historial persistente de git. El checkpoint es un "deshacer local a nivel de conversación" rápido, automático y capaz de restaurar el historial de chat; pero tiene límites muy claros.

Este artículo tiene dos objetivos: enseñarte a usar el flujo de "guardado automático y restauración" de checkpoints, y definir sus límites de forma estricta: qué se puede restaurar, qué no se recuperará jamás, cuándo confiar en checkpoints y cuándo recurrir a git de forma obligatoria. Entender estos límites es lo que transforma a esta característica en una verdadera red de seguridad.

Al terminar de leer este artículo, obtendrás:

• Qué es un checkpoint y en qué momentos realiza capturas de forma automática (sin tu intervención).
• Las dos formas de abrir el menú de restauración: el comando /rewind o pulsar doble Esc con el cuadro vacío, detallando sus opciones.
• Una tabla de comparación: "qué se puede restaurar" frente a "qué no se puede recuperar" (código e historial de chat frente a comandos Bash y estados externos).
• La división de responsabilidades entre checkpoints y git: cuándo usar cada uno y por qué no son sustitutos.
• Un ejercicio práctico paso a paso: provocar un cambio erróneo en el código y restaurarlo con un checkpoint.

---

01 Qué es un checkpoint: Capturas automáticas antes de cada prompt

Empecemos con la definición: un checkpoint es una "captura del código previa a la edición" que Claude Code guarda de forma automática. Se genera cada vez que envías un prompt y te permite regresar a ese estado anterior con escribir /rewind.

En el artículo 07 presentamos esta opción de restauración. Ahora profundizaremos en ella. Piensa en el flujo de trabajo con Claude: envías una instrucción → la IA realiza el ciclo de "pensar → actuar → observar", modificando archivos → evalúas el resultado y envías el siguiente prompt (ciclo detallado en el artículo 03). El checkpoint guarda el estado del código justo antes de procesar cada prompt de entrada.

Analogía: Los marcadores de capítulos en una grabación de vídeo. El reproductor graba el contenido de forma continua, pero genera marcadores al inicio de cada sección o capítulo. Si quieres volver a ver una parte, saltas directamente a ese marcador sin necesidad de rebobinar de principio a fin. Los checkpoints funcionan igual: cada prompt enviado genera un marcador en la cronología de la sesión, y /rewind te permite volver a ese marcador de forma directa. La diferencia es que no solo "ves" el estado anterior; el código y la conversación regresan físicamente a ese punto para que tomes otro rumbo de desarrollo.

La documentación oficial define esta función:

Al trabajar con Claude, el sistema de checkpoints captura automáticamente el estado del código antes de cada edición. Esta red de seguridad te permite abordar refactorizaciones complejas con tranquilidad, sabiendo que siempre puedes regresar a un estado anterior.

Nota la palabra clave: automáticamente. Esta es la gran diferencia con git: no requieres hacer nada. En git debes confirmar los cambios con git commit manualmente; los checkpoints se guardan en segundo plano de forma silenciosa sin que tengas que preocuparte de si guardaste o no.

Casos de uso típicos descritos en el manual:

• Evaluar alternativas: si el enfoque A no te convence, regresas al punto de partida para probar el enfoque B, manteniendo el código limpio y eliminando el miedo a "romper el proyecto".
• Corregir desvíos: si tras una edición fallan los tests y no quieres revisar línea por línea para deshacer los cambios, regresas al checkpoint anterior y listo.
• Iterar desarrollos: dejas que Claude reescriba un módulo completo para probar; si el resultado no convence, restauras el estado previo como si no hubiera pasado nada.
• Liberar contexto: tras una larga sesión de depuración, quieres mantener la configuración inicial pero limpiar las pruebas fallidas intermedias (usando la opción de resumen que explicamos en la sección 03).

Todas estas situaciones responden al mismo principio: "quiero probar un enfoque complejo con libertad, pero con la seguridad de poder volver atrás si falla". Los checkpoints resuelven este problema.

💡 Resumen en una frase: Un checkpoint es una captura automática del código previa a la edición que se genera ante cada prompt enviado, permitiéndote regresar a ese punto con /rewind sin necesidad de realizar guardados manuales.

---

02 Funcionamiento interno: Cuándo, dónde y cuánto tiempo se guardan

Al ser un proceso automático, es importante saber cómo se comporta el sistema: cuándo realiza las capturas, dónde se guardan en el disco y cuánto tiempo se conservan.

Cuándo se guardan: Un checkpoint por prompt

La regla es sencilla: cada prompt enviado por el usuario genera un nuevo checkpoint. La documentación oficial lo detalla:

Cada prompt de usuario genera un nuevo checkpoint.

Por lo tanto, la frecuencia de los puntos de restauración sigue el ritmo de tu conversación: si envías diez prompts, dispondrás de diez checkpoints a los que regresar. Esto explica por qué el menú de restauración muestra la lista de prompts de tu conversación actual: cada uno representa el inicio de una tarea y un punto de restauración.

Visualicemos este flujo de guardado a lo largo de una conversación:

El diagrama muestra que cada prompt genera un checkpoint antes de que Claude comience a trabajar (nodos azules). Si al llegar al prompt 3 notas que el código se ha desviado, escribes /rewind y regresas al checkpoint 1 (línea discontinua), deshaciendo las ediciones y la conversación de los prompts 2 y 3.

Dónde se guardan: Carpeta local ~/.claude

Las capturas no se guardan en la memoria temporal; se escriben en el disco duro. La documentación del proyecto (claude-directory.md) define su ubicación:

file-history/<session>/ — Contiene las capturas previas a la edición de los archivos modificados por Claude, utilizadas para la restauración de checkpoints.

Los archivos se guardan en el directorio ~/.claude/file-history/<session>/. No necesitas manipularlos de forma manual, pero es útil saber dónde están para entender que hay copias físicas en disco y para controlar el espacio que ocupa la aplicación en tu máquina.

Persistencia: Disponibles entre sesiones

Al guardarse en disco, los checkpoints no se pierden al cerrar la terminal. La documentación oficial lo detalla:

Los checkpoints persisten entre sesiones de chat, lo que te permite acceder a ellos al reanudar una conversación previa.

Es decir, si cierras la sesión hoy con Ctrl+D y regresas mañana con claude --resume (o --continue), los checkpoints anteriores seguirán disponibles y podrás ejecutar /rewind para regresar a un punto de ayer. Es un comportamiento muy cómodo: las sesiones no se borran al cerrar la terminal, sino que se asocian al identificador de la conversación y persisten en el disco según los límites de la directiva cleanupPeriodDays.

Cuánto tiempo se conservan: Límite de 30 días

Las capturas no se guardan para siempre; el sistema realiza limpiezas periódicas:

Limpieza automática tras 30 días de inactividad (configurable).

Esta limpieza depende del parámetro cleanupPeriodDays en el archivo settings.json (que abordamos en el artículo 31). Por defecto, elimina los datos de sesiones inactivas tras 30 días (admite un mínimo de 1 día, y ponerlo en 0 dará error). Nuestra recomendación es dejar el valor por defecto. Treinta días es suficiente; las versiones a largo plazo deben gestionarse en git (sección 05) y no depender de las capturas temporales de Claude.

Saber que las copias se guardan en file-history en tu directorio de usuario te ayudará a comprender cómo Claude gestiona el historial en segundo plano sin intervención manual.

Propiedad	Comportamiento	Gestión
Frecuencia	Un checkpoint por cada prompt enviado	Automático
Ubicación	~/.claude/file-history/<session>/	Transparente para el desarrollador
Persistencia	Se mantienen al cerrar y reanudar la sesión	Persisten en disco
Expiración	Eliminación tras 30 días (cleanupPeriodDays)	No modificar; usar git para histórico persistente

💡 Resumen en una frase: Los checkpoints se guardan ante cada prompt, se escriben en ~/.claude/file-history/, persisten al cerrar la terminal y se borran a los 30 días; todo el flujo se gestiona en segundo plano sin que tengas que intervenir.

---

03 Cómo restaurar: /rewind, doble Esc y opciones del menú

Una vez guardados, veamos cómo invocarlos. Dispones de dos accesos directos: el comando /rewind o pulsar dos veces Esc con el cuadro vacío.

Accesos directos

El primero consiste en escribir el comando slash en el chat:

/rewind

El segundo es más directo: si el cuadro de entrada está vacío, pulsa dos veces la tecla Esc:

(con el cuadro vacío, pulsa Esc Esc)

Ambas acciones abren el menú de restauración (rewind menu). Palabras de la documentación oficial:

Ejecuta /rewind o pulsa la tecla Esc dos veces cuando el cuadro de entrada esté vacío para abrir el menú de restauración.

Recordamos el detalle de edición del artículo 14 que debes tener en cuenta:

Si el cuadro de entrada contiene texto escrito, pulsar doble Esc limpiará el texto en lugar de abrir el menú de checkpoints. El texto borrado se guardará en el historial de comandos, pudiendo recuperarse pulsando ↑ después de interactuar con el menú.

En resumen: si el cuadro contiene texto, doble Esc lo borrará. Para abrir el menú de checkpoints, asegúrate de que el cuadro esté vacío antes de pulsar doble Esc. Si te resulta confuso, escribe el comando /rewind directamente, el cual se abrirá sin importar si hay texto o no.

Opciones del menú de restauración

Al abrir el menú, se listará cada uno de los prompts de la sesión actual (los marcadores de la cronología). Elige el punto de restauración y, a continuación, selecciona el método de restauración. Las opciones disponibles son:

Opción de menú	Comportamiento	Caso de uso recomendado
Restore code and conversation	Restaura el código y el historial de chat al punto elegido	Quieres desechar las últimas iteraciones por completo y empezar de cero desde ese punto.
Restore conversation	Restaura el chat al punto elegido, manteniendo el código actual	El código modificado es correcto, pero la conversación se ha desviado y quieres reconducirla.
Restore code	Restaura el código al punto elegido, manteniendo el chat actual	El código no funciona y quieres revertirlo, pero quieres mantener la explicación del chat y el contexto.
Summarize from here	Resume la conversación actual a partir de este punto	Quieres compactar un hilo secundario de depuración para no saturar el contexto.
Summarize to here	Resume la conversación anterior hasta llegar a este punto	Quieres compactar los prompts de saludo e inicio y mantener los detalles de los últimos mensajes.
Cancel	Cierra el menú sin realizar acciones	Pulsación por error.

La opción de restaurar solo una de las partes ("Restore code" o "Restore conversation") es muy útil en el desarrollo:

• Usar "Restore code" (solo código): has debatido un algoritmo con Claude durante cinco prompts y decidís la implementación. Claude modifica el código pero introduce un bug estructural. Quieres deshacer la edición del código, pero no quieres perder los cinco prompts de conversación previos donde se definió el algoritmo. Al elegir "Restore code", el archivo vuelve a su estado original pero el chat se mantiene intacto, permitiéndole a Claude reescribir con base en la conversación previa.
• Usar "Restore conversation" (solo chat): Claude ha modificado el archivo y el código funciona correctamente, pero a continuación le has hecho preguntas sobre otros archivos y el contexto se ha vuelto confuso. Eliges "Restore conversation" para limpiar el chat posterior, manteniendo los cambios de código en los archivos.

Como ves, puedes disociar el código y el chat al revertir cambios. La opción más habitual es "Restore code": el plan es correcto pero la implementación falló; deshaces el código y le pides que intente la edición de nuevo.

Es importante diferenciar las acciones de "Restore" y "Summarize". No realizan la misma tarea aunque se listen en el mismo menú:

• Restore (restaurar) = revisión de estado: revierte el código de los archivos, el historial del chat o ambos al punto seleccionado. Es un viaje al pasado.
• Summarize (resumir) = gestión de contexto: condensa el chat seleccionado en un resumen textual generado por IA para liberar espacio de tokens, sin modificar los archivos en disco.

La documentación oficial define esta diferencia de comportamiento:

Las opciones de restauración (restore) modifican el estado: revierten cambios en archivos, el historial del chat o ambos. Las opciones de resumen (summarize) compactan fragmentos de la conversación en un texto de resumen sin alterar los archivos del disco.

Esta opción de resumen es una variante de la compactación de contexto que vimos con /compact en el artículo 19. Mientras /compact resume todo el chat, las opciones del menú de checkpoints te permiten elegir a partir de qué prompt realizar la compactación para mantener intacto el bloque que te interese.

Al seleccionar "Restore conversation" o "Summarize from here", el prompt del mensaje seleccionado se copiará de forma automática en tu cuadro de entrada para que puedas editarlo y enviarlo de nuevo, facilitando la redirección de la tarea.

Dudas habituales al restaurar

"El menú de checkpoints está vacío o tiene pocas opciones" → Es el comportamiento normal si estás al inicio de la sesión. El menú lista los prompts enviados en la sesión; si acabas de iniciar el chat, no habrá puntos de guardado. Los checkpoints se crean conforme avanza la conversación.

"Me he equivocado al seleccionar el checkpoint y he restaurado un punto muy antiguo, ¿puedo recuperarlo?" → Los checkpoints persisten en el disco duro (sección 02) y no se eliminan por el hecho de restaurar una versión anterior. Abre de nuevo el menú con /rewind y selecciona un prompt más reciente de la lista para volver a ese estado. En cualquier caso, para mayor seguridad, te recomendamos realizar un git commit antes de cambios estructurales; la persistencia de git es tu salvaguarda definitiva (sección 05).

💡 Resumen en una frase: Abre la restauración con /rewind o doble Esc sin texto; en el menú, selecciona el punto temporal y define si restaurar ("Restore" para revertir archivos o chat) o compactar ("Summarize" para aligerar contexto). Si deshaces de más, el menú mantiene los puntos en disco para reajustar.

---

04 Límites del sistema: Qué se puede restaurar (y qué no)

Esta sección es de vital importancia para evitar pérdidas de información. Los checkpoints solo registran las modificaciones directas realizadas por las herramientas de edición de Claude (Edit, Write, MultiEdit). Cualquier cambio realizado por otras vías quedará fuera de su control.

Analogía de la grabación de vídeo: Graba la pantalla, no la habitación. Si grabas un tutorial de desarrollo y a mitad de la grabación se derrama café sobre tu teclado, al rebobinar el vídeo verás la pantalla limpia, pero el café seguirá sobre el teclado. El rebobinado de checkpoints maneja los archivos de código; no puede revertir las consecuencias de comandos de consola o conexiones de red que interactúen con el sistema operativo.

Detallamos qué elementos puede y cuáles no puede gestionar el sistema de checkpoints:

Tipo de cambio	¿Restaurable por checkpoints?	Motivo de compatibilidad
Contenido de código modificado por herramientas de edición	✅ Sí	Es el objetivo de monitorización de la herramienta.
Historial de la conversación en el chat	✅ Sí	Se guarda y restaura en el menú interactivo.
Archivos alterados por comandos Bash (rm, mv, cp...)	❌ No	Los cambios de consola escapan al control de los checkpoints.
Archivos no modificados durante la conversación activa	❌ No	El sistema solo vigila archivos que Claude ha editado en la sesión.
Cambios realizados por el desarrollador en editores externos	❌ No	Las ediciones fuera de Claude Code no se registran.
Modificaciones hechas por otras sesiones simultáneas	❌ No	Cada sesión de chat gestiona sus checkpoints de forma independiente.
Efectos secundarios externos (llamadas API, escrituras en base de datos...)	❌ No	Escapan al control de los archivos de código en disco.

Presta atención a los dos primeros límites. Sobre los comandos ejecutados en consola:

...

El sistema de checkpoints no registra archivos modificados por comandos de bash. Si Claude Code ejecuta órdenes como rm file.txt, mv old.txt new.txt o cp source.txt dest.txt, estos cambios de archivos no podrán deshacerse mediante la restauración. Solo se registran las ediciones de archivos directas hechas por las herramientas de edición de Claude.

Este es el caso que comentábamos al inicio: si Claude elimina un archivo ejecutando rm en Bash, /rewind no podrá recuperarlo. Distingue cómo modifica Claude los archivos mirando los nombres de las herramientas en el chat (puedes pulsar Ctrl+O para desplegar la información detallada):

• Si utiliza herramientas de edición (Edit, Write, MultiEdit) → Los cambios se registran y se pueden deshacer con /rewind.
• Si utiliza la consola (Bash) para ejecutar comandos (rm, mv, cp, redirecciones >...) → Las modificaciones no se registran y /rewind no podrá recuperarlas.

Revisa los nombres de las herramientas en el log de Claude. Si Claude va a ejecutar comandos de consola que alteren archivos (como renombrar directorios o borrar temporales), no confíes en /rewind y realiza un commit en git previamente.

Sobre las modificaciones externas:

Los checkpoints solo registran los archivos modificados dentro de la sesión de conversación activa. Los cambios manuales realizados en tu editor de código o por otras terminales simultáneas de Claude Code no se registrarán, a menos que coincidan en el mismo archivo editado en la sesión.

Es decir, lo que edites en VS Code o en otra pestaña de consola no se guardará en los checkpoints del chat activo.

Sigue esta regla de desarrollo: si la tarea implica comandos de consola, borrado de archivos, accesos a bases de datos o peticiones externas, realiza un git commit previo de control; no confíes la seguridad del repositorio a /rewind. Reserva los checkpoints para la depuración y reescritura de algoritmos de código.

Incidencia en el desarrollo	¿Se recupera con /rewind?	Gravedad	Solución de restauración
Un algoritmo implementado no compila	✅ Sí	Leve	Ejecutar /rewind
Claude borra una carpeta con rm -rf en Bash	❌ No	Crítica	Usar git checkout o backups locales
Un script de base de datos modifica registros de producción	❌ No	Crítica	Backups de base de datos o rollback de transacciones
Claude ejecuta un git push no deseado	❌ No	Moderada	Revertir el commit en el repositorio remoto con git
Modificas un archivo en VS Code y Claude lo sobrescribe	❌ No	Leve	Usar la función de deshacer de tu IDE o git

Los fallos marcados con ❌ escapan del ámbito de los checkpoints al no ser ediciones directas de archivos en la sesión de chat. Tenlo presente.

💡 Resumen en una frase: Los checkpoints solo restauran archivos editados por las herramientas de Claude y el chat; comandos de consola (rm/mv), cambios externos y llamadas de red quedan fuera de su control. Si el cambio va más allá de editar el texto de un archivo, usa git.

---

05 Coordinación con git: Deshacer en local frente a histórico persistente

Entendido su comportamiento, analicemos la coordinación con git. ¿Es necesario usar git si ya disponemos de checkpoints? La respuesta es afirmativa: git y los checkpoints cubren necesidades de desarrollo totalmente distintas.

La recomendación oficial define esta relación:

Trata los checkpoints como una herramienta de "deshacer local" y Git como tu "historial persistente".

Analogía: El bloc de borradores frente al libro de actas. Los checkpoints son el borrador: realizas anotaciones, tachas y corriges de forma rápida sobre la marcha. Git es el libro de actas: guardas los documentos finalizados y firmados de forma permanente, accesibles para el resto del equipo y con un control de versiones histórico. No dejas de registrar el libro de actas porque tengas un bloc de borradores, ni usas el libro oficial para tus anotaciones rápidas. Ambas herramientas se complementan.

La documentación define las directrices de uso:

• Utiliza los sistemas de control de versiones tradicionales (como Git) para la gestión de commits, ramas e históricos de desarrollo a largo plazo.
• Los checkpoints complementan pero no sustituyen a las herramientas de control de versiones tradicionales.

Compara el diseño de ambas herramientas:

Criterio	Checkpoint	Git
Disparador	Automático (por prompt)	Manual (ejecutas git commit)
Frecuencia	Alta (cada prompt de la sesión)	Media (al completar una tarea o sección)
Comandos de consola	❌ No registra borrados de Bash	✅ Recupera archivos si estaban comprometidos
Persistencia	Temporal (eliminación por inactividad)	Permanente (se guarda en el repositorio)
Colaboración	❌ Local de tu terminal	✅ Compartido en repositorios remotos
Ámbito óptimo	Iteraciones rápidas y pruebas en local	Hitos de código, ramas y despliegues

Nota: Git tampoco puede revertir llamadas de API externas ni escrituras en bases de datos externas; su ámbito se limita a los archivos del repositorio comprometidos en los commits.

Estrategia de desarrollo recomendada:

• Desarrollo rápido y depuración → Confía en los checkpoints. Cambias el código, ejecutas /rewind si no compila, y pruebas de nuevo. Te evita llenar el historial de git con commits intermedios de pruebas que no aportan valor.
• Hitos de código y fin de tarea → Crea un git commit. Cuando el algoritmo funcione y pase las pruebas, consolida los archivos en git. Este es tu punto de restauración permanente.
• Protección ante comandos de consola → Usa git. Como los checkpoints no registran borrados de Bash (rm), crear un commit antes de ejecutar scripts te asegurará poder recuperar los archivos del repositorio si el comando elimina carpetas por error.

El flujo habitual consiste en: usar los checkpoints para probar y refactorizar en local de forma ágil; y realizar un git commit en cuanto el cambio sea funcional. Esta coordinación te proporciona la agilidad de los checkpoints y la robustez de git. Un error común consiste en programar durante horas sin hacer commits confiando en los checkpoints. Si la sesión da un fallo y el chat se interrumpe, la cronología de checkpoints se romperá, perdiendo los puntos de restauración intermedios. Realiza commits frecuentes.

Explicaremos la integración de Claude Code con git (escribir commits automáticos, gestionar ramas) en el artículo 43 "Flujo de trabajo con Git"; quédate con que los checkpoints son para deshacer en local y git para el histórico de versiones.

Si quieres probar un enfoque alternativo en caliente sin alterar la sesión de chat activa, puedes realizar un fork de la conversación:

claude --continue --fork-session

Crea una conversación paralela manteniendo el contexto actual, permitiéndote probar la alternativa en otro chat sin modificar la cronología de la sesión original (ver artículo 34).

💡 Resumen en una frase: Los checkpoints son tu borrador rápido en local (automático, de alta frecuencia y temporal), y git es tu histórico de versiones permanente (manual, estable y colaborativo). Alterna el uso de ambos y realiza commits al completar hitos para evitar pérdidas de información.

---

06 Ejercicio práctico: Modificar código y restaurar con checkpoints

Realicemos un ejercicio práctico para crear un cambio en un archivo, comprobar su validez y revertir el estado usando los checkpoints.

Paso 1: Crear una carpeta de pruebas e iniciar un repositorio de git

En tu terminal de sistema, crea una carpeta vacía y añade un archivo de prueba:

mkdir ~/rewind-demo && cd ~/rewind-demo
git init
printf 'hello\n' > note.txt
git add note.txt && git commit -m "init: nota inicial"

Resultado esperado: el archivo note.txt contiene la palabra hello y hemos registrado el primer commit en git (esto nos servirá para comparar el comportamiento de las herramientas).

Paso 2: Iniciar Claude y modificar el archivo

Inicia Claude en la carpeta de pruebas:

claude

Envía la primera petición de edición (este prompt generará el primer checkpoint de la conversación):

Modifica el archivo note.txt para que contenga tres líneas: manzana, plátano y cereza; utiliza las herramientas de edición

Resultado esperado: Claude modificará el archivo note.txt añadiendo las tres frutas. En el modo de permisos default te pedirá confirmación; aprueba el cambio. Especificar el uso de herramientas de edición asegura que el cambio entre en el historial de checkpoints.

Paso 3: Realizar una segunda modificación sobre el archivo

Escribe una segunda instrucción de cambio:

Elimina esas tres líneas y escribe la frase: "esta versión no me interesa"

Resultado esperado: el archivo note.txt cambiará su contenido. Ahora disponemos de dos prompts en el historial de la conversación y dos puntos de restauración.

Paso 4: Abrir el menú de checkpoints y restaurar el estado

Asegúrate de que el cuadro de entrada de la terminal esté vacío y pulsa dos veces la tecla Esc (o escribe /rewind):

(con el cuadro vacío, pulsa Esc Esc)

Resultado esperado: se abrirá el menú interactivo con la lista de tus prompts. Selecciona el punto correspondiente a la primera modificación (añadir las frutas) y elige la opción "Restore code and conversation".

Paso 5: Validar que el código ha regresado al estado original

Sal de la conversación (o ejecuta un comando usando ! en el chat) y consulta el contenido del archivo:

! cat note.txt

Resultado esperado: el archivo note.txt volverá a contener únicamente la palabra hello; las dos ediciones de frutas y la frase posterior se habrán eliminado, y el chat habrá regresado al inicio. El archivo ha vuelto a su estado original gracias al checkpoint. Todo ello sin usar comandos de git, gestionado por los checkpoints.

Paso 6: Comprobar el límite con comandos Bash

Ahora probaremos el comportamiento ante comandos Bash de consola. Escribe en el chat:

Elimina el archivo note.txt usando el comando Bash rm

Claude ejecutará rm note.txt en la terminal. Una vez borrado, intenta volver a abrir el menú con /rewind y restaura el estado previo. Consulta el contenido del directorio:

! ls

Resultado esperado: el archivo note.txt no se recuperará y seguirá borrado. Los checkpoints no registran comandos de consola. Para recuperar el archivo, recurre a git:

git checkout note.txt

Resultado esperado: el archivo note.txt se recupera con el texto hello gracias al commit inicial de git. Git ha restaurado lo que el checkpoint no pudo registrar.

Completa esta práctica para experimentar el comportamiento de ambas herramientas y fijar sus límites de uso.

💡 Resumen en una frase: Completa la práctica: edita un archivo con Claude → modifícalo de nuevo → abre el menú con doble Esc y restaura el estado anterior (el archivo vuelve a su inicio) → bórralo con rm en Bash e intenta restaurar (verás que falla y debes usar git checkout); comprobar este comportamiento te ayudará a asimilar el funcionamiento de las herramientas.

---

07 Resumen

En este artículo hemos analizado el funcionamiento y los límites del sistema de checkpoints en Claude Code.

Repasemos los puntos tratados:

Concepto	Funcionamiento / Sintaxis	Detalle de control
Qué es un checkpoint	Copia automática del código previa a la edición	Generada ante cada prompt de usuario; no requiere guardados manuales.
Dónde se guarda	Carpeta ~/.claude/file-history/	Persiste al cerrar la terminal y se borra a los 30 días de inactividad.
Cómo se invoca	Comando /rewind o doble Esc	Abre el menú de restauración si el cuadro de entrada está vacío.
Opciones de restauración	Restore code / Restore conversation	Permite revertir solo el archivo de código, solo el chat, o ambos.
Qué se puede restaurar	Cambios de herramientas de edición	Ediciones en la sesión de chat con herramientas como Edit o Write.
Qué no se puede restaurar	Comandos Bash y cambios externos	Acciones de consola (rm/mv), ediciones fuera de la sesión o llamadas API.
Coordinación con git	Deshacer en local frente a histórico	Los checkpoints son borradores rápidos; git guarda los hitos y protege ante comandos de consola.

Ahora deberías ser capaz de: explicar la mecánica de guardado de los checkpoints, abrir el menú de checkpoints usando comandos o atajos de teclado, seleccionar la opción de restauración adecuada a cada problema, identificar qué cambios son restaurables y cuáles requieren el uso de git, y coordinar ambas herramientas en tu flujo de trabajo para programar con seguridad. Utilizar los checkpoints como borrador de código y git como salvaguarda definitiva te proporcionará un entorno de desarrollo ágil y protegido.

Integra el uso de checkpoints en tus refactorizaciones para agilizar tus desarrollos diarios.

---

En el próximo artículo, 38 "Estructura de plugins", entraremos en el manual de desarrollo de extensiones. Hemos hablado de Skills, Hooks, atajos y MCP a lo largo de la serie. En la siguiente sección explicaremos cómo empaquetar estos recursos en un plugin de Claude Code, detallando el esquema del archivo plugin.json, qué carpetas debe contener y cómo distribuirlo para compartirlo con otros desarrolladores. Piensa en esto: ¿qué utilidades de las que has diseñado te gustaría empaquetar en un único módulo instalable? Lo veremos en el próximo artículo.

---

Lecturas recomendadas

• Ejecución paralela: Iniciar varios agentes a la vez
• Conexión MCP: Conectar Claude con servicios de red
• Integración con VS Code