Codex Automations per le attivit脿 lunghe: trigger programmati, heartbeat e lavoro su pi霉 giorni

Se affidi a Codex controlli ripetitivi, tracciamento di PR, follow-up dopo il deploy e triage su pi霉 giorni, la prima domanda non 猫 se si pu貌 automatizzare. 猫 quale tipo di attivit脿 merita automazione e come farlo. Automations non trasforma Codex in un agente sempre acceso in background. Lo riporta semplicemente al momento giusto, dentro il perimetro giusto, per fare una sola cosa ben definita.

1. Prima giudica se l’attivit脿 va automatizzata

1.1 standalone/project automation: lavori in background indipendenti

Standalone automation e project automation sono entrambi lavori in background indipendenti. La differenza riguarda l’ambito. Standalone non 猫 legata a un progetto preciso; project automation 猫 vincolata a un percorso di progetto, quindi si adatta meglio a lavori ricorrenti attorno a un repository fisso.

Ogni trigger avvia un’esecuzione nuova. Quando termina, il risultato va in inbox o triage; se non c’猫 nulla di nuovo, pu貌 essere archiviato automaticamente. I casi d’uso tipici sono controlli settimanali delle dipendenze, triage giornaliero delle issue e controlli pianificati dopo un deploy.

Il limite principale 猫 l’ambiente locale: la macchina che esegue Codex deve restare accesa, l’app deve continuare a girare e il percorso del progetto deve esistere. Se la macchina va in sospensione, si spegne o l’app si chiude, non va avanti. Non 猫 il livello giusto per hosting senza supervisione a lungo termine.

1.2 thread automation (heartbeat): wakeup periodici sullo stesso thread

Thread automation 猫 un wakeup periodico in stile heartbeat agganciato al thread di conversazione corrente. L’idea centrale 猫 preservare il contesto: a ogni risveglio la stessa conversazione continua invece di creare una nuova esecuzione indipendente.

Va bene per controlli dei log dopo il deploy, follow-up di pi霉 giorni e triage continuo. Per esempio, puoi chiedere a Codex di controllare i log di deploy ogni 10 minuti, avvisare solo quando vede un errore o un successo e restare in silenzio altrimenti. Questo tipo di lavoro ha bisogno di continuit脿 del contesto, quindi standalone automation non 猫 la scelta giusta.

Heartbeat non 猫 un daemon permanente n茅 un forever loop. 猫 un ritmo di risveglio -> controllo -> report -> attesa. Se l’app si mette in pausa o si chiude, anche il heartbeat si ferma.

1.3 Tabella di confronto

Dimensione	standalone/project automation	thread automation (heartbeat)
Posizione di esecuzione	Thread di background indipendente	Thread di conversazione corrente
Conservazione del contesto	Contesto nuovo a ogni esecuzione	Conserva il contesto della sessione corrente
Casi d’uso adatti	Lavori ripetitivi indipendenti, triage delle issue, controlli sulle dipendenze	Follow-up di lavori lunghi, triage continuo, log dopo deploy, lavoro su pi霉 giorni
Dipendenze	Devono esistere app locale / macchina / percorso del progetto	Il thread corrente deve restare collegato
Superficie del risultato	inbox / triage, archiviazione automatica se non c’猫 nulla	Finestra della conversazione corrente
Meccanismo di stop	Disattivare l’automazione	Mettere in pausa o chiudere l’app

La decisione 猫 semplice: l’attivit脿 deve mantenere il contesto? Se s矛, usa thread automation. 猫 legata a un progetto preciso? Se s矛, usa project automation; altrimenti standalone automation.

2. Quali attivit脿 si adattano a Automations

Non tutte le attivit脿 ripetitive meritano Automations. Prima guarda la forma del lavoro.

2.1 Caratteristiche delle attivit脿 adatte

Le attivit脿 adatte ad Automations di solito hanno tre caratteristiche: alta ripetizione, regole chiare e output verificabile.

Il lavoro molto ripetitivo compare con un ritmo fisso e punta praticamente allo stesso risultato ogni volta. I controlli settimanali delle dipendenze, il triage giornaliero delle issue e le verifiche fisse dopo i deploy sono buoni esempi. Ambito di controllo, criteri di decisione e formato di output possono essere definiti in anticipo.

Le attivit脿 basate su regole si trasformano molto bene in prompt. Per esempio: “Controlla le versioni in package.json, elenca i pacchetti con nuove versioni e consiglia un ordine di aggiornamento.” I criteri di giudizio restano stabili, quindi non c’猫 bisogno di ripeterli ogni volta.

Anche l’output verificabile conta. Una buona automazione deve tornare in inbox / triage, archiviarsi da sola quando non c’猫 nulla da fare e mostrare chiaramente il passo successivo quando trova qualcosa. Cos矛 capisci se sta davvero facendo risparmiare tempo invece di spostare il rumore altrove.

2.2 Caratteristiche delle attivit脿 che non si adattano

Le attivit脿 che non si adattano ad Automations di solito hanno quattro caratteristiche: richiedono giudizio umano frequente, dipendono da uno stato esterno che cambia in fretta, il prompt non 猫 ancora stabile oppure richiedono hosting senza supervisione per lungo tempo.

Le attivit脿 che richiedono spesso giudizio umano tendono ad avere confini sfumati. Decisioni architetturali, caccia a bug complessi e trade-off situazionali richiedono tutti adattamento al caso, quindi si adattano male a un’automazione rigida.

Anche le attivit脿 che dipendono da uno stato esterno che cambia rapidamente chiedono cautela. Il monitoraggio in tempo reale di un servizio di produzione, per esempio, cambia troppo in fretta ed 猫 pi霉 adatto a strumenti di osservabilit脿 specializzati che ad Automations.

Non automatizzare nemmeno un prompt che non si 猫 ancora provato. Fallo girare manualmente un po’ di volte, stabilizza regole, ambito e output, e solo dopo trasformalo in automazione.

L’hosting senza supervisione a lungo termine non 猫 il livello giusto per una project-scoped automation. Dipende dall’app locale, dalla macchina e dal percorso del progetto. Se la macchina sparisce, l’automazione si ferma. Non 猫 una soluzione cloud.

2.3 Tabella di compatibilit脿

Tipo di attivit脿	Adatta?	Motivo	Approccio consigliato
Controlli settimanali delle dipendenze	S矛	Ripetitiva, basata su regole, verificabile	standalone automation o project automation
Triage giornaliero delle issue	S矛	Pu貌 andare in inbox, pu貌 essere archiviata automaticamente, il prompt 猫 stabile	standalone automation o thread heartbeat
Controlli dei log dopo deploy	S矛	Stesso thread, il contesto conta	thread automation
Decisioni architetturali	No	Serve giudizio umano frequente, i confini sono sfumati	conversazione manuale
Caccia a bug complessi	No	Serve adattamento situazionale	conversazione manuale
Monitoraggio in tempo reale	No	Lo stato esterno cambia troppo in fretta	strumenti di osservabilit脿 specializzati
Hosting senza supervisione a lungo termine	No	La project-scoped automation dipende dall’ambiente locale	approccio CI o cloud
Flussi di automazione non testati	No	Prompt instabile, esecuzioni manuali incoerenti	stabilizzare prima manualmente

Il flusso decisionale 猫 semplice: prima verifica se il prompt 猫 stabile, poi chiediti se l’attivit脿 deve mantenere il contesto e infine se ti serve davvero hosting cloud duraturo.

3. Creare la tua prima standalone/project automation

3.1 Flusso di creazione

1. Scrivi prima l’attivit脿 in modo chiaro. Definisci ambito, input, output, criteri di successo e condizioni di stop.
2. Scegli il tipo di automazione. Il lavoro ripetitivo indipendente va in standalone; il lavoro ripetitivo attorno a un repository fisso va in project automation.
3. Scegli la posizione di esecuzione. In un repository Git, inizia con un worktree per non disturbare il workspace corrente.
4. Definisci la frequenza. Le attivit脿 a intervalli di minuti hanno bisogno di condizioni di stop esplicite per non svegliarsi all’infinito.
5. Fai prima alcuni cicli di prova. Quando l’output 猫 stabile, passa alla frequenza reale.

3.2 Come scegliere tra worktree e local project

Posizione di esecuzione	Isolamento	Casi adatti	Rischio
worktree	Le modifiche restano isolate dal directory corrente	Attivit脿 che modificano file, scrivono codice o propongono PR	Gli errori di solito restano dentro il worktree e si buttano via facilmente
local project	Nessun isolamento; esecuzione diretta nella directory corrente	Controlli in sola lettura, generazione di report, triage	Pu貌 influire sui file che stai modificando

Nei repository Git, le attivit脿 di modifica dovrebbero partire in un worktree. Usa local project solo quando l’attivit脿 猫 esplicitamente di sola lettura, ispezione o conferma.

4. Creare thread automation (heartbeat)

4.1 Flusso di creazione

1. Verifica prima che il thread corrente stia gi脿 gestendo un lavoro lungo.
2. Poi collega la thread automation a quel thread.
3. Scrivi esattamente cosa deve controllare a ogni wakeup, quando deve riportare e quando deve restare in silenzio.
4. Definisci condizioni di stop: successo, fallimento, timeout o numero massimo di round.
5. Parti con frequenza bassa e verifica che non faccia spam prima di passare al ritmo finale.

4.2 Esempio di prompt heartbeat

Controlla i log di deploy ogni 10 minuti e riporta solo in questi casi:

1. Appare un segnale di errore (contiene "error", "failed" o "exception")
2. Appare un segnale di completamento (contiene "deployed", "success" o "completed")
3. Sono passati 30 minuti e non 猫 ancora finito

Formato del report:
- Status: [in progress / success / failure]
- Estratto chiave del log: [fino a 3 righe]
- Prossimo passo: [se presente]

Rimani in silenzio quando non cambia nulla.

Questo prompt rende espliciti ambito di controllo, confine di output e condizioni di stop. Non serve ripetere “verifica completata” a ogni wakeup, n茅 trasformare l’assenza di cambiamenti in rumore.

5. Sicurezza: sandbox, approval policy e governance del team

5.1 Impostazioni sandbox e approval policy

Automations gira per default dentro una sandbox. La sandbox decide quali file pu貌 toccare, se pu貌 oltrepassare i confini e se serve approvazione aggiuntiva. Per l’automazione in background, pi霉 il perimetro predefinito 猫 piccolo, meglio 猫.

Modalit脿 sandbox	Ambito dei permessi	Adatta a	Livello di rischio
read-only	Solo lettura, nessuna scrittura	Ispezione e analisi pure	Basso
workspace-write	Lettura/scrittura nel workspace; le azioni esterne richiedono ancora approvazione	Automazioni quotidiane, modifiche a file, suggerimenti di PR	Medio
danger-full-access	Accesso al sistema senza restrizioni	Ambienti isolati o attivit脿 molto fidate	Alto

La approval policy controlla se l’agente deve chiedere permesso quando incontra un’azione pi霉 rischiosa.

approval policy	Comportamento	Caso d’uso
on-request	Chiede permessi superiori quando serve	Un po’ di autonomia, ma con revisione umana
never	Esegue tutto automaticamente, senza chiedere	Script di automazione o ambienti non interattivi

La raccomandazione predefinita dovrebbe essere workspace-write + rules/allowlist, non full access + unattended. La seconda opzione 猫 troppo ampia quando qualcosa va storto.

5.2 Consiglio di governance

I team possono fissare sandbox e approval in requirements.toml per evitare che qualcuno conceda troppi permessi per errore.

[agent]
approval_policy = "never"
sandbox = "workspace-write"

L’obiettivo non 猫 bloccare tutto. L’obiettivo 猫 tenere stretto il confine predefinito ed espanderlo solo quando il lavoro ne ha davvero bisogno.

6. Tre modelli di automazione pronti da usare

6.1 Revisione settimanale delle dipendenze

• Frequenza di trigger: una volta a settimana
• Posizione di esecuzione: worktree da preferire nei repository Git
• Output riuscito: elenco delle dipendenze aggiornabili e priorità suggerite
• Condizione di stop: se non c’猫 nulla da aggiornare, mantieni il risultato breve
• Limite dei permessi: sola lettura o report leggero

6.2 Follow-up heartbeat dopo il deploy

• Frequenza di trigger: ogni 10 minuti, fino a 30 minuti
• Posizione di esecuzione: thread automation
• Output riuscito: riepilogo breve di successo, fallimento o timeout
• Condizione di stop: segnale di successo, segnale di fallimento o timeout
• Limite dei permessi: leggere solo i log, non toccare la produzione

6.3 Triaging giornaliero di issue / PR

• Frequenza di trigger: una volta al giorno
• Posizione di esecuzione: standalone automation o thread heartbeat
• Output riuscito: mettere in inbox ci貌 che richiede attenzione umana
• Condizione di stop: restare in silenzio quando non c’猫 nulla di nuovo
• Limite dei permessi: per default workspace-write; evitare full access

7. Se l’automazione fallisce, controlla prima queste 6 cose

1. L’app Codex 猫 ancora in esecuzione e la macchina 猫 sveglia?
2. Il percorso del progetto esiste ancora o il worktree 猫 stato spostato / rimosso?
3. La sandbox sta bloccando scritture o rete?
4. La thread automation ha davvero bisogno di mantenere il contesto?
5. Il worktree si 猫 accumulato troppo e va ripulito?
6. Il prompt dice chiaramente quando fermarsi e quando riportare?

8. Checklist FAQ

8.1 Automations 猫 una task programmata o un agente sempre attivo?

Somiglia pi霉 a un lavoro in background programmato o risvegliato periodicamente. A ogni wakeup controlla, lavora, informa e poi torna in attesa. Non 猫 un forever loop.

8.2 Qual 猫 la differenza tra standalone/project e thread automation?

Standalone/project automation 猫 un’esecuzione di fondo indipendente che riparte da zero ogni volta, e il risultato va in inbox / triage. Thread automation 猫 un heartbeat sullo stesso thread e conserva il contesto della conversazione attuale.

8.3 Quali attivit脿 si adattano a Automations e quali no?

Quelle adatte sono ripetitive, basate su regole e verificabili. Quelle inadatte richiedono giudizio umano frequente, dipendono da uno stato esterno che cambia in fretta o hanno prompt instabili.

8.4 Come scelgo tra worktree e local project?

Per tutto ci貌 che pu貌 modificare file, privilegia worktree. Usa local project solo per controlli in lettura e attivit脿 di tipo report.

8.5 Continua se chiudo l’app o il computer dorme?

No. L’automazione legata al progetto dipende dall’app locale, dalla macchina e dal percorso del progetto. Se l’app si chiude o la macchina dorme, si ferma.

8.6 Quando dovrei usare Computer Use?

Solo quando devi operare direttamente una GUI e non esistono API o interfacce web. Se il codice normale basta, di solito non ne vale la pena.

8.7 Come controllo costo e frequenza?

Tieni la frequenza solo al livello necessario, controlla lo stato con /status, definisci condizioni di stop per ogni automazione e evita il polling eccessivo.

9. Riassunto

Computer Use, il browser integrato e Automations risolvono livelli diversi dello stesso problema. Automations serve a dare a Codex lavoro stabile, verificabile e ripetitivo in background; thread automation serve a seguire lavori lunghi su pi霉 giorni; worktree e sandbox servono a tenere sotto controllo il rischio.

L’ordine pi霉 sicuro 猫 sempre lo stesso: prima giudicare se il lavoro va automatizzato, poi scegliere posizione di esecuzione e permessi, e solo dopo regolare la frequenza. Prima rendi stabile il processo umano, poi lascia che Codex lo faccia girare un po’ pi霉 a lungo.