# Cómo deshacer cambios en Claude Code: /rewind y git > Modos de rewind, limitaciones de los checkpoints, git checkout, stash, reflog y protección contra comandos destructivos. Cinco formas de restaurar un estado. Source: https://ailoot.ai/blog/es/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/es/claude-code-undo-changes/ Language: es Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-b7b37450af4a50af4dc32138cb252887c36f5edf9a1f22af0d1b3a8e876e76b2 [En la documentación encontrarás información práctica sobre cómo trabajar con Ailoot](https://ailoot.ai/docs/). ## ¿Qué significa deshacer en Claude Code y por qué no bastan tres niveles?
Puntos clave Deshacer en Claude Code tiene tres niveles: el comando integrado `/rewind` (recuperación instantánea dentro de una sesión), `git checkout` (restaurar el último commit) y `git reflog` (una red de seguridad para casos catastróficos, por si alguien ejecutó `git reset --hard`). Cada nivel cubre su propia clase de errores y nada más allá de sus límites. Conocer solo `/rewind` te deja en una situación muy comprometida ante el primer error grave.
Activé `/rewind` durante mi primera semana usando Claude Code, cuando rompió la lógica de autenticación de mi proyecto en dos prompts. Hice un rewind, respiré aliviado y seguí trabajando. Un mes después surgió otra situación: estaba escribiendo una migración de esquema, Claude me ayudó, hice commit, cambié de rama y me di cuenta de que había olvidado un paso necesario. `/rewind` no ayudó: la sesión ya era otra. `git checkout` al commit anterior sí ayudó. Un mes más tarde, le dije accidentalmente al agente: «vuelve todo al último push», y ejecutó `git reset --hard`, destruyendo tres horas de trabajo. `git reflog` me salvó: los hashes de los commits destruidos seguían ahí. Esas tres historias muestran tres niveles de protección que funcionan de manera distinta, detectan errores diferentes y son todos necesarios. Esta guía explica cada nivel con sus comandos, limitaciones y ejemplos; también muestra cómo configurar un proyecto de antemano para que Claude no lo eche abajo la primera vez. **3 niveles para deshacer: qué cubre cada uno y cuándo usarlo:** | Nivel | Comando | Cubre | NO cubre | |----|----|----|----| | 1\. Dentro de una sesión | `/rewind` o `Esc Esc` | Archivos modificados por Claude con sus propias herramientas; historial de la conversación | Comandos bash, editores externos, migraciones de bases de datos | | 2\. Antes de un commit | `git checkout .` o `git stash` | Todos los cambios sin confirmar en los archivos | Commits ya confirmados | | 3\. Catástrofe | `git reflog` + `git reset --hard ` | Commits destruidos por `reset --hard` o un force-push | Comandos bash destructivos (rm, migraciones de bases de datos) | A continuación veremos cada nivel: qué hacer exactamente, cuáles son los peligros y cómo configurarlo todo para no tener nada que deshacer porque nada se haya roto. ## ¿Cómo se abre /rewind: con el comando o con Esc-Esc?
Puntos clave Hay dos formas de abrir el menú Rewind en Claude Code. La primera es escribir `/rewind` en el campo de entrada. La segunda es pulsar `Esc` dos veces cuando el campo está vacío. Si hay texto en el campo, la primera doble pulsación de Esc lo borra y guarda su contenido en el historial de entrada; otra doble pulsación abre el menú. El comando `/rewind` tiene como alias `/checkpoint`.
Después de cada respuesta, Claude crea automáticamente una instantánea de todos los archivos que editó en esa sesión. Las instantáneas se guardan en `~/.claude/file-history/{sessionId}/` y se conservan hasta 30 días. Son incrementales: solo se guardan las diferencias entre estados, no el archivo completo. De forma predeterminada, se guardan hasta 100 instantáneas por sesión. Esto significa que, en la mayoría de los proyectos reales, en cualquier momento tienes un historial completo de todos los cambios de Claude durante la jornada de trabajo. Para abrir el menú Rewind, pulsa `Esc` dos veces cuando el campo de entrada esté vacío: ``` [user-input is empty] > _ [press Esc, Esc] Rewind to which message? 1. Create a migration for the User table (3 files changed) 2. Add the lastLoginAt field (1 file changed) 3. Rewrite the authorization logic (5 files changed) ... ``` Si hay texto en el campo de entrada, la primera doble pulsación de `Esc` lo borra y lo guarda en el historial, al que puedes acceder con `Up`. Esto resulta útil cuando ya has empezado a escribir y te das cuenta de que necesitas hacer un rewind. Esta es una cita de la documentación oficial de Anthropic:

«Si hay texto en el campo del prompt, al pulsar Esc dos veces primero se borrará en lugar de abrir el menú. El texto borrado se guarda en el historial de entrada, por lo que puedes restaurarlo con la flecha hacia arriba después del menú de rewind.»

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
El comando `/rewind` hace lo mismo: abre el menú. Existe el alias `/checkpoint`, que lleva al mismo sitio. Qué método te resulta más cómodo depende de la costumbre. Yo uso `Esc Esc`: es más rápido y no tengo que apartar las manos del teclado. ## 6 modos en el menú Rewind: ¿cuál elegir y cuándo?
Puntos clave Después de seleccionar un punto de rewind en el menú Rewind, aparece un segundo menú con seis modos. Tres restauran el estado (`Restore code and conversation`, `Restore conversation`, `Restore code`), dos comprimen el historial (`Summarize from here`, `Summarize up to here`) y uno cancela la acción (`Never mind`). El caso más habitual —«deshacer tanto el código como la conversación»— corresponde a la primera opción.
Elige un punto de la lista y aparecerá el menú de acciones. Seis opciones, cada una con una función diferente. **Tabla completa de los modos:** | Modo | Qué hace | Cuándo elegirlo | |----|----|----| | `Restore code and conversation` | Restaura los archivos y el historial de la conversación al punto seleccionado | El caso más habitual: Claude se desvió y quiero empezar de nuevo con las indicaciones correctas | | `Restore conversation` | Revierte solo el historial de la conversación; los archivos se quedan como están | El código está bien, pero la conversación se desvió; reformularé a partir de este punto y conservaré los cambios actuales | | `Restore code` | Revierte los archivos; la conversación se queda como está | Algunos cambios de Claude eran innecesarios, pero sigo necesitando el contexto de la conversación (por ejemplo, acordamos los siguientes pasos) | | `Summarize from here` | Comprime todo lo que hay DESPUÉS del punto seleccionado en un resumen. No modifica los archivos | Una sesión larga de depuración ha consumido el contexto; necesito liberar espacio sin perder las instrucciones iniciales | | `Summarize up to here` | Comprime todo lo que hay ANTES del punto seleccionado en un resumen. No modifica los archivos | Hubo una larga explicación inicial seguida de una tarea concreta: comprimimos la explicación en un mensaje y dejamos intacto el trabajo reciente | | `Never mind` | Cierra el menú sin hacer cambios | He cambiado de opinión | La función `Summarize up to here` apareció en Claude Code v2.1.139-v2.1.142, publicado del 11 al 15 de mayo de 2026, en la semana 20:

«Puedes comprimir el contexto inicial desde el menú Rewind con “Summarize up to here”.»

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
La diferencia entre `Restore` y `Summarize` es fundamental. Restore vuelve a un estado anterior y deshace todo lo que ocurrió después del punto seleccionado. Summarize no deshace nada: solo comprime. Los mensajes originales permanecen en la transcripción de la sesión como referencia, pero en el contexto activo solo queda el resumen. Usa Restore cuando quieras que sea «como si esto nunca hubiera ocurrido». Usa Summarize cuando quieras «conservarlo, pero sin que ocupe espacio en el contexto». Después de `Restore conversation` o `Summarize from here`, el texto original del prompt seleccionado vuelve al campo de entrada; puedes editarlo y enviarlo de nuevo. Después de `Summarize up to here`, el campo de entrada queda vacío y sigues al final de la conversación. ## ¿Qué cambios no puede deshacer /rewind en Claude Code?
Puntos clave `/rewind` solo registra los cambios que Claude hace con sus propias herramientas de edición de archivos. No puede ver ni restaurar nada más. Hay tres tipos de cambios invisibles: comandos bash (rm, mv, cp), ediciones externas (tus cambios manuales en un IDE, cambios de otras sesiones) y operaciones ajenas a los archivos (migraciones de bases de datos, git push, llamadas a API remotas).
Esta es la principal limitación con la que se encuentra la gente: `/rewind` muestra una marca verde y dice “rewind successful”, pero el proyecto sigue roto porque Claude hizo algo más que modificar archivos. Veamos los tres casos. **1. Los comandos bash no se registran.** Si Claude ejecuta `rm file.txt` o `mv old.txt new.txt` en un turno, esos cambios no se incluyen en el checkpoint. La documentación de Anthropic lo afirma explícitamente:

«Los checkpoints no registran los archivos modificados mediante comandos bash. Por ejemplo, si Claude Code ejecuta rm file.txt, mv old.txt new.txt o cp source.txt dest.txt, esos cambios en los archivos no se pueden deshacer con rewind.»

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Esto significa que si Claude elimina, mueve o copia un archivo por su cuenta mediante la herramienta bash, `/rewind` no lo restaurará todo. `git checkout` o restaurar desde una copia de seguridad pueden ayudar, pero requieren algo más que pulsar dos teclas. **2. No se registran las ediciones externas.** Si abres manualmente un archivo en VS Code y lo editas, o una segunda sesión de Claude modifica los mismos archivos en paralelo, la primera sesión no puede ver esos cambios. Se crea una instantánea del checkpoint cuando Claude termina un turno en la sesión actual. Lo que ocurre entre turnos queda fuera de su responsabilidad. **3. Las operaciones ajenas a los archivos no están cubiertas en absoluto.** Una migración de Prisma aplicada con `npx prisma migrate dev` ha cambiado el esquema de la base de datos; `/rewind` no la deshará porque la base de datos está fuera del sistema de archivos del proyecto. Un force-push a `origin/main` es lo mismo: el commit llegó al servidor remoto y el checkpoint no lo recuperará. Una llamada a una API remota que haya cobrado dinero o eliminado un registro solo puede deshacerse mediante los mecanismos propios de la API. **Regla:** Si una tarea afecta a algo fuera de los archivos del proyecto —migraciones de bases de datos, git push, API remotas—, prepara una estrategia de reversión independiente para cada efecto externo. `/rewind` solo cubre el historial de archivos locales de la sesión actual. ## /rewind y git: ¿en qué se diferencian y por qué necesitas ambos?
Puntos clave `/rewind` es una reversión local dentro de una sola sesión de Claude Code. Guarda instantáneas incrementales durante un máximo de 30 días, hasta 100 por sesión. git es el historial del proyecto a largo plazo, compartido por el equipo, con ramas, conflictos de fusión y un repositorio remoto. Uno no sustituye al otro. La mejor práctica es hacer un `git commit` en cada hito lógico y recurrir a `/rewind` entre commits.
La documentación de Anthropic describe directamente esta combinación:

«Los checkpoints están diseñados para una recuperación rápida a nivel de sesión. Para los commits, las ramas y el historial a largo plazo, sigue usando un sistema de control de versiones (por ejemplo, Git). Los checkpoints complementan el control de versiones habitual, pero no lo sustituyen. Piensa en los checkpoints como “deshacer local” y en Git como “historial permanente”.»

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Las diferencias, en una tabla: | Parámetro | /rewind | git | |----|----|----| | Granularidad | Cada turno de la conversación | Cada commit | | Almacenamiento | Hasta 30 días, un máximo de 100 por sesión, localmente en `~/.claude/file-history/` | Permanente, en `.git/` del repositorio y en el servidor remoto | | Qué registra | Las modificaciones de Claude mediante sus propias herramientas | Todos los cambios confirmados | | Qué NO registra | Bash, ediciones externas, migraciones, push | Cambios sin confirmar | | Comando | Un comando dentro de Claude | Un sistema de control de versiones externo | | Revierte la conversación | Sí | No | | Funciona entre sesiones | Solo dentro de la misma sesión | En todas partes | La combinación es sencilla: cada vez que llegues a un estado en el que «esto funciona y no quiero perderlo», haz un `git commit`. Entre commits, recurre a `/rewind`: es instantáneo, no requiere un mensaje de commit y no llena el historial de git con estados intermedios. Cuando termines el trabajo, haz un commit; preferiblemente, uno significativo y atómico. ## ¿Por qué un solo /rewind no cubre toda la tarea? Deshacer es un caso de **Context Engineering**. Si gestionas el contexto de la sesión (cuándo hacer commit, cuándo pulsar `/rewind`, qué reglas poner en `CLAUDE.md`), obtendrás un Claude predecible que no destruye el proyecto ni pierde trabajo. ## ¿Por qué es peligroso `git reset --hard` cuando pides a Claude que «vuelva atrás»?
Puntos clave En lenguaje natural, «volver atrás» significa «consultar el historial», no «destruirlo»; Claude debería ofrecer `git checkout` de forma predeterminada, no `reset --hard`; la protección se configura en CLAUDE.md.
Una petición de «guardar el estado actual y volver al último push» puede dar lugar a estos comandos: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` El primer comando era correcto: guardó los cambios sin confirmar en el stash. El segundo fue destructivo: reescribió la rama para situarla en el commit `35eb731`, y todos los commits entre este y `882e618` quedaron huérfanos. De forma predeterminada, los commits huérfanos permanecen en `.git/objects/` hasta que se ejecuta `git gc`, lo que suele ocurrir automáticamente en un plazo de dos semanas. Pero si en ese momento no sabías qué hacer, el tiempo ya jugaba en tu contra. La lógica es sencilla: en lenguaje natural, «volver atrás», «retroceder», «restaurar», «revertir» y «deshacer» significan «consultar el historial» o «volver a un lugar seguro». No significan «destruir el historial». El comando `git reset --hard` lo destruye: reescribe la rama y elimina los commits del conjunto de los que son accesibles desde HEAD. Una alternativa segura es `git checkout `, que crea un HEAD separado y permite consultar el estado anterior sin tocar las ramas. La principal recomendación práctica es hacer un `git commit` del estado actual antes de cualquier tarea importante, sobre todo antes de refactorizar varios archivos. Un commit convierte cualquier metedura de pata de Claude en un único comando `git checkout .` sin perder trabajo. ## ¿Cómo te salva git reflog después de un reset destructivo?
Puntos clave `git reflog` muestra el historial local de todos los movimientos de HEAD en el repositorio, incluso los commits eliminados mediante `git reset --hard` o un force-push. De forma predeterminada, cada movimiento se guarda durante 90 días. Si Claude (o tú, o cualquier otra persona) destruyó commits con un comando destructivo, `git reflog` mostrará sus hashes y podrás restaurar la rama con `git reset --hard `.
Después de un reset destructivo, ejecuta `git reflog` de inmediato: ```bash git reflog ``` La salida tiene este aspecto: ``` 35eb731 HEAD@{0}: reset: moving to 35eb731 882e618 HEAD@{1}: commit: middleware refactoring complete d63695e HEAD@{2}: commit: leaveRemove method finalized 1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled 35eb731 HEAD@{4}: pull origin main ``` `HEAD@{1}` hasta `HEAD@{3}` son precisamente esos commits «destruidos». No han desaparecido del almacén local de objetos de git; simplemente han dejado de ser accesibles a través de la rama. Para restaurarlos: ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Después, la rama volverá a contener todo el historial hasta la catástrofe. **Limitaciones de Reflog:** 1. **Solo local.** El reflog se guarda en `.git/logs/HEAD`; no está en el repositorio remoto. Si haces un force-push y luego eliminas la copia local del repositorio, el reflog desaparecerá junto con la carpeta. 2. **90 días de forma predeterminada.** Las entradas más antiguas pueden ser eliminadas por git gc. Puedes configurar el plazo con `git config gc.reflogExpire 200.days.ago`. 3. **No cubre lo que nunca estuvo en HEAD.** Si un commit solo estaba en el stash y este se destruyó, el reflog solo mostrará el último estado del stash, no su historial interno. **Regla para el equipo:** no ejecutes nunca `git gc --aggressive` justo después de una catástrofe. Primero investiga con reflog y recupera el trabajo; después haz lo demás. Y no elimines el clon local del repositorio hasta tener la certeza de que se ha subido todo lo que necesitas. ## ¿Cómo proteger un proyecto frente a comandos git destructivos mediante CLAUDE.md?
Puntos clave Añade al `CLAUDE.md` de tu proyecto un bloque de instrucciones que defina qué comandos git puede ejecutar Claude por su cuenta, cuáles requieren confirmación explícita y cuáles están prohibidos sin que el usuario pronuncie una frase exacta. Claude trata CLAUDE.md como el prompt del sistema del proyecto y sigue estas reglas de forma predeterminada. Así, un prompt «peligroso» se convierte en dos comandos seguros.
La vulnerabilidad es que Claude no dispone de contexto protector de forma predeterminada. Interpreta «volver atrás» como `git reset --hard` porque, técnicamente, es un método válido. Añade la protección a `CLAUDE.md`, el archivo del prompt del sistema del proyecto. **Regla mínima** (añádela a tu `CLAUDE.md`): ```markdown ## Git Safety Protocol - NUNCA ejecutes comandos git destructivos (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), salvo que solicite explícitamente esas acciones. Tomar medidas destructivas sin autorización no es útil y puede ocasionar la pérdida de trabajo. - Cuando diga «roll back», «go back», «restore», «revert» o «undo», interprétalo como comandos de REVISIÓN: usa `git log`, `git diff`, `git checkout ` (crea un HEAD separado) o `git stash` (conserva los cambios). - PIDE SIEMPRE confirmación antes de CUALQUIER comando que: - Cambie la posición de HEAD a otro commit de una rama - Modifique el historial de commits - Pueda hacer que se pierda trabajo sin confirmar - Incluya las opciones --hard, --force, --aggressive - Antes de cualquier comando destructivo, presenta una comparación numerada: - SEGURO: usar `git checkout ` para consultar temporalmente el estado - DESTRUCTIVO: usar `git reset --hard` para destruirlo de forma permanente - Espera a que elija explícitamente antes de ejecutarlo. ``` **Regla ampliada** para el equipo (añádela al `CLAUDE.md` de la raíz del repositorio): ```markdown ## Git Workflow Rules - Haz un commit en cada hito funcional. Antes de un commit WIP, ejecuta `git status` y `git diff`, prepara solo archivos revisados expresamente por nombre con `git add -- path/to/file` y revisa el diff preparado antes de confirmar. Un temporizador recuerda revisar; no autoriza preparar todo el árbol de trabajo. - Claude nunca debe usar `git add .` ni `git add -A` para sus commits. Especifica los archivos por nombre solo después de `git status` + `git diff`. - Antes de hacer `git push --force` a main, detente y pregúntame. En ramas de funcionalidades, haz force-push con prudencia y solo si tienes la certeza de que estoy dispuesto a perder la versión anterior. - Al resolver conflictos de fusión, no elijas «ours» ni «theirs» de inmediato: enséñame primero ambas versiones y luego decidiré. - `.gitignore` debe contener `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. Si faltan, añádelas. ``` Después de añadir estos bloques, la siguiente frase «vuelve al último push» daría lugar a esta respuesta: > Veo 3 archivos sin confirmar y 4 commits desde el último push. Hay dos opciones: > > 1. SEGURA: crear una rama `view-last-push` con `git checkout `; conservaré todo el trabajo, pero mostraré temporalmente el estado del push. > 2. DESTRUCTIVA: `git reset --hard `; destruiré permanentemente 4 commits y los cambios sin confirmar. Solo se podrán restaurar mediante `git reflog` durante los próximos 90 días. ¿Cuál eliges? Eso supone medio minuto de conversación en vez de cuatro horas de trabajo perdido. ## ¿Cuáles son las 5 formas de deshacer en Claude Code y cómo elegir la adecuada?
Puntos clave Si algo sale mal, hay cinco niveles de gravedad: `/rewind` (dentro de una sesión), `git checkout .` (cambios sin confirmar), `git checkout ` (volver a un commit anterior sin perder el historial), `git reset --hard ` (retroceder la rama y perder los commits posteriores), `git reflog` + recuperación (catástrofe, todo ha desaparecido). Cada nivel es más drástico y peligroso que el anterior.
El escenario «Claude lo rompió, necesito restaurarlo urgentemente» avanza de abajo arriba por esta escalera. Empieza siempre por el nivel 1. **Nivel 1. `/rewind`: deshacer al instante dentro de una sesión.** Pulsa `Esc Esc` o escribe `/rewind`. Elige el punto anterior al problema. Elige un modo (normalmente `Restore code and conversation`). Un segundo después estarás de vuelta en el pasado y podrás empezar de nuevo. Cubre el 80 % de los casos en que «Claude hizo algo mal». **Nivel 2. `git checkout .`: deshacer todos los cambios sin confirmar.** ```bash git diff # first see what actually changed git checkout . # undo all uncommitted changes in all files # or selectively: git checkout -- path/to/file.ts # only one file ``` Útil cuando `/rewind` no ha funcionado (por ejemplo, porque Claude tocó los archivos mediante bash) o cuando necesitas deshacer algo fuera del historial de la sesión. Todos los cambios que no se hayan confirmado desaparecerán permanentemente. Si podrías arrepentirte, ejecuta primero `git stash` (consulta el nivel 2.5). **Nivel 2.5. `git stash`: dejar los cambios a buen recaudo.** ```bash git stash save "might still need this" # return to a clean state (without changes) # ... # if you change your mind—restore from stash: git stash pop ``` Un buen término medio entre «perderlo para siempre» y «dejarlo como está». El stash permanece en local hasta que se borra expresamente. **Nivel 3. `git checkout `: volver a un commit anterior sin perder el historial.** ```bash git log --oneline # find the hash of the right commit, e.g. abc1234 git checkout abc1234 # detached HEAD—view without changing anything # like the state? create a branch from it: git checkout -b recovery abc1234 # return: git checkout main ``` Es una «vuelta temporal» segura. Un HEAD separado no modifica la rama; tu trabajo actual en `main` (o en la rama en la que estuvieras) sigue intacto. Si quieres trabajar con ese estado, crea una rama. **Nivel 4. `git reset --hard `: mover la rama a un punto anterior.** ⚠️ Destructivo. Los commits posteriores al hash indicado quedan huérfanos. ```bash git reflog # note the hash of the current state git reset --hard abc1234 # rewrite the branch # found a mistake? return through reflog: git reset --hard HEAD@{1} # to where you were before the reset ``` Úsalo solo si estás seguro de que no necesitas los commits posteriores. Y consulta siempre `git reflog` ANTES del reset para saber a qué estado volver si cambias de opinión. **Nivel 5. `git reflog` + recuperación: escenario catastrófico.** Alguien (Claude, tú, un compañero) ya ha ejecutado `git reset --hard` o un force-push y ha borrado el trabajo. ¿Qué haces? ```bash git reflog # look for the last hash before the disaster git branch recovered HEAD@{N} # create a branch from it git checkout recovered # switch to it git diff main # compare with the current state git checkout main && git merge recovered # restore into main, if you're sure ``` Si el reflog ya se ha borrado (de forma predeterminada, después de 90 días), el último recurso es `git fsck --lost-found`, que mostrará los commits colgantes de `.git/objects/`. Es casi arqueología, pero a veces funciona. **Regla para elegir un nivel:** | Qué ha ocurrido | Nivel | |-----------------------------------------------|-----------------------------| | Claude reescribió 3 archivos de forma incorrecta | 1\. `/rewind` | | Lo probé, no me gustó y la sesión no está ayudando | 2\. `git checkout .` | | Lo estropeé manualmente, no quiero perderlo y quizá lo restaure | 2.5. `git stash` | | Hice un commit y necesito retroceder un commit | 3\. `git checkout ` | | Estoy seguro de que no necesito los commits posteriores | 4\. `git reset --hard` | | Ya lo borré con un comando destructivo | 5\. `git reflog` | ## ¿Cómo proteger un proyecto para no tener que deshacer nada?
Puntos clave La mejor forma de deshacer es no tener que hacerlo. Tres reglas de protección: revisar el progreso cada 30 minutos y confirmar un hito funcional preparando expresamente solo rutas revisadas; incluir en `.gitignore` las líneas necesarias `.claude/personal/` y `.env*`; hacer los experimentos importantes en una rama aparte con `git checkout -b experiment-`. Esto reduce la pérdida recuperable en archivos confirmados; los sistemas externos y el trabajo sin commit necesitan su propio plan de recuperación.
**Regla 1. Haz commit cada 30 minutos.** No esperes a que «la tarea esté terminada». Confirma cualquier paso intermedio que funcione. Los mensajes de commit pueden ser cualquiera; lo importante es que Claude (o tú) pueda volver a un estado funcional con un solo comando `git checkout`. ```bash # at the beginning of a task git status # inspect all staged and unstaged paths git diff # review the changes # Replace this example path with the actual file you reviewed. git add -- path/to/file.ts git diff --cached # verify exactly what will be committed git commit -m "wip: starting User schema migration" # after 30 minutes (or after the first working iteration) git status git diff git add -- path/to/file.ts # actual reviewed path, not a directory wildcard git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # at the end of the task—a meaningful commit git reset --soft HEAD~2 # combine the three wip commits into one git commit -m "feat(auth): add lastLoginAt field to User table" ``` Si añades un recordatorio PostToolUse, conserva la revisión y la preparación por rutas explícitas. No conviertas el temporizador en commits automáticos sin comprobar: podrían incluir ediciones ajenas o archivos ya preparados. **Regla 2. `.gitignore` mínimo.** Estas líneas son necesarias en la raíz del proyecto: ```gitignore # secrets .env .env.local .env.*.local # local Claude Code settings (not pushed to the team repository) .claude/personal/ .claude/sessions/ .claude/file-history/ # dependencies and build node_modules/ dist/ .next/ build/ ``` Uso la carpeta `.claude/personal/` para mis propios experimentos y notas, que no deben incluirse en el repositorio compartido. Las carpetas `.claude/sessions/` y `.claude/file-history/` son el almacenamiento local de Claude Code: no deben estar en el repositorio, ocupan mucho espacio y están vinculadas a una máquina concreta. **Regla 3. Haz los experimentos en una rama aparte.** Si la tarea es grande (refactorizar 10+ archivos, migrar a una base de datos nueva, reescribir un módulo), no la hagas en la rama principal: ```bash git checkout -b experiment/auth-rewrite # work, commit every 30 minutes # if it works: git checkout main git merge experiment/auth-rewrite # if it doesn't: git checkout main git branch -D experiment/auth-rewrite # delete the branch # that's it, the main branch is intact ``` Este sencillo hábito convierte «Claude destrozó el proyecto» en «Claude destrozó una rama, la borré y volvemos a empezar». **Regla 4. Antes de operaciones peligrosas, usa `git tag`.** Antes de una migración de base de datos, una refactorización grande o una actualización de dependencias, crea una etiqueta: ```bash git tag pre-prisma-migration-v2 # work # something went wrong: git reset --hard pre-prisma-migration-v2 # or just take a look: git checkout pre-prisma-migration-v2 ``` Una etiqueta es un puntero con nombre a un commit que no perderás ni siquiera cuando se limpie el reflog. ## ¿Qué sigue? ¿Cómo encaja deshacer en el Context Engineering?
Puntos clave Deshacer no es una habilidad independiente, sino parte de la gestión del contexto de la sesión de Claude Code. Cuando sabes cuándo pulsar `/rewind`, cuándo hacer `git commit` y cuándo usar `git stash`, estás gestionando todo un flujo de trabajo, no un solo comando. Esto forma parte del **Context Engineering**. Sin él, Claude actúa como un asistente corriente; con él, como una herramienta predecible.
Estos tres niveles para deshacer son la infraestructura de una habilidad: saber restaurar un estado cuando algo se rompe. Esa habilidad, por sí sola, es limitada. Pero al combinarla con otras herramientas de Context Engineering, se convierte en algo más. El Plan Mode no te permite escribir código de inmediato: primero viene el plan, luego la confirmación y, por último, la ejecución. Es una forma preventiva de deshacer: no escribes algo que después tendrás que deshacer porque el plan se revisó de antemano. Lee más en la guía sobre [Plan Mode en Claude Code](https://ailoot.ai/blog/es/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/es/claude-md-template/) establece reglas que Claude respeta de forma predeterminada, incluido el Git Safety Protocol que vimos antes. Es una protección preventiva contra los comandos destructivos. El [Second Brain](https://ailoot.ai/blog/es/claude-code-second-brain/) le da a Claude memoria del proyecto entre sesiones: sabe qué código tienes, cuál es la lógica de negocio y qué acuerdos se alcanzaron anteriormente. Cuanta más memoria tiene, menos probable es que haga algo incorrecto. [Skills y subagents](https://ailoot.ai/blog/es/claude-code-skills-library/) son tu metodología expresada en código. Si el flujo de trabajo git correcto está integrado en un Skill, ningún subagent ejecutará `git reset --hard` sin confirmación. Todo esto, en conjunto, es **Context Engineering**. Gestiona el contexto antes del prompt, no durante. Lee más en [qué es Context Engineering](https://ailoot.ai/blog/es/context-engineering/). Deshacer es la última línea de defensa. Plan Mode + CLAUDE.md + Second Brain + Skills son las cuatro primeras. Cuando están configuradas, deshacer es algo poco frecuente y rápido. Cuando no lo están, se convierte en un ritual diario.
### Fuentes - [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new) - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
Deshacer empieza donde termina la planificación. [Abrir Ailoot](https://ailoot.ai/). ## Preguntas sobre Claude Code ### ¿Un punto de control WIP debe usar git add .? No. Ejecuta `git status` y `git diff`, prepara solo los archivos revisados por nombre e inspecciona `git diff --cached` antes del commit. Un recordatorio periódico no autoriza incluir cambios ajenos ni archivos preparados previamente. ### ¿/rewind deshace una migración de base de datos o una acción API remota? No. La guía limita los puntos de control a ediciones de archivos admitidas de la sesión. Los efectos en base de datos, Git remoto y API necesitan recuperación separada; utiliza Git o una copia para archivos fuera de esa cobertura. ## Ailoot · La empresa y su cartera de proyectos Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI. La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes. Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.