Llevas semanas con la app de Claude Code y ya le has cogido el truco: encargos claros, revisar el visor, aprobar. Funciona. Pero empiezas a notar el techo: querrías lanzar dos cosas a la vez, repites las mismas instrucciones cada sesión, y se te ocurren tareas que serían un script si pudieras llamar a Claude desde la línea de comandos.
Ese techo tiene nombre: es el momento de bajar a la terminal. No porque sea "más pro", sino porque desbloquea un puñado de cosas que la app, por diseño, no te da. Esta guía es el salto: qué ganas de verdad, cómo instalarlo, los comandos que importan y los flujos que cambian tu forma de trabajar.
Nota
El motor es el mismo en la app y en la terminal. No vas a "aprender otro Claude Code". Vas a destapar las funciones avanzadas que la interfaz visual mantiene fuera de la vista: paralelismo, automatización y control fino de permisos.
Qué ganas al bajar a la terminal (y qué no)
Seamos honestos para que no pierdas el tiempo. La terminal no te hace mejor ni los resultados más inteligentes. Lo que cambia es la forma de trabajar. Ganas cuatro cosas concretas:
- Sesiones en paralelo. Varias instancias trabajando a la vez en ramas distintas. Es la razón número uno para dar el salto.
- Automatización. Flags como
--printy--output-formatconvierten a Claude en un comando más, encadenable con|,grepo un cron. - Modo headless. Meter a Claude dentro de un script o un pipeline de CI sin que haya nadie mirando la pantalla.
- Control de permisos. Decides qué autoaprueba (leer, listar) y qué exige tu OK (borrar, ejecutar, push).
Lo que no cambia: la red de seguridad sigue ahí. Claude te pide aprobación antes de tocar nada, igual que en la app. Solo que ahora tú decides dónde poner el listón.
Instalación: cinco minutos
Si ya tienes la app, ya cumples los requisitos (Node y, casi seguro, Git). La terminal se instala como un paquete global:
# Con npm (lo más común)
npm install -g @anthropic-ai/claude-code
# Comprueba que está y mira la versión
claude --version
# Inicia sesión la primera vez (usa tu misma cuenta de la app)
claudeLa primera vez que ejecutas claude dentro de una carpeta, te pide login y arranca una sesión interactiva en ese directorio. A partir de ahí le hablas en lenguaje natural, exactamente igual que en la app. La diferencia está en lo que puedes hacer alrededor de esa conversación.
Consejo
Arranca siempre Claude dentro de la carpeta del proyecto (cd mi-proyecto && claude). El directorio donde lo lanzas es su zona de trabajo y donde busca el CLAUDE.md. Lanzarlo desde el home por error es el primer tropiezo clásico.
Los comandos que sí importan
Olvídate de memorizar cien atajos. En la práctica, el día a día son seis. Los comandos que empiezan por / se escriben dentro de la sesión de Claude:
/clear— vacía el contexto y empieza limpio. Tu mejor amigo: una sesión, un objetivo. Cuando cambies de tarea, límpiala./init— escanea el proyecto y te genera un primerCLAUDE.md. El punto de partida para el contexto permanente./agents— gestiona subagentes (los exploramos abajo)./permissions— ajusta qué autoaprueba y qué no./resume— retoma una sesión anterior con todo su contexto. Cierras el portátil y mañana sigues donde lo dejaste.#al inicio de una frase — guarda esa instrucción en elCLAUDE.mdsin abrir el archivo. Atajo de oro.
Y dos flags que se usan al lanzar claude desde fuera, no dentro:
claude -p "tu encargo"(o--print) — ejecuta una tarea y devuelve el resultado por la salida estándar, sin sesión interactiva. La puerta a la automatización.--output-format json— devuelve la respuesta estructurada para que la procese otro programa.
El salto real: sesiones en paralelo con git worktrees
Aquí está el motivo de verdad para bajar a la terminal. En la app trabajas con una conversación a la vez. En la terminal puedes tener tres Claudes trabajando en paralelo, cada uno en su rama, sin pisarse.
El truco es git worktree: crea copias del repositorio que comparten el mismo historial pero viven en carpetas y ramas distintas. Abres una terminal por worktree, lanzas un claude en cada una, y reparten el trabajo.
# Desde la raíz del proyecto, crea tres worktrees en ramas nuevas
git worktree add ../proyecto-feature -b feature-pagos
git worktree add ../proyecto-tests -b add-tests
git worktree add ../proyecto-docs -b update-docs
# En tres pestañas/ventanas de terminal distintas:
cd ../proyecto-feature && claude # "implementa el flujo de pagos"
cd ../proyecto-tests && claude # "escribe tests para el módulo de auth"
cd ../proyecto-docs && claude # "actualiza el README con los nuevos endpoints"
# Cuando una rama esté lista, la mergeas y limpias su worktree
git worktree remove ../proyecto-docsEsto es lo que la app no te da y lo que, una vez lo pruebas, ya no sueltas. Mientras una sesión refactoriza, otra documenta y otra prueba. Tu trabajo pasa de "esperar a que Claude termine" a "supervisar tres frentes". Es el paso de asistente a equipo.
Atención
Paralelismo no es barra libre. Cada sesión sigue su objetivo y nada más: un worktree, una tarea. Si mezclas temas dentro de una misma sesión, le quitas precisión exactamente igual que en la app. Y revisa cada rama antes de mergear; tres agentes producen el triple de cambios que aprobar.
CLAUDE.md y slash commands: tu sistema operativo personal
Si en la app CLAUDE.md ya era útil, en la terminal es imprescindible. Es el contexto permanente que Claude lee al arrancar cada sesión: qué es el proyecto, cómo trabajas, qué reglas respetar. Con varias sesiones en paralelo, es lo que mantiene a todas alineadas sin que se lo repitas a cada una.
El segundo nivel son los slash commands personalizados: archivos Markdown en .claude/commands/ que se convierten en atajos. Escribes un prompt largo una vez y lo invocas con /nombre para siempre.
Revisa el código que acabo de cambiar buscando:
- Bugs de lógica y casos límite sin cubrir.
- Problemas de seguridad (inputs sin validar, secretos en claro).
- Inconsistencias con las convenciones de este proyecto.
No reescribas nada todavía. Lista los hallazgos por gravedad
y espera mi OK antes de tocar archivos.A partir de ese archivo, escribes /revisa dentro de cualquier sesión y Claude ejecuta esa revisión completa. Multiplica esto por tus tareas recurrentes (commits, changelog, auditoría) y dejas de teclear lo mismo cada día.
Modo headless: Claude dentro de tus scripts
El último flujo avanzado es el que casi nadie usa y más rinde. Con claude -p metes a Claude en cualquier script, cron o pipeline de CI. Deja de ser una ventana de chat y se vuelve una pieza de tu automatización.
# Genera el mensaje de commit a partir del diff staged
git commit -m "$(git diff --cached | claude -p 'Resume estos cambios en un mensaje de commit conciso, en imperativo')"
# Triaje automático: clasifica un issue nuevo por la salida estándar
echo "$ISSUE_BODY" | claude -p 'Clasifica este issue: bug / feature / pregunta. Responde solo la etiqueta.' --output-format jsonAquí es donde Claude Code deja de ser una herramienta que abres y se vuelve infraestructura que corre sola. Empieza con encargos acotados y deterministas (resúmenes, clasificación, formato), no con tareas destructivas sin supervisión.
Cuándo dar el salto (y cuándo no)
No bajes a la terminal por estatus. Hazlo cuando sientas al menos una de estas tres señales:
- Repites instrucciones. Si copias el mismo prompt cada sesión, necesitas slash commands y
CLAUDE.mdafinado. - Querrías lanzar dos tareas a la vez. Eso son worktrees. La razón número uno.
- Se te ocurren scripts. Si piensas "esto debería correr solo", quieres el modo headless.
Si no sientes ninguna —tus encargos son puntuales y los revisas con calma— quédate en la app sin complejos. Es igual de potente para ese uso y no tiene fricción.
La regla para escalar es la misma de siempre: de a poco. Instala la terminal, acostúmbrate a los seis comandos, y solo entonces prueba un worktree. El paralelismo y los scripts llegan cuando lo anterior ya te sale solo. El salto no es técnico, es de volumen: en cuanto tengas tres sesiones produciendo a la vez y un par de slash commands hechos, no vas a querer volver.
