El Mac que no duerme

Qué es y por qué importa

Claude Code puede trabajar durante horas aunque no estés. Una noche se lo escribí de verdad: «Me voy a dormir, tienes plenos poderes.» A la mañana siguiente la build ya estaba publicada.

Pero solo funciona si le dejas tres cosas: un objetivo claro, una forma de comprobar él solo su trabajo y un límite a lo que puede tocar.

Sin objetivo da vueltas en vacío. Sin verificación te cuenta que todo está bien. Sin límites puede hacer daños. Con los tres, por la mañana encuentras el trabajo y una lista de decisiones que aprobar, no sorpresas.

1. El mensaje de la noche

Lo escribo en la sesión de Claude Code abierta en el proyecto, como último mensaje antes de irme a la cama. Cópialo y rellena las partes entre [ ].

Me voy a dormir. Tienes plenos poderes sobre este trabajo hasta mañana por la mañana.

OBJETIVO
[Una sola frase, concreta. Ej.: "La nueva página de precios, publicada en la web de pruebas".]
Has terminado cuando: [ej. "la página se abre desde el móvil y los botones llevan al pago de prueba"].

CÓMO LO COMPRUEBAS TÚ SOLO
- Lanza los tests después de cada cambio y no sigas si uno falla.
- Abre la página en el navegador y haz una captura de cada pantalla terminada.
- No me digas "hecho" sin la prueba: el comando que has usado y el resultado.

LÍMITES (lo que NO puedes tocar)
- La base de datos real, los datos de los usuarios, los pagos reales.
- No borres archivos, no publiques en la App Store, no cambies las claves.
- Si para seguir tienes que hacer una de estas cosas: para y escríbemelo.

SI TE ATASCAS
Prueba dos caminos distintos. Si ninguno funciona, escribe dónde te has quedado y pasa a la parte siguiente.

MAÑANA POR LA MAÑANA
Déjame un resumen: qué has hecho, qué has decidido tú solo y por qué, qué necesitas de mí.

Cómo rellenar las partes entre [ ]

• Objetivo: una sola cosa. «Arregla la web» no es un objetivo. «La nueva página de precios, publicada en la web de pruebas» sí.
• «Has terminado cuando»: escribe lo que verías tú, con tus propios ojos, si el trabajo estuviera hecho. Es la línea que le dice cuándo parar.
• Los tests tienen que existir ya y pasar antes de que te vayas a dormir. Si no tienes, el trabajo de esta noche puede ser justo escribirlos.
• Claude solo puede hacer las capturas si tiene una forma de abrir el navegador, por ejemplo conectado a Chrome. Si no la tiene, quita esa línea o pon una comprobación que pueda hacer desde la terminal.

2. Antes de apagar la luz

Si el Mac entra en reposo, Claude también se para. Antes de pegar el mensaje hago cuatro cosas:

1. Guardo todo con un commit. Así, por la mañana, en los cambios veo solo el trabajo de la noche.
2. Enchufo el cargador.
3. Dejo el portátil abierto. Cerrar la tapa lo pone en reposo, incluso con los ajustes que lo mantienen despierto.
4. Impido el reposo. En la app de escritorio de Claude está la opción Keep computer awake, en Settings > This computer > System. Desde la terminal uso un comando que el Mac ya trae: caffeinate.

Desde la terminal arranco Claude Code así:

caffeinate -i claude

caffeinate -i mantiene el Mac despierto mientras Claude Code siga abierto. Cuando lo cierras, el Mac vuelve a comportarse como siempre. La pantalla, en cambio, se puede apagar, no cambia nada.

3. No lo dejes parado esperando un sí

En el modo Manual, Claude Code te pide permiso antes de la mayoría de los cambios y comandos. De noche eso significa que, a la primera pregunta, se queda parado hasta que te despiertas.

Por eso, antes de irme a dormir, miro en qué modo estoy. En la terminal lo cambias con Shift+Tab y lo ves escrito debajo del prompt. De noche uso uno de estos dos:

• auto: Claude trabaja sin preguntarte nada y un segundo modelo revisa las acciones antes de que se ejecuten, bloqueando las arriesgadas (despliegues a producción, borrados masivos, force push). También tiene en cuenta los límites escritos en el mensaje. Si no lo encuentras con Shift+Tab, tu cuenta o tu modelo no lo tienen: usa el otro.
• acceptEdits: acepta por su cuenta los cambios en los archivos y algunos comandos básicos, como crear o mover carpetas. Para los demás comandos preguntaría, así que va junto con las reglas allow que ves más abajo, para dejarle lanzar al menos los tests.

Una cosa que conviene saber del modo auto: si bloquea una acción 3 veces seguidas, o 20 en total, se pone en pausa y Claude vuelve a pedirte permiso. Si por la mañana lo encuentras parado en una pregunta, mira qué quería hacer: es justo una de las decisiones que te tocan a ti.

El que se salta todos los permisos (bypassPermissions), en cambio, no lo uso: la documentación dice que solo se use en contenedores o máquinas virtuales aisladas, no en tu Mac.

4. Límites de verdad: reglas y hooks

Una regla escrita en el mensaje es una petición; un hook es un muro. La documentación también lo dice, con otras palabras: los permisos los hace cumplir Claude Code, no el modelo. Lo que escribes en el mensaje orienta lo que Claude intenta hacer, pero no cambia lo que se le permite.

Las reglas allow y deny

Son líneas en el archivo .claude/settings.json del proyecto. Allow: lo que Claude puede hacer sin preguntar. Deny: lo que no puede hacer nunca, en ningún modo. Si algo está a la vez en allow y en deny, gana deny. También las ves y las cambias escribiendo /permissions dentro de Claude Code.

De día le pido a Claude que las prepare:

Añade al archivo .claude/settings.json de este proyecto una regla allow para lanzar los tests sin preguntarme, y reglas deny para: git push, los comandos rm, los cambios en el archivo .env. Enséñame el archivo antes de guardarlo.

Más o menos tiene que quedar así (en lugar de npm test va el comando de tests de tu proyecto):

{
  "permissions": {
    "allow": ["Bash(npm test *)"],
    "deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Edit(./.env)"
    ]
  }
}

Ojo: una regla bloquea el comando escrito de esa forma, no el mismo programa lanzado de otra manera. Por eso los límites siguen también en el mensaje, y mejor que las claves reales ni siquiera estén en el proyecto.

El hook para los comandos peligrosos

Un hook es un comando que Claude Code lanza solo en un momento concreto. El que necesitas aquí se llama PreToolUse: salta antes de que Claude use una herramienta, por ejemplo antes de cada comando en la terminal. El script mira el comando y, si termina con el código 2, Claude Code lo bloquea y le pasa a Claude el motivo, para que cambie de camino. También bloquea comandos que una regla allow dejaría pasar.

No tienes que escribirlo tú. Se lo pido a Claude, también de día:

Crea un hook PreToolUse para este proyecto, en .claude/settings.json, que bloquee los comandos Bash que contengan: rm -rf, git push --force, [el comando con el que publicas tu app]. El script tiene que terminar con código 2 y escribir el motivo del bloqueo. Luego pruébalo: enséñame que un comando prohibido se detiene de verdad y que un comando normal pasa.

Luego escribo /hooks en Claude Code y compruebo que aparece en la lista, debajo de PreToolUse.

5. A la mañana siguiente

Lo primero que leo es el resumen, sobre todo la parte «qué has decidido tú solo». Ahí están las cosas que aprobar. Luego vuelvo a lanzar yo uno de los comandos que usó como prueba: si a mí me sale un resultado distinto, esa prueba no vale.

Y en la misma sesión pregunto:

Enséñame la lista de los archivos que has cambiado esta noche. Para cada decisión que has tomado tú solo, dime qué pasa si la deshago.

Errores comunes

• Dejarlo en modo Manual: a la primera petición de permiso se para hasta la mañana. Antes de irte, elige el modo y prepara las reglas allow.
• Un objetivo vago, tipo «mejora la app»: trabaja toda la noche y no sabes en qué. Escribe una sola cosa, con la línea «has terminado cuando».
• Cerrar la tapa o dejarlo con batería: el Mac entra en reposo o se queda sin batería a mitad de la noche. Déjalo abierto, enchufado al cargador, con caffeinate o la opción que lo mantiene despierto.
• Fiarse solo de los límites escritos en el mensaje: son una petición y en una conversación larga se pueden perder. Para las cosas que no deben pasar nunca, pon una regla deny o un hook.

Lista de comprobación

• Un objetivo en una frase y la línea «has terminado cuando»
• Los tests existen y pasan antes de empezar la noche
• Todo guardado con un commit antes de la noche
• Modo elegido: auto, o acceptEdits con las reglas allow
• Reglas deny y hook probados de día
• Cargador enchufado, tapa abierta, Mac que no entra en reposo
• El mensaje de la noche pegado, con tus límites

Preguntas frecuentes