Il Mac che non dorme

Cos'è e perché conta

Claude Code può lavorare per ore anche quando tu non ci sei. Una sera gliel'ho scritto davvero: «Vado a dormire, hai pieno potere.» La mattina dopo la build era online.

Ma funziona solo se gli lasci tre cose: un obiettivo chiaro, un modo per verificare da solo il proprio lavoro e un limite a cosa può toccare.

Senza obiettivo gira a vuoto. Senza verifica ti racconta che è tutto a posto. Senza limiti può fare danni. Con tutti e tre, la mattina trovi il lavoro e una lista di decisioni da approvare, non sorprese.

1. Il messaggio della sera

Lo scrivo nella sessione di Claude Code aperta sul progetto, come ultimo messaggio prima di andare a letto. Copialo e riempi le parti tra [ ].

Vado a dormire. Hai pieno potere su questo lavoro, fino a domattina.

OBIETTIVO
[Una frase sola, concreta. Es: "La pagina dei prezzi nuova, online sul sito di prova".]
Hai finito quando: [es. "la pagina si apre dal telefono e i pulsanti portano al pagamento di prova"].

COME VERIFICHI DA SOLO
- Lancia i test dopo ogni modifica e non andare avanti se uno fallisce.
- Apri la pagina nel browser e fai uno screenshot di ogni schermata finita.
- Non dirmi "fatto" senza la prova: il comando che hai usato e il risultato.

LIMITI (cosa NON puoi toccare)
- Il database vero, i dati degli utenti, i pagamenti veri.
- Non cancellare file, non pubblicare sull'App Store, non cambiare le chiavi.
- Se per andare avanti devi fare una di queste cose: fermati e scrivimelo.

SE TI BLOCCHI
Prova due strade diverse. Se nessuna funziona, scrivi dove ti sei fermato e passa alla parte successiva.

DOMATTINA
Lasciami un riassunto: cosa hai fatto, cosa hai deciso da solo e perché, cosa ti serve da me.

Come riempire le parti tra [ ]

• Obiettivo: una cosa sola. «Sistema il sito» non è un obiettivo. «La pagina dei prezzi nuova, online sul sito di prova» sì.
• «Hai finito quando»: scrivi cosa vedresti tu, con i tuoi occhi, se il lavoro fosse fatto. È la riga che gli dice quando fermarsi.
• I test devono già esistere e passare prima che tu vada a dormire. Se non ne hai, il lavoro di stanotte può essere proprio scriverli.
• Gli screenshot Claude li può fare solo se ha un modo per aprire il browser, per esempio collegato a Chrome. Se non ce l'ha, togli quella riga o mettici un controllo che può fare dal terminale.

2. Prima di spegnere la luce

Se il Mac va in stop, si ferma anche Claude. Prima di incollare il messaggio faccio quattro cose:

1. Salvo tutto con un commit. Così domattina, nelle modifiche, vedo solo il lavoro della notte.
2. Attacco il caricatore.
3. Lascio il portatile aperto. Chiudere il coperchio lo manda in stop, anche con le impostazioni per tenerlo sveglio.
4. Impedisco lo stop. Nell'app desktop di Claude c'è l'opzione Keep computer awake, in Settings > This computer > System. Dal terminale uso un comando che il Mac ha già: caffeinate.

Dal terminale avvio Claude Code così:

caffeinate -i claude

caffeinate -i tiene sveglio il Mac finché Claude Code resta aperto. Quando lo chiudi, il Mac torna a comportarsi come sempre. Lo schermo invece si può spegnere, non cambia niente.

3. Non lasciarlo fermo ad aspettare un sì

In modalità Manual, Claude Code ti chiede il permesso prima della maggior parte delle modifiche e dei comandi. Di notte vuol dire che alla prima domanda resta fermo fino a quando ti svegli.

Per questo, prima di andare a dormire, guardo in che modalità sono. Nel terminale la cambi con Shift+Tab e la vedi scritta sotto il prompt. Di notte uso una di queste due:

• auto: Claude lavora senza chiederti niente e un secondo modello controlla le azioni prima che partano, bloccando quelle rischiose (deploy in produzione, cancellazioni di massa, force push). Tiene conto anche dei limiti scritti nel messaggio. Se non la trovi con Shift+Tab, il tuo account o modello non ce l'ha: usa l'altra.
• acceptEdits: accetta da solo le modifiche ai file e qualche comando base, tipo creare o spostare cartelle. Per gli altri comandi chiederebbe, quindi va insieme alle regole allow che vedi sotto, per lasciargli lanciare almeno i test.

Una cosa da sapere sulla modalità auto: se blocca un'azione 3 volte di fila, o 20 in tutto, si mette in pausa e Claude torna a chiederti il permesso. Se la mattina lo trovi fermo su una domanda, guarda cosa voleva fare: è proprio una delle decisioni che spettano a te.

Quella che salta tutti i permessi (bypassPermissions) invece non la uso: la documentazione dice di usarla solo in container o macchine virtuali isolate, non sul tuo Mac.

4. I limiti veri: regole e hook

Una regola scritta nel messaggio è una richiesta; un hook è un muro. Lo dice anche la documentazione, con altre parole: i permessi li fa rispettare Claude Code, non il modello. Quello che scrivi nel messaggio orienta cosa Claude prova a fare, ma non cambia cosa gli è permesso.

Le regole allow e deny

Sono righe nel file .claude/settings.json del progetto. Allow: cosa Claude può fare senza chiedere. Deny: cosa non può fare mai, in nessuna modalità. Se una cosa è sia in allow che in deny, vince deny. Le vedi e le modifichi anche scrivendo /permissions dentro Claude Code.

Di giorno chiedo a Claude di prepararle:

Aggiungi al file .claude/settings.json di questo progetto una regola allow per lanciare i test senza chiedermelo, e regole deny per: git push, i comandi rm, le modifiche al file .env. Fammi vedere il file prima di salvarlo.

Più o meno deve venire così (al posto di npm test ci va il comando dei test del tuo progetto):

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

Attenzione: una regola blocca il comando scritto in quel modo, non lo stesso programma lanciato in un'altra forma. Per questo i limiti restano anche nel messaggio, e le chiavi vere è meglio che nel progetto non ci siano proprio.

L'hook sui comandi pericolosi

Un hook è un comando che Claude Code lancia da solo in un momento preciso. Quello che serve qui si chiama PreToolUse: scatta prima che Claude usi uno strumento, per esempio prima di ogni comando nel terminale. Lo script guarda il comando e, se esce con il codice 2, Claude Code lo blocca e passa a Claude il motivo, così lui cambia strada. L'hook blocca anche i comandi che una regola allow lascerebbe passare.

Non devi scriverlo tu. Lo chiedo a Claude, sempre di giorno:

Crea un hook PreToolUse per questo progetto, in .claude/settings.json, che blocchi i comandi Bash che contengono: rm -rf, git push --force, [il comando con cui pubblichi la tua app]. Lo script deve uscire con codice 2 e scrivere il motivo del blocco. Poi provalo: fammi vedere che un comando vietato viene fermato davvero e che un comando normale passa.

Poi scrivo /hooks in Claude Code e controllo che compaia nella lista, sotto PreToolUse.

5. Domattina

La prima cosa che leggo è il riassunto, e in particolare la parte «cosa hai deciso da solo». Lì ci sono le cose da approvare. Poi rilancio io uno dei comandi che ha usato come prova: se a me esce un risultato diverso, quella prova non vale.

E nella stessa sessione chiedo:

Fammi vedere la lista dei file che hai cambiato stanotte. Per ogni decisione che hai preso da solo, dimmi cosa succede se la annullo.

Gli errori più comuni

• Lasciarlo in modalità Manual: alla prima richiesta di permesso si ferma fino al mattino. Prima di uscire scegli la modalità e prepara le regole allow.
• Un obiettivo vago, tipo «migliora l'app»: lavora tutta la notte e non sai su cosa. Scrivi una cosa sola, con la riga «hai finito quando».
• Chiudere il coperchio o lasciarlo a batteria: il Mac va in stop o si scarica a metà notte. Lascialo aperto, attaccato al caricatore, con caffeinate o l'opzione per tenerlo sveglio.
• Fidarsi solo dei limiti scritti nel messaggio: sono una richiesta, e in una conversazione lunga si possono perdere. Per le cose che non devono succedere mai, metti una regola deny o un hook.

Checklist

• Un obiettivo in una frase e la riga «hai finito quando»
• I test esistono e passano prima di partire
• Tutto salvato con un commit
• Modalità scelta: auto, oppure acceptEdits con le regole allow
• Regole deny e hook provati di giorno
• Caricatore attaccato, coperchio aperto, Mac che non va in stop
• Il messaggio incollato, con i tuoi limiti

Domande frequenti