/goal in Claude Code: modalità autonoma e Agent View nel 2026

Documentazione di riferimento Ailoot: ailoot.ai/docs/.

Che cos’è /goal in Claude Code?#

In precedenza, Claude Code si fermava dopo ogni risposta e aspettava il tuo prompt successivo. Funzionava per le attività brevi, ma non per quelle lunghe: una migrazione di API, la correzione di 12 test falliti, il refactoring di un file da 800 righe: queste attività richiedono 20–30 iterazioni e ognuna ti riportava al terminale.

/goal risolve il problema con un’idea semplice: separare «chi svolge il lavoro» da «chi decide quando è finito». L’agente principale scrive il codice. Un valutatore separato (il modello rapido Haiku) legge la conversazione dopo ogni turno e risponde a una domanda: «La condizione è stata soddisfatta?». Se no, l’agente inizia un altro turno. Se sì, il controllo torna a te.

La documentazione ufficiale di Anthropic lo definisce così:

Migliaia di agenti di notte, da un telefono: non è marketing, ma la pratica attuale di un ingegnere Anthropic. E il meccanismo che lo rende possibile è la combinazione di /goal + Agent View, introdotta nella stessa versione l’11 maggio 2026.

Perché serve la modalità autonoma: cosa c’era prima e dopo l’11 maggio 2026?#

L’idea di «lasciare l’IA a lavorare durante la notte» esisteva già dall’autunno del 2025, quando Cursor Composer e la modalità automatica di Cline potevano già lavorare in background. Ma prima dell’11 maggio 2026 Claude Code richiedeva un wrapper manuale: un’attività cron che chiamava claude -p ogni N minuti oppure un wrapper che controllava git status e avviava il prompt successivo.

Questo approccio fai-da-te causava regolarmente disastri. Il 22 maggio 2026, uno sviluppatore ha lasciato uno script del genere in esecuzione durante la notte e si è svegliato con una fattura di 6.000 $. La causa principale: Anthropic ha cambiato silenziosamente il TTL della cache di Claude Code da un’ora a cinque minuti senza annunciarlo. Cron chiamava la produzione ogni 30 minuti: la cache aveva il tempo di scadere tra un’esecuzione e l’altra. Ogni esecuzione ricostruiva da zero una cronologia di 800.000 token. Scrivere nuovi dati nella cache costa molto più che leggere da una cache attiva.

Lo sviluppatore non stava facendo nulla di insolito: usava lo strumento esattamente come Anthropic lo aveva pubblicizzato.

/goal risolve il problema con un’architettura integrata:

1. Processo supervisore che mantiene la sessione fuori dal terminale e continua a funzionare anche quando chiudi la finestra e il laptop entra in sospensione.
2. Valutatore Haiku: un modello economico controlla ogni turno; i token del valutatore costano pochi centesimi.
3. Limite rigido di turni nella condizione: puoi scrivere esplicitamente or stop after 20 turns e la sessione si fermerà di sicuro.
4. Isolamento tramite worktree per le sessioni in background: le modifiche vanno su un ramo separato senza toccare la tua copia di lavoro.

La differenza rispetto all’approccio «scrivi il tuo script bash» è che Anthropic integra tutti questi meccanismi nello strumento come funzionalità di prima classe, anziché ricorrere a stratagemmi di terze parti.

Come abilitare /goal in 3 passaggi#

Passaggio 1. Aggiorna Claude Code alla versione 2.1.139 o successiva.

Controlla la versione:

claude --version

Se è precedente alla 2.1.139, aggiorna:

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

Le versioni rilasciate tra il 12 e il 19 maggio 2026 hanno corretto bug importanti della prima versione. Nella 2.1.140 è stato corretto un blocco silenzioso in cui disableAllHooks impediva il funzionamento del valutatore. Nella 2.1.143 sono arrivati worktree.bgIsolation: "none" e una correzione per i loop degli hook di arresto. Nella 2.1.144 (19 maggio) sono stati aggiunti --resume per le sessioni in background e --json per gli agenti per lo scripting. La versione minima è la 2.1.143.

Passaggio 2. Digita /goal con una condizione.

Apri una normale sessione di Claude Code e inserisci il comando:

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

Non serve inviare un prompt separato dopo: il comando avvia subito il primo turno. La condizione può essere scritta in russo, inglese o in una combinazione delle due lingue: il modello le capisce entrambe. Il limite di lunghezza è di 4.000 caratteri.

Passaggio 3. Monitora tramite il pannello live.

Dopo l’avvio di /goal, nella parte inferiore del terminale appare un pannello live:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

Cosa mostra:

• Turni: quanti turni sono stati completati
• Tempo trascorso: quanto tempo è passato dall’avvio
• Token: totale dei token spesi (il dato principale per monitorare il budget)
• Ultimo: l’ultimo motivo indicato dal valutatore per rispondere «non ancora»

Un accorgimento utile: se il valutatore restituisce lo stesso motivo per tre turni consecutivi, è segno che sei in un loop. Premi Ctrl+C oppure inserisci /goal clear (sinonimi: stop, off, reset, cancel), riformula la condizione e avvia di nuovo. Le guide della community a /goal indicano questa regola come principale segnale di loop: «bloccato sullo stesso motivo tre volte: è un loop, esci».

Come scrivere una buona condizione: 5 regole + 5 esempi#

La documentazione di Anthropic descrive tre elementi necessari per una buona condizione:

Un modello già pronto copre tutti e tre gli elementi in una sola riga:

A ready-made template covers all three elements in one line:

/goal [esegui il lavoro] finché [stato finale misurabile] senza [vincoli da rispettare]

Cinque regole che mettono in difficoltà la maggior parte delle persone:

Regola 1. Lo stato finale deve essere verificabile con un comando, non con il gusto personale.

Non «falla sembrare bella», ma npm test exits 0. Non «migliora la UX», ma Lighthouse Performance score above 90. Il valutatore legge solo la trascrizione: non esegue comandi né guarda screenshot. Se il risultato non può essere registrato in testo, il valutatore non dirà mai «sì».

Regola 2. I vincoli devono essere espliciti e circoscritti.

Senza vincoli, Claude potrebbe correggere i test cancellandoli o commentando le asserzioni che falliscono. Specifica without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Regola 3. È necessario un limite rigido di turni.

Aggiungi or stop after N turns a ogni condizione. È una via di salvezza contro i loop infiniti. Senza un limite, un loop in esecuzione per un’ora consuma più token che svolgere la stessa attività manualmente. Metti in conto questa eventualità.

Regola 4. Descrivi CHE COSA vuoi, non solo COME.

Se non hai menzionato gli elementi visivi nella condizione, Claude non li creerà. Se la condizione richiede solo «test superati», Claude potrebbe commentare i test complessi. Descrivi CHE COSA vuoi, non solo COME lo verificherai.

Regola 5. Fai mostrare le prove nella chat a Claude.

Il valutatore non esegue comandi: legge solo ciò che Claude ha già mostrato. Se la condizione richiede «npm test è verde» ma Claude non ha mostrato l’output di npm test nella trascrizione, il valutatore risponderà «non ancora» per sempre. Aggiungi alla condizione la frase «mostra l’output di <command> nella conversazione».

Cinque esempi funzionanti per attività comuni:

1. Migrazione API:
/goal ogni chiamata a getUser() è stata sostituita con fetchUser(), npm test passa, npm run build è verde, nessun altro nome API è stato modificato, oppure fermati dopo 30 turni

2. Correzione dei test:
/goal tutti i test falliti in test/auth ora passano (npm test mostra 0 errori nella chat), senza modificare le asserzioni o cancellare i test, oppure fermati dopo 20 turni

3. Qualità del codice (dimensione dei file):
/goal src/legacy/UserService.ts è stato suddiviso in file da meno di 200 righe ciascuno, tutti gli import sono aggiornati, npm run build è verde, oppure fermati dopo 25 turni

4. Smaltimento delle issue arretrate:
/goal elabora ogni issue con l’etichetta 'good-first-issue': leggi la descrizione, implementa una correzione in un ramo worktree, apri una PR. Continua finché la coda non è vuota o sono state elaborate 6 issue

5. Verifica di sicurezza:
/goal tutte le vulnerabilità di npm audit con gravità >= high sono corrette, tutti i test esistenti passano, nessuna modifica incompatibile dell’API, oppure fermati dopo 15 turni

Vuoi fare più che eseguire /goal e creare una configurazione in cui la modalità autonoma funzioni davvero sul tuo progetto? /goal è solo l’ultimo anello. Prima servono tre pilastri: un clone IA (la tua metodologia in Skills e Subagents), un secondo cervello (CLAUDE.md e una cartella plans/) e il context engineering (Plan Mode e /compact). Tutti e tre i componenti vanno progettati insieme: è questa combinazione che consente di lavorare con il contesto.

5 esempi in cui /goal funziona davvero#

La documentazione di Anthropic indica quattro tipi di attività per cui /goal è adatto:

Ecco cinque esempi con condizioni già pronte: copiale e adattale al tuo progetto.

Esempio 1. Migrare un modulo a una nuova API.

Scenario: stai passando da REST a GraphQL o sostituendo la vecchia funzione getUser() con la nuova fetchUser(). L’attività è meccanica, ma riguarda 30–50 file.

Condizione:

/goal ogni getUser() in src/ è stato sostituito con fetchUser(), tutte le chiamate sono state aggiornate alla nuova interfaccia (id invece di userId), npm test passa, nessun file fuori da src/ è stato toccato, oppure fermati dopo 30 turni

Perché funziona: lo stato finale può essere verificato con grep -r getUser src/ | wc -l (dovrebbe essere 0) e npm test exits 0. Il vincolo protegge i file di test.

Esempio 2. Correggere i test falliti.

Scenario: dopo l’aggiornamento di una libreria, 15 test non passano. Sai che la correzione è meccanica: aggiornare i mock e adattare le asserzioni al nuovo formato. Non vuoi farlo a mano.

Condizione:

/goal tutti i test falliti in test/ ora passano, npm test mostra i risultati nella chat con 0 errori, senza cancellare i test o commentare le asserzioni, oppure fermati dopo 25 turni

Un altro esempio dello stesso tipo di condizione:

Un altro esempio dello stesso tipo di condizione:

Correggi tutti i test falliti finché npm test non restituisce 0, senza modificare alcun file fuori dalla directory /auth

Esempio 3. Suddividere una classe monolitica.

Scenario: un unico file da 1.200 righe contiene tutto: il modello, il servizio, le utilità e il client API. Vuoi suddividerlo secondo il principio «un file, una responsabilità», aggiornare tutti gli import e mantenere i test superati.

Condizione:

/goal src/legacy/UserService.ts è stato suddiviso in file da meno di 200 righe; ogni file ha una sola responsabilità (model, repository, api-client, validator), tutti gli import sono aggiornati, npm run build è verde, i test esistenti passano, oppure fermati dopo 25 turni

Esempio 4. Smaltire le issue arretrate durante la notte.

Scenario: hai un repository open source con 20 issue etichettate good-first-issue. Vuoi che Claude le esamini durante la notte.

Condizione:

/goal elabora ogni issue con l’etichetta 'good-first-issue': leggi la descrizione, implementa una correzione in un ramo worktree separato worktree-issue-N, apri una PR con una descrizione. Continua finché la coda non è vuota o sono state elaborate 6 issue, oppure fermati dopo 80 turni

Il numero 6 non è stato scelto a caso: è un limite realistico per una notte con un piano Pro.

Esempio 5. Audit di sicurezza.

Scenario: npm audit mostra 8 vulnerabilità ad alta gravità. Vuoi che Claude le corregga senza aggiornare le versioni principali.

Condizione:

/goal ogni vulnerabilità di npm audit con gravità high+ è stata corretta, npm audit mostra 0 high nella chat, tutti i test esistenti passano, nessuna modifica incompatibile dell’API, nessun aggiornamento delle versioni principali dei pacchetti, oppure fermati dopo 15 turni

Cosa NON fare con /goal:

Croucher enuncia con forza la regola pratica nella sua guida sul campo: non usare /goal per attività in cui «finito» significa «sembra bello», «sembra giusto», «ben progettato» o «divertente». Il valutatore legge solo la trascrizione: non esegue strumenti e non può valutare come funziona il risultato. Questa regola esclude l’80% delle attività soggettive in cui /goal entra in loop senza produrre risultati utili.

Quando /goal fa sprecare soldi: 3 anti-pattern#

Anti-pattern 1. Condizione vaga senza un limite rigido di turni.

L’errore più comune è una condizione come «migliora il codice», «rendilo buono» o «ottimizzalo». Senza un limite di turni, l’agente continuerà a funzionare finché non esaurirà la tua quota.

Findskill ha descritto un caso reale:

200 $ in 14 ore per una condizione vaga corrispondono all’intero limite settimanale del piano Max. Ti svegli al mattino senza quota e senza un risultato utile.

Protezione: termina ogni condizione con or stop after N turns (15 per le attività facili, 50 per quelle difficili e 100 al massimo per le esecuzioni notturne).

Anti-pattern 2. Loop ricorsivo con cache non funzionante.

La storia del 22 maggio 2026: 6.000 $ in una notte perché Anthropic ha cambiato silenziosamente il TTL della cache da un’ora a 5 minuti. Lo sviluppatore non usava direttamente /goal, ma la logica era la stessa: un loop autonomo con un timer cron di 30 minuti ricostruiva ogni volta da zero una cronologia di 800.000 token.

Il problema principale era che l’automazione esterna non era al corrente delle modifiche interne del provider. Potrebbe succedere lo stesso con /goal se lo fai funzionare per 8 ore senza supervisione: l’uso dei token cresce in modo non lineare e la cache dei prompt non funziona come pensi.

Protezioni:

1. Non eseguire /goal per 8+ ore senza controlli intermedi.
2. Attiva i limiti di utilizzo in Settings → Usage (una nuova protezione dopo l’incidente da 6.000 $).
3. Apri claude agents due volte durante la notte: dai un’occhiata con Space e controlla che il numero di turni non cresca più rapidamente del previsto.
4. Per catene di modelli costose (Opus 4.7), imposta un limite di turni più rigido: massimo 30.

Anti-pattern 3. Creatività tramite /goal.

Croucher ha usato /goal per creare un gioco: la condizione includeva determinismo, invarianti e la verifica che il livello fosse superabile. Il gioco è stato creato, i test sono passati e il valutatore ha dichiarato «raggiunto». Il gioco era privo di elementi visivi: la condizione non menzionava la grafica.

Questo illustra la regola generale: il valutatore ottimizza esattamente ciò che misuri. Se la condizione non menziona gli elementi visivi, non ce ne saranno. Se menziona solo i test, potrebbe commentare le asserzioni.

Protezione: non usare /goal per nulla che dipenda dal gusto (design, copy, UX). Torna a una sessione normale o al Plan Mode: in questo modo resti nel ciclo decisionale.

Che cos’è Agent View e come aprire la dashboard#

Se /goal è il comando «lavora finché non hai finito», Agent View è la sala di controllo in cui puoi vedere tutti questi comandi contemporaneamente. Anthropic la descrive così:

Comando per aprirla:

claude agents

Si apre una TUI, una dashboard testuale nel terminale. L’elenco delle sessioni è a sinistra e il pannello peek, con l’ultimo messaggio della riga selezionata, è a destra.

Sei stati delle sessioni:

Scorciatoie principali:

↑ / ↓             spostarsi nell’elenco delle sessioni
Space             pannello peek (visualizza senza collegarti)
Enter / →         collegarsi a una sessione (entrarvi)
←                 scollegarsi (uscire senza terminarla)
Ctrl+T            fissare (proteggere la sessione dall’arresto automatico)
Ctrl+X            fermare la sessione; premi di nuovo entro 2 sec per eliminarla
Ctrl+R            rinominare
Ctrl+S            attivare/disattivare il raggruppamento (stato ↔ directory)

Come avviare una sessione in background:

Da Claude Code interattivo:

/bg fix the failing test test/auth/login.test.ts

Oppure direttamente dalla shell:

claude --bg "fix the failing test test/auth/login.test.ts"

Oppure con un nome, così compare in Agent View con un’etichetta riconoscibile:

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

La sessione in background viene aggiunta automaticamente ad Agent View: avviala con --bg, apri claude agents e la vedrai nell’elenco.

Funzionalità principale: le sessioni continuano a funzionare anche quando il laptop entra in sospensione o chiudi la finestra:

Ma se spegni il laptop o lo riavvii manualmente, le sessioni in background terminano con lo stato Failed. Le esecuzioni notturne con molti agenti in background funzionano solo su un laptop che non viene spento.

Worktree: come Claude isola le sessioni parallele#

I worktree risolvono il problema principale del lavoro autonomo in parallelo: cosa succede se due sessioni provano a modificare src/auth.ts contemporaneamente? Prima della versione 2.1.139, queste sessioni potevano sovrascrivere letteralmente le modifiche l’una dell’altra. Con Agent View, Anthropic ha introdotto l’isolamento automatico:

Come funziona in pratica:

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

Ogni sessione lavora nella propria copia. Quando l’attività è terminata, unisci i rami necessari in main.

Insidia pericolosa: eliminare una sessione elimina il suo worktree.

Se termini una sessione in Agent View (premi Ctrl+X due volte), il suo worktree scompare. Tutte le modifiche non salvate vanno perse. Prima di eliminare una sessione in Agent View, esegui sempre commit o push.

Disattivazione (in casi rari):

Se hai un repository in cui i git worktree non funzionano (per esempio, una configurazione con symlink o un grande monorepo con checkout lento), puoi disattivare l’isolamento:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

In questo caso le sessioni in background modificheranno direttamente la tua copia di lavoro. Questa opzione è arrivata nella versione 2.1.143 dopo le segnalazioni dei team con grandi monorepo.

Il parallelismo consuma la quota:

Questo significa che un piano Pro (20 $ al mese) basta per 1–2 sessioni parallele durante la notte, non per dieci. Se vuoi eseguire molti agenti in parallelo, ti serve Max o Enterprise.

Combinare /goal + Plan Mode + subagents per le attività lunghe#

Un errore tipico è digitare subito /goal build a new feature. Non funziona perché il valutatore non sa come appare una «funzionalità finita». Serve un piano con caselle di controllo che il valutatore possa verificare una per una.

Livello 1. Plan Mode crea un piano suddiviso in fasi.

In Plan Mode, chiedi a Claude di creare un piano dettagliato delle modifiche, suddiviso in 5–7 fasi con caselle di controllo verificabili. Salvalo come plans/2026-05-24-google-oauth.md. Ogni fase ha 3–7 caselle con azioni concrete.

Livello 2. I subagents suddividono il lavoro per fase.

Se il piano può essere parallelizzato (per esempio, le fasi sono indipendenti: un endpoint backend, un modulo frontend e una migrazione DB), puoi avviare ogni fase in una sessione in background separata tramite claude --bg --name "<phase>". Ogni sessione ha il proprio worktree.

Livello 3. /goal esegue il ciclo finché le caselle non sono completate.

/goal tutte le fasi da 1 a 7 in plans/2026-05-24-google-oauth.md sono complete e contrassegnate con [x], tutti i test in test/auth passano (npm test mostra 0 errori), npm run build è verde, oppure fermati dopo 50 turni

Dopo ogni turno, il valutatore legge il piano, controlla quali caselle sono completate e, se ne rimangono, l’agente continua.

Questa combinazione si basa su tre componenti:

• context engineering: il contesto corretto in plans/, che il valutatore legge
• secondo cervello: la cartella plans/ conserva il piano tra una sessione e l’altra
• clone IA: CLAUDE.md stabilisce le regole che l’agente segue

Senza CLAUDE.md, /goal potrebbe suggerire una soluzione che compromette l’architettura. Senza un piano in plans/, il valutatore non conosce i criteri di successo. Senza subagents, non ci sono fasi parallele: tutto procede in sequenza.

Come confrontare /goal con Codex, Cursor e altre modalità degli agenti#

/goal aggiunge una verifica separata del completamento dopo ogni turno. Gli altri prodotti hanno modalità diverse: una CLI locale, un’attività ospitata nel cloud e una sessione supervisionata nell’editor non sono unità di confronto intercambiabili. In particolare, non descrivere tutto il lavoro di Codex CLI come un container cloud e non presumere un unico modello valutatore o metodo di fatturazione per ogni esecuzione.

Usa lo stesso snapshot del repository e la stessa attività, con identici controlli di accettazione. Per ogni candidato registra:

Affermare che uno strumento consumi un multiplo fisso di token richiede queste condizioni e conteggi misurati per lo stesso risultato riuscito. Anche una percentuale di benchmark richiede versione del benchmark, modello, harness e impostazioni: le percentuali Terminal-Bench senza questi dettagli non sostituiscono tali prove. Questo articolo non offre un benchmark indipendente tra strumenti.

Scegli in base al flusso necessario: modifiche supervisionate, un’attività circoscritta in background o un lavoro su più turni con una condizione esplicita di completamento. Prova la modalità supportata dal prodotto installato senza presumere che un intero concorrente sia privo di autonomia. Separa autorizzazione dei permessi e continuazione dell’attività: approvare automaticamente una chiamata non dimostra che l’obiettivo dell’utente sia stato raggiunto.

/goal rispetto a /loop:

/loop è un altro comando della stessa versione e avvia attività periodiche a intervalli di tempo (ogni N minuti). /goal si basa su una condizione (finché non viene soddisfatta). Usa /loop per attività simili a cron e /goal per il raggiungimento di un obiettivo specifico.

Dalla documentazione di Anthropic:

Checklist pre-avvio di /goal: 7 elementi#

Checklist prima di ogni esecuzione di /goal:

1. Claude Code versione 2.1.139+: controlla con claude --version e aggiorna se è precedente. La versione minima consigliata è la 2.1.143 (15 maggio 2026), che corregge i loop degli hook di arresto.

2. La condizione include uno stato finale verificabile: invece di «miglioralo», specifica npm test exits 0. Se non riesci a trovare un comando bash per verificare il risultato, /goal non è adatto a questa attività.

3. È presente un limite rigido di turni: ogni condizione specifica or stop after N turns. Usa 15 per le attività facili, 50 per quelle difficili e 100 al massimo per le esecuzioni notturne.

4. I vincoli sono espliciti e circoscritti: without modifying files outside /auth, without removing existing assertions, without bumping major versions. Senza questi vincoli, Claude potrebbe correggere i test cancellandoli.

5. Tutte le modifiche importanti sono state sottoposte a commit o push: se non lavori in un worktree (per esempio, worktree.bgIsolation: "none"), Claude modifica la tua copia di lavoro. Un errore potrebbe farti perdere il lavoro non salvato.

6. I limiti di utilizzo sono attivi in Settings → Usage: una nuova protezione dopo l’incidente da 6.000 $. Imposta un limite giornaliero, per sessione e mensile.

7. Agent View claude agents è aperta in un’altra finestra: per le attività lunghe, dai un’occhiata con Space una volta all’ora. Se il numero di turni cresce più rapidamente del previsto o il valutatore ripete lo stesso motivo per tre turni, premi Ctrl+C e riformula la condizione.

Un altro elemento: non usare mai /goal con --dangerously-skip-permissions su codice di qualcun altro o che non conosci. Questa combinazione disabilita tutti i controlli e lascia che l’agente faccia ciò che vuole nel tuo progetto. L’autore di questa analisi lo usa solo in un worktree appena creato, in cui non c’è nulla da perdere.

/goal è una funzionalità potente, ma non è magica. Funziona bene quanto riesci a formulare la condizione. Se puoi descrivere a parole «finito» in modo che un comando lo verifichi, /goal farà il resto. Altrimenti, torna a una sessione normale o al Plan Mode.

Puoi continuare a esplorare Ailoot su ailoot.ai.