Usar Claude Code de forma segura: modos de permiso, checkpoints y secretos

01Antes de trabajar: revisar carpeta, secretos y medios de recuperación

El uso seguro empieza antes de enviar el prompt. Primero comprueba que la terminal se encuentra en la carpeta correcta y, si estás practicando, usa una carpeta separada del repositorio de trabajo real. Si el proyecto contiene archivos sensibles como `.env`, certificados o material personal, revisa primero qué información quedará accesible para la herramienta de IA. Aunque el ejemplo parezca necesitar una clave API, usa únicamente un valor obviamente ficticio como `sk-EXAMPLE-NOT-REAL`, nunca una clave real.

Comprobaciones antes de empezar
- ¿La carpeta actual corresponde al proyecto que pretendo usar?
- ¿Los archivos de ejemplo están libres de datos personales reales, contraseñas y claves API?
- ¿He revisado con git el estado anterior al cambio o he hecho un commit si era necesario?
- Si es una tarea nueva para mí, ¿empiezo con un flujo centrado en la revisión, como plan o Manual?

La existencia de checkpoints en Claude Code no elimina la necesidad de un control de versiones independiente. La documentación oficial indica expresamente que los checkpoints no sustituyen a un sistema como git. En proyectos importantes, mantén prácticas normales de control de versiones, como hacer un commit antes del trabajo o usar una rama separada.

02Modos de permiso: distinguir el nivel de automatización y los puntos de revisión humana

Los modos de permiso descritos en la documentación oficial son Manual, acceptEdits, plan, auto, dontAsk y bypassPermissions. Worknote recomienda a las personas principiantes empezar con Manual o plan. Esto no significa que el riesgo desaparezca; es una elección orientada a crear el hábito de leer primero el alcance de los cambios y decidir conscientemente.

El modo inicial predeterminado varía según el plan. En la documentación oficial revisada el 2026-09-22, el modo inicial predeterminado de la terminal interactiva para los planes Pro, Max y Team se describe como auto, mientras que para otros planes es Manual. Por tanto, no supongas que siempre aparecerá el mismo flujo de aprobación y comprueba el modo actual.

claude --permission-mode plan

03Durante el trabajo: entender archivos y comandos antes de aprobar

Claude Code puede leer por sí mismo los archivos necesarios y solicitar aprobación antes de modificar archivos o ejecutar comandos. Sin embargo, que aparezca una ventana de aprobación no garantiza por sí solo que el comando sea seguro. Lee primero qué archivos cambiarán, si se incluyen operaciones de eliminación, movimiento o copia, y si aparece alguna instalación o ampliación de alcance que no pediste.

Antes de cambiar nada, dime únicamente lo siguiente.
1. Los nombres de los archivos que modificarás
2. Qué cambiarás en cada archivo
3. Los comandos de shell que pretendes ejecutar
4. Si existe alguna operación que elimine, mueva o sobrescriba archivos originales
Todavía no modifiques archivos ni ejecutes comandos.

• Si se seleccionan más archivos de los solicitados, preguntar la razón.
• Para comandos como rm, mv o cp que cambian directamente el estado de los archivos, volver a revisar la ruta de destino.
• Si aparece un comando de instalación, comprobar si realmente es necesario para los requisitos.
• Si aparecen cambios distintos de los esperados, detener la aprobación y volver a plan.
• Eliminar los valores reales para evitar que información sensible entre en prompts, archivos o registros.

04Checkpoints: conocer con precisión el alcance de la restauración

Claude Code crea un checkpoint automático con cada prompt que envías. Puedes abrir el menú de restauración con `/rewind` o pulsando Esc dos veces cuando el cuadro de entrada está vacío, y elegir opciones como restaurar código y conversación, solo la conversación, solo el código o un resumen. Sin embargo, esta función no registra todos los cambios de archivos.

/rewind

En particular, no debes esperar que `/rewind` restaure por completo los archivos eliminados o movidos mediante comandos de shell. Considera los checkpoints como una ayuda para revertir trabajo dentro de Claude Code y gestiona el historial del proyecto y la recuperación mediante herramientas independientes como git.

05Separar secretos y datos reales de los ejemplos de práctica

No introduzcas contraseñas, claves API, información real de clientes ni datos reales de investigación en prompts o archivos de ejemplo simplemente porque el código parezca necesitarlos. En tutoriales y reproducciones de errores, usa datos sintéticos y tokens claramente ficticios. En un proyecto real, comprueba por separado qué datos pueden proporcionarse a la herramienta según la política de la organización y el entorno de uso.

Valor ficticio para practicar:
API_KEY=sk-EXAMPLE-NOT-REAL

Datos ficticios:
date,category,amount
2026-09-01,food,12000

Si el proyecto ya contiene información sensible, no supongas que basta con pedir «no mires ese archivo». Revisa el alcance de archivos a los que puede acceder la herramienta y la política de seguridad; si es necesario, reproduce el problema en una copia de trabajo de la que se haya eliminado la información sensible.

06Después del trabajo: basarse en el diff real y la ejecución, no solo en la explicación

Después de terminar el trabajo, juzga el resultado por los archivos reales y la ejecución, no por que la IA diga que «ha terminado». Como en el artículo anterior, lee git diff, vuelve a ejecutar los comandos y compara con los valores esperados. Si se trata de una corrección de error, no compruebes solo que el problema desaparezca: verifica también que la entrada que antes funcionaba correctamente siga produciendo el mismo resultado.

Comprobaciones después del trabajo
- ¿Solo cambiaron en git diff los archivos esperados?
- ¿El resultado de ejecución coincide con los valores esperados de los requisitos?
- ¿No quedan archivos temporales ni secretos ficticios entre los elementos que se van a confirmar?
- ¿Quedan registrados el motivo del cambio y la forma de ejecutarlo para que otra persona pueda entenderlo?

Las explicaciones en lenguaje natural de Claude Code son material de apoyo para la revisión. La decisión final se toma comparando con el diff real, los resultados de ejecución y las reglas del proyecto. Este principio puede mantenerse aunque cambie el modelo o el modo de permiso.

07Resultado final: lista de seguridad antes, durante y después del trabajo

• Al principio, usar un flujo centrado en la revisión como Manual o plan.
• Como bypassPermissions omite todas las comprobaciones, usarlo solo en contenedores o VM aislados.
• No considerar los checkpoints como sustituto de git.
• No esperar que los checkpoints restauren archivos modificados por comandos Bash o cambiados directamente fuera de Claude Code.
• Usar datos sintéticos y valores claramente ficticios en lugar de contraseñas, claves API o datos personales reales.
• Determinar si el trabajo está terminado mediante el diff y la ejecución real, no por la explicación de la IA.

El principio común de esta serie es definir primero requisitos pequeños, empezar por la lectura y la planificación, comprobar el alcance de los cambios y hacer que una persona verifique los resultados de ejecución. A medida que aumenta el alcance de la automatización, el papel humano no desaparece: se desplaza hacia comprobar qué se permitió y si el resultado coincide con los criterios establecidos.

Qué comprobar por tu cuenta

Redactado según la documentación oficial de Claude Code, revisada el 2026-09-22 · Claude Code no se ejecutó realmente · No hay código Python ejecutable

• Comprobar que las descripciones de Manual, acceptEdits, plan, auto, dontAsk y bypassPermissions coincidan con la documentación oficial
• Comparar con la documentación oficial la diferencia del modo inicial predeterminado entre Pro, Max y Team y los demás planes
• Comparar con la documentación oficial los checkpoints automáticos de cada prompt y el acceso mediante /rewind o pulsando Esc dos veces con el campo de entrada vacío
• Comprobar que se indique que los checkpoints no rastrean ni restauran archivos cambiados mediante comandos Bash ni archivos modificados fuera de Claude Code
• Comprobar que se indique claramente la limitación de que los checkpoints no sustituyen a git
• Comprobar que se usen solo valores claramente ficticios como sk-EXAMPLE-NOT-REAL en lugar de secretos reales