Claude Code Terminal: 7 upgrade al workflow per power user

Claude Code in versione “vanilla” è già utile così com’è. Lo installi, lo istruisci con un prompt e lui costruisce quello che vuoi. È l’impostazione da vibe-coding della maggior parte delle persone, e funziona.

La versione di Claude Code usata da chi ha un terminale personalizzato è un altro strumento. Ha pre-approvato i comandi bash di cui si fida, quindi Claude quasi mai chiede il permisso di nuovo. Un CLAUDE.md sta nella root del progetto, così Claude conosce già le convenzioni dal momento in cui si apre una sessione. E quando una sessione inizia a sembrare confusa, il comando a cui ricorrono non è un riavvio.

Questo articolo colma il divario tra queste due configurazioni di Claude Code, in sette upgrade. Nessuno richiede più di dieci minuti per essere impostato, e ognuno ripaga entro una settimana.

Se non hai mai aperto Claude Code prima, la nostra guida principale a Claude Code è un punto di partenza migliore. Tutto ciò che segue presume che tu sappia già creare prompt e accettare chiamate agli strumenti.

1. Smetti di ri-approvare sempre gli stessi comandi

Di default, ogni nuova invocazione di uno strumento ti chiede l’approvazione. Va bene la prima volta che esegui pytest. Fastidioso alla terza. Alla decima, stai martellando Enter senza leggere il prompt. È il peggio di entrambi i mondi: ti sei abituato a ignorare il controllo di sicurezza, e comunque ti rallenta.

Certo, esiste la modalità "bypassa i permessi in modo pericoloso" o "auto mode". Abbiamo trattato ampiamente i pro e i contro nel mio tutorial su Auto Mode e Channels di Claude Code.

Definire i permessi nel file settings.json

La soluzione è un file .claude/settings.json nella root del progetto, con un blocco permissions che pre-approva i pattern di cui ti fidi e blocca quelli di cui non ti fidi:

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

Le regole vengono valutate in un ordine fisso: prima deny, poi ask, poi allow. Il primo match vince, quindi una regola di deny batte sempre un allow successivo.

Padroneggiare scope e wildcard

Tre cose fanno inciampare le persone la prima volta che scrivono una di queste regole.

1. La prima è lo scope. Un .claude/settings.json di progetto sovrascrive il tuo ~/.claude/settings.json globale, quindi se hai consentito Bash(rm *) a livello globale e un progetto lo nega, vince il progetto. È l’impostazione giusta, ma sorprende chi si aspetta che gli allow globali restino "appiccicosi".

2. La seconda sono i wildcard sui comandi di rete. Bash(curl http://github.com/ *) sembra restrittivo ma non intercetta https://, opzioni prima dell’URL, redirect o espansione di variabili di shell. Il pattern consigliato dalla documentazione è negare Bash(curl *) in toto. Poi usa lo strumento WebFetch con WebFetch(domain:github.com) per i domini che vuoi davvero consentire.

3. La terza è lo spazio. Bash(ls *) fa match con ls -la ma non con lsof. Bash(ls*) corrisponde a entrambi. Lo spazio prima dell’asterisco fa la differenza, quindi vale la pena essere intenzionali su quale dei due scrivi.

Alcune scorciatoie da tastiera si affiancano ai permessi nella stessa categoria "smetti di lottare col terminale" e vale la pena impararle dal primo giorno:

• Shift+Tab cicla le modalità di permesso (default, auto-accept, plan)

• Esc+Esc apre il selettore di rewind (ne parliamo al punto 3)

• Ctrl+R cerca al contrario nella cronologia dei prompt, come in bash e zsh

• Ctrl+U cancella dal cursore all’inizio della riga

• Shift+Enter aggiunge una nuova riga dentro il prompt

La maggior parte di queste scorciatoie funziona subito nei terminali. Se non dovesse, esegui una volta il comando slash /terminal-setup per installare tutto.

2. Fai sì che Claude Code ricordi il tuo progetto

Ogni sessione parte con una finestra di contesto fresca.

Di default, Claude non ricorda che usi uv invece di pip. Non ricorda che i tuoi test stanno in tests/ e non in test/. E anche le convenzioni API che hai passato dieci turni a spiegare ieri spariscono. La soluzione è un file CLAUDE.md nella root del progetto. Avvia Claude Code da quella directory (o da una sottodirectory) e il file viene caricato automaticamente nel contesto prima del tuo primo prompt.

Il modo più veloce per iniziare è /init. Eseguilo dentro il progetto. Claude legge il codebase e scrive un CLAUDE.md iniziale con i comandi di build, le istruzioni per i test e le convenzioni che riesce a inferire. Lo modificherai dopo, perché /init ti dà una base funzionante, non un file finito.

Ci sono tre luoghi in cui Claude cerca il contesto, impilati uno sull’altro:

CLAUDE.md di progetto in ./CLAUDE.md viene distribuito col repo. È uguale per ogni contributor, quindi qui metti i fatti specifici del progetto:

• Il package manager e la versione del linguaggio
• Il comando per i test e dove si trovano i test
• La struttura delle directory e le convenzioni non ovvie
• Qualsiasi cosa serva a un nuovo compagno di squadra il primo giorno

CLAUDE.md utente in ~/.claude/CLAUDE.md ti segue in ogni progetto sulla tua macchina. Qui vanno le preferenze personali: il tuo stile di coding, come ti piace scrivere le docstring, le lingue che usi per prime. Non mettere qui fatti di progetto, perché colerebbero in ogni altro repo che apri.

Auto-memory è il terzo livello, e lo scrive Claude da solo. Quando lo correggi durante una sessione ("qui usiamo snake_case, non camelCase"), registra la correzione in ~/.claude/projects/<project>/memory/MEMORY.md. Le prime 200 righe o 25KB di quel file vengono caricate all’inizio di ogni conversazione nello stesso progetto. Puoi vedere cosa è caricato con /memory, che ti permette anche di attivare o disattivare l’auto-memory.

Una regola di dimensionamento: tieni ogni CLAUDE.md sotto le 200 righe. Oltre, il file inizia a mangiare contesto in modo percepibile a ogni turno, e Claude segue i file lunghi meno affidabilmente di quelli corti. Se il tuo supera la soglia, dividilo in .claude/rules/ con scope per percorso. Per un approfondimento su cosa dovrebbe stare in un file CLAUDE.md, vedi la mia guida al miglior CLAUDE.md.

3. Smetti di riavviare le sessioni quando vanno storte

L’istinto, quando una sessione inizia a sembrare fuori fase, è fare /clear e ricominciare da capo. Nella maggior parte dei casi è l’istinto sbagliato. Riavviando butti via i percorsi dei file che Claude stava modificando, il test fallito che stava seguendo o i vincoli che avevi indicato all’inizio. Una sessione nuova deve reimparare tutto, e paghi questo reimparare in token e tempo.

La prima cosa da imparare è il sintomo. Il marciume di contesto ha alcuni segnali evidenti:

• Claude richiede di nuovo un percorso file che ha modificato cinque turni fa
• Ripete un suggerimento che avevi già rifiutato
• Perde traccia del branch su cui ti trovi
• Lo hai corretto più di due volte sullo stesso punto in una sessione

Una volta che li vedi, hai quattro opzioni, e non sono intercambiabili:

Compattare la sessione

 /compact non è così male come alcuni utenti sostengono.

Il tuo CLAUDE.md di progetto sopravvive. Dopo il compattamento Claude rilegge il file dal disco e lo reinserisce, quindi le tue convenzioni non si perdono. Puoi anche passare istruzioni di focus per guidare il riassunto, come /compact keep the auth refactor decisions, drop the failed test runs. È la differenza tra un riassunto utile e uno generico.

Usare l’opzione “undo” di Claude Code

Il selettore di rewind con Esc+Esc è quello di cui quasi nessuno sa l’esistenza. Apre un elenco di ogni checkpoint del prompt nella sessione. Una volta scelto, offre tre opzioni: ripristinare solo la conversazione, solo il codice o entrambi.

"Ripristina codice e conversazione" è ciò che serve alla maggior parte delle persone. Mezz’ora di turni sbagliati può sparire senza aprire git. È la cosa più vicina che Claude Code ha a un undo per un’intera sessione.

Una volta che smetti di riavviare, il problema successivo è ritrovare le sessioni.

Dare un nome e riaprire le sessioni

claude -n <name> (o --name) avvia una sessione nominata, e il nome appare in /resume e nel titolo del terminale. Quando hai tre cose in corso nello stesso repo (un branch di esperimento, un refactor, un debug), i nomi sono come le distingui. /rename cambia il nome a sessione in corso se cambia lo scope.

Trucchetto: usa /color per distinguere ulteriormente le sessioni quando ne esegui più di una nella stessa finestra del terminale.

Per riaprire una sessione ci sono due flag. claude --continue (o -c) carica la conversazione più recente nella directory corrente. Usalo quando eri appena qui e vuoi riprendere.

claude --resume apre un selettore interattivo, e claude --resume <name-or-id> salta direttamente a una sessione specifica. Tratta le sessioni come i branch di git: flussi di lavoro diversi meritano i propri.

4. Pianifica le cose toste, risparmia su quelle facili

Il costo più grande in una configurazione personalizzata non è l’editor o le scorciatoie. È allineare la quantità di calcolo che spendi alla difficoltà del task davanti a te. Tre strumenti lavorano insieme per questo: la modalità plan, /effort e /model.

Usare la modalità plan di Claude Code

La modalità plan dice a Claude di pensare a un approccio prima di toccare i file. Scrive il piano, tu lo leggi, lo approvi o lo contesti, e solo dopo esegue.

Un trucco che uso per rendere i miei piani a prova di bomba è un semplice prompt che uso spesso:

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

Questo avvierà più subagent per rivedere il piano da più aspetti e suggerire correzioni. È una buona pratica quando si lavora con un file di piano oltre le 500 righe.

Il costo è che pianificazione più red-teaming aggiungono due turni prima che atterri qualsiasi codice, quindi per tutto ciò che non sia una feature importante o un bug fix rilevante è eccessivo.

Ci sono cinque modi per entrare in modalità plan:

La forma inline (/plan refactor the auth module to use JWT) è quella che molti si perdono. Imposta modalità e task in una sola battuta invece che in due. Per una guida passo passo ai flussi di lavoro di revisione-prima del piano, il mio tutorial sulla modalità plan di Claude Code va passo dopo passo.

Impostare un livello di effort appropriato

Effort è la cosa successiva da imparare. Controlla quanto ragionamento esteso fa Claude a ogni turno. Effort più alto significa ragionamento più profondo, più token e risposta più lenta.

/effort <level> e il flag CLI --effort <level> accettano tutti e cinque i valori. Low, medium, high e xhigh persistono tra le sessioni. Max vale solo per la sessione corrente perché rimuove il vincolo di spesa in token, quindi lo imposti di proposito ogni volta. Il default giusto per il lavoro quotidiano è low o medium. Riserva high o xhigh ai problemi davvero difficili, e max ai momenti in cui preferisci bruciare token piuttosto che sbagliare.

Una contro-osservazione utile: un modello su low con ottimo contesto spesso batte lo stesso modello su max con contesto scarso. Pulire il prompt di solito è una vittoria più grande che alzare l’effort.

Scegliere il modello giusto

La selezione del modello è dove avviene il vero risparmio. /model cambia a metà sessione, e Option+P (macOS) / Alt+P (Win/Linux) esegue lo switch senza cancellare ciò che hai già digitato. Alias da conoscere:

• sonnet è il default da daily driver

• opus è per i problemi più duri (l’alias best punta anche a opus)

• haiku è per quando vuoi velocità

• sonnet[1m] e opus[1m] sono le varianti con contesto 1M

• opusplan esegue Opus in plan mode e Sonnet in esecuzione

• default rimuove ogni override e torna al modello consigliato

Se stai usando Opus per tutto, passare a Sonnet per la maggior parte della giornata è il taglio di spesa più grande a tua disposizione. 

Opus è la scelta giusta quando sei bloccato su qualcosa di difficile e vuoi il modello più intelligente. Sonnet gestisce quasi tutto il resto. Il divario di costo tra i due è abbastanza grande che "userò Opus per stare sicuro" è l’abitudine più costosa da lasciare in autopilota.

5. Automatizza quello che fai a mano

Una volta rimosse le fonti di attrito, il livello successivo è il lavoro che ancora fai manualmente.

Task pianificati

È più facile che capire come non farlo. Due feature coprono quasi tutto: /loop per i controlli ricorrenti che altrimenti dovresti sorvegliare, e gli hook per le garanzie che non puoi ottenere da un’istruzione in CLAUDE.md.

/loop riesegue un prompt o un comando slash a cadenza ricorrente. La sintassi ha due forme:

• /loop 5m <prompt> esegue il prompt ogni 5 minuti

• /loop <prompt> da solo delega la cadenza al modello, che decide quando rieseguire

Le unità di intervallo sono s, m, h e d, con un minimo di un minuto. Ti serve Claude Code v2.1.72 o successiva.

Per esempio, puoi impostare un watcher dei test: /loop 2m run the test suite and report failures. Invece di ricordarti di eseguire i test dopo ogni modifica (e dimenticartelo metà delle volte), Claude intercetta un test rotto al successivo tick di 2 minuti.

Lo stesso schema funziona per un polling del deploy su staging (/loop 10m check if the staging deploy is green) o una coda dei log durante un incidente intermittente (/loop 1m tail the last 50 lines of app.log and flag errors).

I loop vivono 7 giorni.

Il task scatta un’ultima volta al settimo giorno e si elimina. Sono legati alla sessione, quindi --continue o --resume li riportano se chiudi e riapri. Per fermare un loop in anticipo, premi Esc. Se ti serve una pianificazione che sopravvive alla chiusura della sessione (un controllo notturno, un digest settimanale), usa Routines tramite /schedule.

Hook

Gli hook sono l’altra metà. Eseguono comandi di shell in punti specifici del workflow di Claude, configurati in .claude/settings.json. 

Il motivo per preferire un hook rispetto a un’istruzione in CLAUDE.md è uno: CLAUDE.md è consultivo, gli hook sono garantiti. Il caso classico è la regola "esegui sempre il linter dopo le modifiche" che Claude salta metà delle volte. Un hook chiude quel gap.

Sei eventi coprono la maggior parte dei casi:

Un minimo hook PostToolUse che esegue il linter dopo ogni modifica ai file:

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

Una particolarità da memorizzare: solo il codice di uscita 2 blocca davvero Claude. L’uscita 1 è trattata come errore non bloccante, e Claude procede comunque, anche se 1 è il tipico codice di errore Unix. Se il tuo hook deve far rispettare una regola, restituisci 2.

Non devi nemmeno scrivere a mano gli hook.

Chiedi a Claude "scrivi un hook che esegua ruff dopo ogni modifica ai file" e lui ti prepara il JSON. /hooks elenca ogni configurazione di hook attiva, così non devi fare grep tra i file di impostazioni quando qualcosa scatta inaspettatamente. Per il catalogo completo degli eventi e gli schemi JSON di stdin/stdout, vedi il mio tutorial sugli hook di Claude Code.

6. Tieni d’occhio quanto ti costa tutto questo

Loop, sessioni lunghe e Opus-di-default bruciano token. Tre comandi rendono la spesa abbastanza visibile da poterla gestire, e l’abitudine giusta è darci un’occhiata, non configurarli all’infinito.

/usage mostra il tuo piano, i totali di sessione, i costi per modello e le barre di avanzamento per le finestre di rate limit da 5 ore e settimanali.

/context visualizza la finestra di contesto corrente come una griglia colorata, con avvisi di capacità e suggerimenti su quali strumenti o file stanno occupando spazio. Usalo quando una sessione sembra pesante e stai decidendo tra /compact e /clear.

/statusline configura una barra persistente in fondo al terminale. Può mostrare il modello, la percentuale di contesto, le finestre di rate limit e qualsiasi altra cosa leggibile dal JSON della sessione. È quella che cambia di più i comportamenti, perché mette i numeri rilevanti per i costi nella tua visione periferica mentre lavori.

Puoi eseguire /statusline e descrivere in linguaggio naturale cosa vuoi mostrare, e Claude genera lo script e aggiorna le impostazioni. L’altra opzione è scrivere uno script shell tu stesso e puntarlo da ~/.claude/settings.json:

{
  "statusLine": {
	"type": "command",
	"command": "~/.claude/statusline.sh"
  }
}

Per un tracciamento a lungo termine tra sessioni, npx ccusage è uno strumento della community che aggrega il consumo di token nel tempo. È di terze parti, non sviluppato da Anthropic, ma colma il gap tra il /usage limitato alla sessione e la tua fattura mensile.

7. Altre tre cose che vale la pena conoscere

I sei upgrade sopra sono quelli che uso ogni giorno. I tre qui sotto sono funzionalità reali che uso meno spesso, ma che dovresti sapere che esistono, così puoi tirarle fuori il giorno in cui ti servono.

Usare il push-to-talk con /voice

/voice attiva la dettatura push-to-talk. Tieni premuto Space, parla, rilascia, e il testo trascritto finisce nell’input del prompt. Ti serve la v2.1.69 o successiva, e sono supportate venti lingue.

La voce batte la tastiera quando cammini e pensi a voce alta o stai dettando l’intento a inizio task prima che la formulazione sia definita. È peggiore per le modifiche a livello di riga, dove "cambia la riga 47 in..." è più facile da digitare.

Recuperare sessioni cloud con /teleport

/teleport (alias /tp) porta una sessione cloud nel tuo terminale locale. Diciamo che hai iniziato un task lungo sulla web app o sull’app iOS, e ora sei tornato al laptop. Esegui claude --teleport per aprire un selettore e atterrare quella sessione nel terminale con il branch giusto già fatto checkout.

Devono allinearsi alcuni requisiti:

• Stato git pulito
• Il repo giusto
• Lo stesso account claude.ai che ha eseguito la sessione cloud
• Il branch è stato pushato sul remote

Non confondere --teleport con --resume. Il secondo riapre solo le sessioni locali dalla cronologia di questa macchina. Per un walkthrough dettagliato, la nostra guida al controllo remoto di Claude Code copre il resto.

Fare domande laterali con /btw

/btw serve per la domanda veloce che vuoi fare senza interrompere il flusso.

Immagina che Claude sia a metà di un task. Hai già avviato una modifica lunga o una chiamata a uno strumento, e ti serve all’improvviso sapere la regex per fare match con gli IP o quale flag fa X. 

Puoi semplicemente digitare /btw <question>, e la risposta appare in un overlay disattivabile. Il task in corso continua a girare, la risposta non entra nella cronologia della conversazione, quindi non devi creare una nuova sessione per una ricerca estemporanea e non inquini quella corrente.

Conclusione

Il modo più veloce per vanificare tutto ciò che c’è in questo articolo è provare tutto in un solo giorno. Scegline due o tre, costruisci memoria muscolare per quelli, e aggiungi il resto quando il primo set diventa automatico.

Tre da cui partire, ognuno per un momento diverso della giornata, così non si pestano i piedi:

• Un CLAUDE.md di progetto snello più due o tre regole con wildcard in .claude/settings.json per i comandi bash che ri-approvi a ogni sessione. È l’abitudine di setup del mattino, e la senti solo quando le interruzioni scompaiono.

• La scelta tra /compact e /clear e il selettore di rewind con Esc+Esc. È l’abitudine di metà sessione, e il segnale è il momento in cui Claude richiede di nuovo un percorso file che conosceva un’ora fa.

• Un /loop per un controllo ricorrente che già ti porta via tempo. È l’abitudine in background, e una volta avviata, ripaga da sola.

Se la differenza tra Sonnet, Opus e Haiku è ancora fusca, il nostro corso Introduction to Claude Models spiega quando si adatta ciascun modello. Questo rende le chiamate /effort e /model molto più semplici.