Claude Code rewind: deshacer cambios sin tocar git

Le pides a Claude Code que refactorice el servicio de pagos. Tarda cuatro minutos. Toca nueve archivos. Los tests pasan, pero el diseño no te convence: ha metido una capa de abstracción que nadie pidió.

Puedes hacer git checkout . y perder también el arreglo que hiciste a mano y no habías commiteado. O pedirle al agente "deshaz lo que acabas de hacer" y rezar para que se acuerde de los nueve archivos.

Hay una tercera opción: Claude Code rewind. Pulsas Esc dos veces y vuelves al punto exacto antes de ese prompt. Sin tocar git.

El problema es que funciona tan bien en el caso fácil que te hace confiar en él en el caso difícil. Y ahí no deberías.

En corto: Claude Code rewind (/rewind, o Esc dos veces con el prompt vacío) devuelve el código y/o la conversación de Claude Code al estado anterior a cualquier prompt de la sesión. No rastrea lo que el agente cambia con comandos Bash ni la mayoría de ediciones de subagentes, y los snapshots caducan a los ~30 días. Úsalo para explorar; usa git para todo lo que importa.

¿Qué es /rewind en Claude Code?

/rewind es el comando de Claude Code que restaura el código, la conversación o ambos al checkpoint que la herramienta guarda automáticamente antes de cada prompt que inicia un turno.

Un checkpoint es una foto de los archivos que Claude ha editado con sus propias herramientas. No es un commit ni un stash: lo gestiona Claude Code por sesión, fuera de tu repositorio.

/rewind llegó con Claude Code 2.0.0, según el changelog oficial, y sigue recibiendo arreglos: la versión 2.1.290 corrigió que el menú no listara un prompt enviado mientras Claude seguía trabajando.

Para abrir el menú tienes dos caminos, según la documentación oficial de checkpointing (consultada el 10 de octubre de 2026):

• Escribir /rewind.
• Pulsar Esc dos veces con el campo de prompt vacío. Si hay texto, el doble Esc lo borra en lugar de abrir el menú. El texto borrado queda en el historial: lo recuperas con la flecha arriba.

El menú lista los prompts que enviaste. Eliges uno y decides qué hacer.

Checkpoints en Claude Code: qué guardan y qué no

Los checkpoints de Claude Code se crean solos y se guardan con la conversación, así que puedes hacer /rewind incluso después de retomar una sesión. Estas son las cifras de la documentación a 10 de octubre de 2026:

Aspecto	Comportamiento documentado
Cuándo se crea un checkpoint	Antes de cada prompt que inicia un turno
Cuántos conserva con archivos	Los snapshots de los 100 checkpoints más recientes de la sesión
Cuánto duran	Por defecto, unos 30 días tras el último snapshot de la sesión (configurable con cleanupPeriodDays)
Restore code and conversation	Vuelven código y conversación a ese punto
Restore conversation	Rebobina la conversación y deja el código como está
Restore code	Revierte los archivos y mantiene la conversación
Summarize from here / up to here	Comprime parte de la conversación para liberar contexto; no toca archivos
Qué NO rastrea	Cambios con Bash (rm, mv, cp), cambios externos a la sesión, la mayoría de ediciones de subagentes, symlinks y hard links

Las opciones de restaurar código solo aparecen si ese checkpoint tiene cambios rastreados. Si el menú no ofrece ninguna opción de restaurar código, Claude no editó nada con sus herramientas desde ese punto. O lo hizo por Bash o con un subagente, que es peor.

Al restaurar la conversación, el prompt original vuelve al campo de entrada para reenviarlo o reescribirlo.

Claude Code rewind vs git stash, commit y worktree

La documentación lo dice en su apartado Not a replacement for version control: los checkpoints son para recuperación rápida dentro de la sesión; para el historial permanente, git. La pregunta útil es qué herramienta usar en cada momento.

Criterio	/rewind	git stash	git commit	git worktree
Para qué sirve	Deshacer el último intento del agente	Aparcar cambios un rato	Fijar un estado que importa	Trabajar en paralelo en otra carpeta
Rebobina la conversación	Sí	No	No	No
Captura cambios hechos con Bash	No	Sí	Sí	Sí (aislados en su carpeta)
Persistencia	~30 días por defecto, por sesión	Hasta que lo borres	Permanente	Mientras exista la rama
Compartible con el equipo	No	No	Sí	Sí, vía rama
Limitación o riesgo	Huecos silenciosos: Bash, subagentes, symlinks	Los stash se olvidan y se acumulan	Ensucia el historial si commiteas cada intento	Más disco y más contexto que gestionar

Mi regla: si un estado del código me costaría más de cinco minutos reconstruirlo, va a un commit. Lo que hay entre commits es terreno de /rewind.

Si trabajas con varios agentes a la vez, el worktree deja de ser opcional. Lo explico en cómo dirigir agentes de IA en paralelo sin que se pisen: rewind no aísla nada entre sesiones, git worktree sí.

Cómo probar dos enfoques con Claude Code rewind

Para comparar dos enfoques con /rewind: fija un commit de partida, lanza el enfoque A, guarda su diff en un parche, rebobina código y conversación, lanza el B y decide con git. Un caso típico: quieres añadir caché a un endpoint, dudas entre memoria o Redis y quieres ver los dos antes de decidir.

1. Fija el punto de partida en git.

git add -A && git commit -m "wip: antes de probar caché"

Los tests y el npm install que lance el agente corren por Bash, y eso no lo rebobina /rewind.

2. Lanza el enfoque A.

Añade caché en memoria con TTL de 60 s al endpoint GET /products.
No toques otros endpoints. Ejecuta los tests al terminar.

Revisa el diff y los tests.

3. Guarda el resultado antes de rebobinar. Si rebobinas, el enfoque A desaparece. Sácalo a un parche, incluidos los archivos nuevos que haya creado el agente (git diff a secas los ignora):

git add -A
git diff --cached > /tmp/enfoque-a.patch
git reset -q

4. Rebobina código y conversación. Esc Esc → prompt del enfoque A → Restore code and conversation. El código vuelve atrás, el prompt reaparece en la entrada y el agente ya no arrastra en su contexto el razonamiento del enfoque A.

5. Edita el prompt y lanza el enfoque B.

Añade caché con Redis (cliente ya instalado en src/infra/redis.ts)
y TTL de 60 s al endpoint GET /products. Ejecuta los tests al terminar.

6. Decide y cierra con git. Si gana B, commit. Si gana A, rebobina otra vez y aplica git apply /tmp/enfoque-a.patch. Después, git status para comprobar que no quedan archivos huérfanos creados por Bash.

Si prefieres conservar la sesión original intacta, la documentación recomienda /branch o claude --continue --fork-session, que bifurcan la conversación en lugar de rebobinarla.

Si quieres practicar este ciclo de explorar barato y consolidar en git sobre un producto real, el curso Construye con IA: de la idea al producto con Claude Code recorre el camino completo.

Cuándo NO fiarte de Claude Code rewind

Claude Code rewind deja huecos en cinco situaciones que reconoce la documentación, y en una más que reportan los usuarios.

Cuando el agente usa Bash. Si Claude ejecuta rm, mv, cp, un script que genera archivos o un formateador, nada de eso entra en el checkpoint. Rebobinas y te quedan archivos borrados o movidos. Es el hueco más peligroso, porque el agente usa Bash constantemente.

Cuando trabajan subagentes. Sus ediciones normalmente no entran en tus checkpoints. La excepción documentada es un skill con context: fork en primer plano. Para el resto, incluido un fork en segundo plano (el valor por defecto), la documentación dice: usa git.

Cuando pasa el tiempo. Los snapshots se borran por defecto a los ~30 días. Si vuelves a un checkpoint sin snapshots, el restore puede fallar con No files were restored. Rewind no es historial; es memoria de corto plazo.

Symlinks, hard links y cambios externos. Los enlaces se saltan con el aviso Restored the code, but skipped N files (ojo con pnpm, que usa hard links), y tus cambios manuales o los de otra sesión normalmente no se rastrean.

Cuando escribes mientras Claude trabaja. Un mensaje encolado que entra en el turno en curso se suma a ese turno y no crea checkpoint propio. Para deshacer lo que Claude hizo después de ese mensaje, tienes que rebobinar al prompt que abrió el turno, y eso deshace el turno entero.

Y luego está lo que no sale en la documentación. En el issue #14002 de anthropics/claude-code, abierto en diciembre de 2025 y todavía abierto a 10 de octubre de 2026, un usuario reporta que la opción "Restore code" aparece de forma intermitente y que a veces solo se restauran algunos archivos, aunque Claude los editó con sus propias herramientas. Sus logs muestran snapshots creados "tracking 0 files".

Tratar una red de seguridad de sesión como control de versiones es uno más de los errores comunes al adoptar Claude Code.

Cómo deshacer cambios en Claude Code sin perder trabajo

Commit antes de explorar, /rewind mientras exploras, git status después de rebobinar. Hoy puedes hacer dos cosas:

1. Hacer un commit wip antes de cada prompt que vaya a tocar más de dos o tres archivos.
2. Tras cada rewind, git status y git diff. Lo que no esperabas, lo creó Bash.

El flujo de trabajo diario completo está en cómo usar Claude Code a diario.

Rewind te deja equivocarte barato. Git te deja equivocarte sin consecuencias. Y la mejor forma de equivocarse menos es decidir qué quieres antes de pedírselo al agente: es la idea central del libro Spec-Driven Development. Con una spec clara, rebobinas menos.

Preguntas frecuentes

¿Cómo abro /rewind en Claude Code?

Escribe /rewind o pulsa Esc dos veces con el campo de prompt vacío. Si hay texto, el doble Esc primero lo borra.

¿/rewind sustituye a git?

No. La documentación oficial lo indica: los checkpoints son para recuperación rápida dentro de la sesión; para historial permanente y colaboración, git. Además, no rastrean cambios hechos con Bash.

¿Por qué /rewind no restaura un archivo que borró Claude?

Porque probablemente lo borró con rm por Bash, y los checkpoints solo rastrean las herramientas de edición de Claude. Recupéralo con git restore <archivo> si estaba commiteado.

¿Cuánto tiempo se guardan los checkpoints de Claude Code?

Se conservan los snapshots de los 100 checkpoints más recientes de cada sesión, y se borran por defecto a los ~30 días. El plazo se amplía con cleanupPeriodDays.

¿/rewind deshace los cambios de los subagentes?

Normalmente no. Solo se restauran los de un skill con context: fork en primer plano. Para el resto, la documentación recomienda revertir con git.

¿Qué diferencia hay entre "Restore conversation" y "Restore code"?

"Restore conversation" rebobina el chat y deja los archivos. "Restore code" revierte los archivos y mantiene el chat. "Restore code and conversation" hace ambas, ideal para probar otro enfoque desde cero.

---

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.