Objetivo del tema
Dominar los modos de trabajo de Claude Code —normal, ediciones automáticas y Plan—, aprender a alternar entre ellos con Shift+Tab, adoptar el flujo profesional de planificar antes de construir y conocer cuándo tiene sentido cada modo.
Durante una sesión interactiva siempre hay un modo de permisos activo que define cuánta autonomía tiene el agente. Pulsando Shift+Tab ciclas entre ellos; el modo vigente se muestra en la línea de estado:
| Modo | Ediciones de archivos | Comandos de terminal | Uso típico |
|---|---|---|---|
| Normal (predeterminado) | Piden aprobación (o regla de allow previa). | Piden aprobación (o regla de allow previa). | Trabajo diario con control total. |
| Ediciones automáticas | Se aplican solas. | Siguen pidiendo aprobación según reglas. | Iteración fluida revisando el diff al final. |
| Plan | Prohibidas. | Solo lectura. | Analizar, diseñar y revisar sin tocar el código. |
Idea clave: la diferencia entre modos no está en el modelo ni en la inteligencia disponible, sino en los permisos. El mismo Claude que planifica en Plan es el que edita en modo normal; lo que cambia es cuánto puede hacer sin preguntar.
El modo normal es el punto de partida. Cada vez que el agente quiere editar un archivo o ejecutar un comando sensible, muestra exactamente qué hará y espera tu decisión: aprobar una vez, aprobar siempre esa acción en la sesión, o rechazar con una indicación alternativa.
Es el modo recomendado mientras aprendes: cada aprobación es una oportunidad para leer código y entender lo que el agente propone.
El modo Plan convierte a Claude Code en un asesor de solo lectura: puede explorar el repositorio, buscar patrones, leer documentación y ejecutar comandos sin efectos secundarios, pero no edita archivos ni ejecuta acciones que modifiquen el proyecto. Al final del análisis presenta un plan concreto y espera tu aprobación para implementarlo.
Es el modo ideal para:
Dentro de Plan combina muy bien con el razonamiento extendido del tema 5: pide think hard o ultrathink para problemas difíciles y espera preguntas de aclaración: un buen agente en modo Plan pregunta antes de suponer.
Para funcionalidades que van más allá de un arreglo puntual, el flujo con mejores resultados tiene tres etapas:
Describe la funcionalidad con detalle y deja que el agente explore y proponga. Ejemplo: "cuando un usuario borra una nota, marcarla como eliminada en la base y crear una pantalla de eliminadas con opción de restaurar o borrar definitivo".
Responde con correcciones y contexto extra: referencias con @, capturas arrastradas a la terminal, restricciones de diseño. Para tareas grandes, pide que guarde el plan en un archivo Markdown: queda como especificación ejecutable.
Al presentar el plan, elige continuar con ediciones automáticas o aprobación manual. El agente ejecuta, corre los tests y reporta resultados; los checkpoints quedan como red de seguridad.
Habla con él como a un compañero del equipo: cuanto más contexto (ejemplos, imágenes, archivos de referencia), menos idas y vueltas. Y si el plan aprobado es extenso, permite la ejecución por fases: cada fase termina con tests en verde y un commit.
El segundo modo con Shift+Tab acepta automáticamente las ediciones de archivos mientras deja los comandos de terminal gobernados por sus reglas. Es el punto dulce para:
La red de seguridad en este modo son los checkpoints (tema 7): ante cualquier dirección equivocada, doble Esc y el proyecto vuelve al estado previo. Velocidad y reversibilidad no tienen por qué estar reñidas.
| Situación | Modo sugerido | Motivo |
|---|---|---|
| Agregar una feature compleja | Plan → ediciones automáticas | Primero alinear diseño, después ejecutar sin fricción. |
| Corregir un bug puntual | Normal | Cambio acotado; aprobar cada paso mantiene el control. |
| Entender un módulo ajeno | Plan | Análisis seguro sobre código que aún no quieres tocar. |
| Refactor de gran alcance | Plan → fases con commits | El plan por fases permite revisar antes de cada paso. |
| Escribir tests o documentación | Ediciones automáticas | Tareas aditivas de bajo riesgo con revisión final del diff. |
| Revisar un pull request ajeno | Plan | Comentarios y análisis sin riesgo de modificar nada. |
No siempre conviene empezar en modo normal. Dos mecanismos fijan el modo inicial:
claude --permission-mode plan # abre la sesión en modo Plan
claude -c --permission-mode plan # retoma la última sesión en PlanO de forma persistente, en el archivo settings.json del proyecto o del usuario:
{
"permissions": {
"defaultMode": "acceptEdits"
}
}Esto es útil, por ejemplo, para Equipos que acuerdan "toda sesión empieza en Plan" como política, o para sesiones de refactor donde ya se presupuesta iteración rápida. El modo sigue cambiándose al vuelo con Shift+Tab: lo que fija la configuración es solo el punto de partida.
Mirando adelante: existe un cuarto estado llamado bypassPermissions, que omite todas las aprobaciones. No se activa con Shift+Tab sino con el flag --dangerously-skip-permissions, y su lugar natural son contenedores y entornos de CI aislados, nunca tu máquina con código de producción. Lo veremos junto a la automatización en el tema 18.
# en la memoria.Conclusión: los modos de permisos formalizan una disciplina que ya aplicaban los buenos equipos: pensar antes de escribir, ejecutar con control y revertir sin dolor. Alternar con Shift+Tab cuesta un segundo y evita horas de re-trabajo: explora y acuerda el camino en Plan, y construye con el nivel de autonomía que la tarea merece. En el próximo tema recorreremos en detalle los comandos slash y las opciones de la línea de comandos.