Codex dentro ChatGPT: la checklist prima di affidargli il tuo progetto

Cosa cambia davvero con Codex dentro ChatGPT

Dal 9 luglio 2026 la nuova app desktop di ChatGPT riunisce Chat, Work e Codex su macOS e Windows. La novità pratica non è un modello magico che “sa programmare meglio”: è una superficie unica nella quale puoi passare dalla conversazione al lavoro sul progetto, mantenendo più continuità tra contesto, file, modifiche e revisione.

Codex può lavorare su più repository nello stesso progetto, mentre tu scegli cartella e task da aprire. Questa comodità aumenta anche la probabilità dell’errore più banale: una richiesta corretta eseguita nel repository sbagliato. Il primo controllo non riguarda quindi il prompt, ma il percorso del progetto e lo stato Git.

Cosa può fare nel lavoro quotidiano

Nell’app desktop selezioni il progetto su cui lavorare. La documentazione ufficiale indica che Codex può leggere e modificare i file della cartella scelta: quindi codice, test, configurazioni consentite e file di testo come Markdown. La stessa app aggiunge modifica inline nel diff, revisione delle pull request nel pannello laterale e supporto a più repository in un progetto.

Il vantaggio concreto è un ciclo più corto: descrivi il problema, fai analizzare il codice, controlli la patch, lasci un’annotazione sulla riga interessata e chiedi una correzione senza ricostruire ogni volta il contesto. Il feedback resta affiancato al diff e diventa contesto per il turno successivo.

• Repository: esplorare struttura, dipendenze, test e convenzioni prima di scrivere.
• File: proporre modifiche circoscritte a codice, test e Markdown autorizzati.
• Annotazioni inline: commentare una riga del diff invece di descrivere vagamente “quella parte lì”.
• Pull request: supportare la review dal pannello laterale e controllare modifiche rispetto a una base.
• Continuità: proseguire dalla chat all’implementazione e alla review senza trasformare ogni passaggio in una nuova caccia al contesto.

Il controllo da fare in sessanta secondi

Prima di chiedere una modifica, fai produrre a Codex una fotografia dello stato iniziale e confrontala con ciò che ti aspetti. Il nome del progetto non basta: cartelle omonime, fork e worktree possono sembrare uguali nell’interfaccia.

Questo esempio usa nomi completamente sintetici. I comandi leggono soltanto lo stato del repository; non creano branch, commit o modifiche.

Progetto atteso: catalogo-demo
Percorso atteso: /Users/demo/progetti/catalogo-demo
Branch atteso: codex/correggi-hero

Prima di modificare, esegui e riporta:
- pwd
- git branch --show-current
- git status --short
- git remote -v, oscurando eventuali dati non necessari

Poi conferma:
- repository trovato
- branch corrente
- modifiche locali già presenti
- file che prevedi di toccare

Se percorso o branch non coincidono, fermati senza modificare file.

Cosa non significa

L’integrazione riduce i passaggi manuali, non la necessità di controllo. Codex può leggere una convenzione male, cambiare un file non previsto o produrre una patch plausibile che rompe un caso limite. Un diff elegante non è un certificato di correttezza.

Nemmeno una sessione lunga sostituisce uno scope. Se scrivi “sistema il progetto”, l’agente deve decidere da solo cosa significhi “sistema”. E quando più agenti lavorano insieme, moltiplicare le iniziative senza separare i file moltiplica soprattutto i conflitti.

• Non significa che ogni modifica proposta sia corretta.
• Non significa che Codex debba lavorare senza confini di file e comportamento.
• Non significa che test, review e verifica manuale siano diventati facoltativi.
• Non significa che un’approvazione richiesta sia un fastidio da disattivare.
• Non significa che il risultato dell’agente sia pronto per produzione appena la sessione termina.

Checklist prima di iniziare

Questa è la checklist minima da completare prima di autorizzare scritture o comandi. Se una voce non è verificabile, il task non è ancora pronto.

• Repository corretto: controlla percorso, remote e cartella radice; non fidarti soltanto del nome mostrato.
• Branch o worktree separata: evita il branch principale e isola i task paralleli in checkout diversi.
• Task circoscritto: definisci un risultato osservabile e indica file o cartelle consentiti e vietati.
• Secret esclusi: non incollare credenziali e verifica che file .env, chiavi, dump e configurazioni private non entrino nel contesto o nel diff.
• Criteri di accettazione: descrivi comportamento atteso, casi limite e cosa deve restare invariato.
• Test disponibili: indica comandi reali per unit test, lint, type check, build o verifica manuale.
• Rollback possibile: conserva lo stato iniziale, non sovrascrivere modifiche altrui e assicurati di poter scartare la patch senza perdere lavoro.

[ ] Repository, percorso e remote verificati
[ ] Branch principale escluso
[ ] Branch o worktree dedicata pronta
[ ] Obiettivo e scope consentito scritti
[ ] File e cartelle fuori scope scritti
[ ] Secret e dati sensibili esclusi
[ ] Criteri di accettazione verificabili
[ ] Comandi di test disponibili
[ ] Stato iniziale conservato e rollback possibile

Branch o worktree: quale usare

Per un solo task breve può bastare una branch dedicata. Se vuoi lavorare in parallelo o lasciare Codex in background, una worktree offre una seconda copia del repository con checkout separato. Nell’app desktop di ChatGPT le worktree servono proprio a eseguire task indipendenti senza disturbare il checkout locale.

La worktree non rende innocue due modifiche incompatibili. Se due task cambiano lo stesso componente, dovrai comunque scegliere un ordine, integrare con attenzione e rieseguire i test dopo l’unione. L’isolamento evita la collisione immediata; non risolve automaticamente quella logica.

1. Usa una branch dedicata quando esiste un solo flusso di modifica e vuoi lavorare nel checkout corrente.
2. Usa una worktree quando il task deve procedere in parallelo o vuoi mantenere pulito il lavoro locale.
3. Assegna a ogni sessione una responsabilità e un elenco di file; evita sovrapposizioni di scrittura.
4. Integra un task alla volta e rilancia i controlli sul risultato combinato.

Checklist prima di accettare la modifica

Quando Codex scrive “fatto”, il tuo lavoro cambia fase: da richiesta a verifica. Parti dal diff, non dal riassunto dell’agente. Il riassunto racconta l’intenzione; il diff mostra ciò che è successo.

• Controllo diff: leggi ogni modifica e confrontala con obiettivo e criteri di accettazione.
• File inattesi: usa git status e diff stat per individuare file generati, rinominati o toccati fuori scope.
• Test: controlla quali comandi sono stati eseguiti, risultato, durata e parti non testate.
• Dipendenze: verifica nuovi pacchetti, versioni, lockfile, licenze e motivazione dell’aggiunta.
• Configurazioni: cerca cambi a CI, build, deploy, permessi, variabili d’ambiente e infrastruttura.
• Secret: controlla diff e file non tracciati; un valore mascherato nel messaggio può essere ancora presente nel repository.
• Review manuale: prova il comportamento reale e chiedi una seconda lettura per le parti rischiose; test verdi e review AI non sostituiscono la responsabilità umana.

[ ] Diff letto riga per riga
[ ] File inattesi controllati
[ ] Test eseguiti e risultati verificati
[ ] Nuove dipendenze giustificate
[ ] Configurazioni e infrastruttura invariate o approvate
[ ] Nessun secret nel diff o nei file non tracciati
[ ] Comportamento provato manualmente
[ ] Review umana completata

Comandi di sola verifica:
git status --short
git diff --stat
git diff

# Poi esegui i comandi documentati dal progetto, per esempio:
# npm test
# npm run build

# Non creare commit finché diff e test non sono stati approvati.

Prompt copiabile per un task controllato

Compila i segnaposto e cancella le righe che non servono. Lo scope deve nominare ciò che l’agente può toccare; “solo i file necessari” è una formula comoda, ma decide tutto lui.

Analizza questo progetto prima di effettuare modifiche.

Obiettivo:
[DESCRIVI IL RISULTATO]

Scope consentito:
- [FILE O CARTELLE MODIFICABILI]

Fuori scope:
- [FILE O CARTELLE DA NON TOCCARE]
- configurazioni di produzione;
- credenziali;
- secret;
- infrastruttura non richiesta.

Prima di modificare:
1. descrivi l’approccio;
2. indica i file coinvolti;
3. segnala rischi e ambiguità;
4. verifica che il branch corrente non sia quello principale.

Durante il lavoro:
- applica modifiche minime;
- non introdurre dipendenze non necessarie;
- mantieni lo stile esistente;
- esegui i test disponibili.

Alla fine:
- mostra il diff;
- elenca i file modificati;
- segnala eventuali modifiche fuori scope;
- riporta test eseguiti e risultati;
- non creare commit senza approvazione esplicita.

Fonti ufficiali per Codex nell’app desktop

Le release note OpenAI del 9 luglio 2026 confermano la nuova app desktop di ChatGPT per macOS e Windows, con Chat, Work e Codex riuniti, modifica inline nel diff, review delle pull request e più repository in un progetto. Le checklist applicano inoltre le raccomandazioni ufficiali su scope, test, sandbox e approvazioni.

• OpenAI: ChatGPT release notes del 9 luglio 2026 ↗
• OpenAI: best practice per lavorare con Codex ↗
• OpenAI: approvazioni, sandbox e sicurezza di Codex ↗
• DottorLone: Agent Data Injection e sicurezza dei coding agent →

La regola da portarsi via

Codex può accorciare il tragitto tra domanda, modifica e review. La responsabilità su repository, permessi, qualità e pubblicazione però non cambia proprietario.