Prepara Codex intorno al tuo lavoro

Percorso guidato aggiornato il 6 settembre 2026. Non partiamo dai plugin: partiamo da te. Alla fine avrai una cartella di lavoro, una mappa dei tuoi software, lo stato reale dei collegamenti e una prima procedura da provare.

Due percorsi: in aula usiamo dati sintetici e nessun account aziendale è necessario. Nella personalizzazione individuale puoi collegare servizi reali solo dopo aver verificato autorizzazioni, trattamento dei dati e permessi. Non occorre collegare tutto per procedere.

Il percorso, in breve

  1. Ti conosco: chi sei, cosa fai e com'è la tua giornata.
  2. Mappiamo gli strumenti: dove passano informazioni e attività.
  3. Prepariamo il banco: accesso, progetto, cartella, permessi, primo salvataggio.
  4. Colleghiamo ciò che serve: plugin prima, altrimenti valutiamo MCP, API o file.
  5. Estraiamo il tuo metodo: seconda intervista su un processo reale.
  6. Costruiamo e proviamo una skill: risultato, feedback, modifica e riprova.

Usa il prompt tutor completo, disponibile anche nella libreria Prompt e risorse, e la scheda di onboarding. Il tutor fa una domanda alla volta, non mostra l'intero questionario e non avanza senza un riepilogo confermato. Puoi saltare una domanda o fermarti; ciò che manca resta «da chiarire».

Se Codex non è ancora installato: la prima intervista si fa con il docente, a coppie o su una nota locale. Se vuoi il tutor dentro Codex, esegui prima soltanto download e login descritti nella scheda tecnica qui sotto, poi comincia l'intervista. Non servono collegamenti per parlare del tuo lavoro.

Fase A — Prima la persona, poi i software

Non è un test di personalità e non richiede informazioni intime. Servono solo dettagli utili per aiutarti a lavorare.

Domande per orientarsi

Approfondisci una risposta concreta prima di passare al tema successivo. Per le attività ricorrenti raccogli frequenza, input, risultato atteso, destinatario, strumenti, fastidio principale e rischio in caso di errore. Tempo impiegato e risparmio desiderato sono stime dichiarate dalla persona, non numeri inventati dall'agente.

Checkpoint A: la persona riconosce il riepilogo e corregge eventuali interpretazioni. Seleziona una prima attività frequente, delimitata, verificabile e a basso rischio. Non «gestire tutta l'azienda».

Fase B — Una mappa ragionata dell'ecosistema

Parti dai software emersi nel racconto, poi controlla le categorie mancanti. La lista è un promemoria per il tutor, non un interrogatorio da leggere tutto insieme. «Non lo uso» è una risposta completa.

Per ogni software salva: nome esatto, uso concreto, servizio/backend (non solo il client), piano se noto, sistema operativo o web, account/organizzazione descritti senza segreti, referente IT, dati coinvolti, letture desiderate, scritture desiderate, priorità ed eventuali limiti aziendali. Non chiedere password, token, dati bancari o archivi clienti nell'intervista.

Checkpoint B: inventario confermato, categorie non usate segnate, una piccola priorità di collegamento legata alla prima attività. La ricerca copre tutti i software censiti; l'installazione parte solo da quelli necessari.

Fase C — Il banco di lavoro: progetto, cartella e informazioni salvate

Segui la scheda tecnica in fondo per download ufficiale, login, piano e permessi. Il percorso principale è l'app desktop, non il terminale.

  1. Crea con il gestore file una cartella nuova e dedicata, per esempio Il-mio-assistente. Non scegliere l'intero computer o un archivio clienti. In aula usa la copia di Laboratorio-Faro.
  2. Nell'app crea o apri un progetto locale e seleziona quella cartella con il controllo disponibile nel client. Se etichette o funzioni differiscono, consulta l'aiuto ufficiale: non cercare pulsanti immaginari. Se il progetto contiene più cartelle, verifica quale è primaria: determina la directory iniziale e la discovery automatica di istruzioni e skill. Un progetto con soli file caricati non equivale a una cartella locale.[2]
  3. Controlla il percorso mostrato. Chiedi a Codex di indicare cartella corrente e file presenti senza modificarli; confronta col gestore file. Se non corrispondono, fermati e correggi la selezione.
  4. Predisponi contesto/, input/ e output/ nella nuova cartella, solo dopo aver approvato il piano di creazione. Sono una convenzione del workshop, non cartelle magiche di Codex. Nel kit mantieni anche le directory originali.
  5. Rivedi il riepilogo dell'intervista: elimina dettagli inutili e correggi ipotesi. Chiedi esplicitamente di salvare profilo, inventario e stato in contesto/onboarding.md, senza sovrascrivere un file esistente. Le risposte dell'intervista non devono finire tutte automaticamente in memoria.
  6. Chiedi un AGENTS.md breve con obiettivo, confini, percorsi del contesto da consultare e conferme per azioni esterne. Prima controlla eventuali istruzioni già presenti. Non copiarvi password o l'intera conversazione. Per i dettagli vedi la sezione tecnica e la guida M3.
  7. Fai creare un piccolo output di prova in output/, poi aprilo davvero. In una nuova conversazione dello stesso progetto chiedi di leggere contesto/onboarding.md e riassumere il punto di ripresa. Confronta con il file.

Salva il riepilogo che ho approvato in contesto/onboarding.md. Prima controlla se esiste: se c'è, mostrami la modifica proposta. Separa fatti confermati, dubbi e prossimo passo. Non includere segreti. Al termine indicami il percorso e verifica che il file sia leggibile.

Idea da portare a casa: per questo percorso la cartella è il banco di lavoro e rende controllabili contesto e risultati. Non è un'affermazione che ogni funzione di Codex richieda sempre una cartella locale. Una chat o «ricordatelo» non sostituiscono un salvataggio verificato. La memoria opzionale è distinta dai file.

Sbloccare non significa togliere ogni protezione. Se qualcosa si ferma, identifica l'ostacolo: login, limiti del piano, progetto sbagliato, accesso ai file, rete, permesso dello strumento o policy IT. Risolvi quel problema specifico; non usare Full access come rimedio universale.

Checkpoint C: progetto corretto, file salvato e riaperto, ripresa provata in una nuova chat, permessi compresi. Login o scrittura non disponibili? Segna il blocco e continua su carta o a coppie, senza chiamarlo collaudo individuale.

Fase D — Collegare, con prove e senza promesse

Per ogni software censito consulta fonti aggiornate: catalogo/marketplace disponibile in Codex, documentazione ufficiale del servizio e documentazione Codex. Annota URL, data, capacità effettive, requisiti di piano/account, costi noti e ciò che resta incerto. Un risultato di ricerca o il nome del servizio in un catalogo non provano l'accesso ai dati richiesti.

1. Esiste un plugin adatto in Codex?

Suggerisci prima questa strada se il plugin è compatibile, affidabile e copre l'attività. Controlla editore, autenticazione, account, permessi e operazioni supportate. Installare un plugin non significa aver collegato l'account, né che tutte le funzioni del software siano esposte. Dopo il consenso, guida l'utente nella procedura mostrata nel suo client; login e OAuth li completa personalmente. Non duplicare collegamenti già funzionanti. Dopo l’installazione apri una nuova chat come indicato dalla guida ufficiale. Per revocare l’accesso controlla anche il connettore/account: disinstallare il plugin non scollega automaticamente i connettori.[6]

2. Niente plugin adatto, ma esiste un server MCP compatibile?

Spiega: «Possiamo valutare un collegamento manuale. Vuoi che ti accompagni passo per passo?». Non partire dall'installazione. Se accetta, prepara una guida specifica per quel servizio e quel sistema, usando endpoint e comandi documentati. Distingui server ufficiale da comunitario, remoto da locale, OAuth da chiave e prerequisiti tecnici. Una sola azione per passo, risultato atteso, verifica e percorso per revocare il collegamento. Non inventare un endpoint o chiedere di incollare segreti in chat.

3. Esistono API, ma nessun MCP pronto?

Comunica: «Il servizio espone API, ma non ho verificato un collegamento pronto per Codex. Serve un'integrazione dedicata o un adattatore da valutare». Non confondere l'assenza di MCP con l'impossibilità di integrare. Costi, manutenzione, autenticazione e autorizzazione rendono questo un progetto tecnico separato, non un requisito del primo avvio. Un eventuale servizio intermediario va valutato come un nuovo soggetto che tratta i dati.

4. Non emerge un collegamento utilizzabile?

Distingui non trovato, non disponibile per questo piano/account, vietato dalla policy e assenza dichiarata dal fornitore. Spiega il limite senza trasformare una ricerca inconcludente in certezza. Proponi export CSV/PDF, copia autorizzata o input manuale: indicare sempre fonte, data e mancata sincronizzazione automatica. L'automazione del browser non è il fallback predefinito: fragile, da autorizzare e valutare separatamente.

Registro e prima prova

Per ogni collegamento usa stati separati: da verificare → disponibile documentato → autorizzato → configurato → testato, oppure bloccato / rinviato / fallback file. Aggiungi metodo, capacità richieste, account previsto senza segreti, evidenza, errore e prossimo passo.

Inizia da una lettura minima autorizzata su un elemento di prova identificabile, non dall'intera casella. Prima verifica che l'account sia quello giusto e poi confronta il risultato con il servizio originale. Registra data, strumento, oggetto, risultato atteso e risultato osservato. In aula la simulazione si chiama simulazione, non connessione testata. Nessuna scrittura è necessaria per completare questa fase; invii, eventi, pubblicazioni e operazioni amministrative richiedono approvazione specifica e verifica sul servizio dopo l'azione.

Checkpoint D: tutte le voci hanno uno stato onesto; il collegamento prioritario ha una prova di lettura riuscita oppure un fallback esplicito. Un software bloccato non impedisce di costruire una skill che lavora su file.

Fase E — Seconda intervista: come fai davvero quel lavoro?

Ora riprendi una sola attività dalla mappa, senza rifare l'intervista personale. Se non hai mai provato Codex su un output verificabile, fai prima la prova sintetica della guida laboratorio.

Per ogni passaggio collega input → strumento → azione → controllo → output. Distingui ciò che fai tu da ciò che vuoi delegare. Con un collegamento mancante sostituisci il passaggio con un export o una consegna manuale dichiarata; non scrivere una skill che finge strumenti inesistenti.

Checkpoint E: procedura restituita e approvata, dipendenze reali, eccezioni, confini e criteri osservabili. Prima prova la procedura su un caso; solo dopo rendila riusabile.

Fase F — La prima skill e il ciclo di miglioramento

Segui Insegna all'agente a fare il tuo lavoro: contiene template, percorso .agents/skills/<nome>/SKILL.md, prova di riconoscimento e registro tentativi.

La skill deve dire quando usarla e quando no, input necessari, collegamenti richiesti o fallback, passi, domande sui dati mancanti, eccezioni, output e criteri di verifica. Scrivere il file non equivale a installazione riconosciuta o procedura collaudata. Il formato richiede name e description.[4] Le cartelle .agents e .codex esistenti possono essere protette in sola lettura nel sandbox workspace-write: se il salvataggio richiede un permesso aggiuntivo, approva solo l’operazione circoscritta oppure salva manualmente, senza allargare tutti gli accessi.[8]

  1. Conserva una prima versione e il suo output su input sintetico o autorizzato.
  2. Valuta con criteri decisi prima. «Va bene» è utile se spieghi che cosa va mantenuto; «è sbagliato» deve localizzare l'errore.
  3. Chiedi una modifica circoscritta alla skill, vedi il cambiamento e approvalo. Un feedback lasciato soltanto in chat non dimostra un aggiornamento persistente.
  4. Salva la revisione, conserva il prima/dopo e riprova lo stesso caso in una nuova conversazione.
  5. Prova anche un caso nuovo, dati incompleti e una richiesta fuori ambito. Controlla che la correzione non rompa il caso già riuscito.

Qui funziona bene [comportamento]: mantienilo perché [criterio]. Qui è sbagliato [punto]: mi aspettavo [risultato verificabile], come mostra [fonte/esempio]. Proponi una sola modifica alla skill e attendi la mia conferma. Dopo il salvataggio riproviamo lo stesso input e un caso diverso, senza cambiare gli output precedenti.

Checkpoint finale: sai aprire il progetto giusto, ritrovare il contesto salvato, distinguere collegamenti testati da ipotesi, richiamare la procedura e dare feedback che diventi una modifica verificata. Una skill che passa un caso non è «pronta per qualunque situazione»: registra limiti e prossima prova. Poi scegli, se serve, una seconda attività.

Scheda tecnica di riferimento — installazione e configurazione

Verifica documentale: 5 settembre 2026. Percorso principale app desktop, non terminale. Questa guida descrive la documentazione corrente: il rendering dell'app e il login sul computer del partecipante devono essere provati prima dell'aula.

1. Scaricare e accedere

  1. Apri la pagina ufficiale dell'app e segui il download per il tuo sistema operativo, oppure chatgpt.com/download.
  2. Installa soltanto su un computer autorizzato. Se servono permessi IT, chiedili: non disabilitare protezioni per procedere.
  3. Accedi personalmente con il tuo account ChatGPT. Non condividere password, codici OAuth o credenziali con docente o compagni.
  4. La documentazione corrente presenta ChatGPT desktop: scegli Codex dal selettore. ChatGPT Chat, Work e Codex non sono nomi intercambiabili. Il corso usa Codex per organizzare un assistente con file e istruzioni; Work è il percorso generalista documentato per ricerca e deliverable.
  5. Apri soltanto la cartella di laboratorio predisposta secondo LABORATORIO.md. Non scegliere la home, Desktop o l'archivio clienti.

Sistemi operativi

2. Login incluso o chiave API?

Autenticazione ufficiale.

Sign in with ChatGPT usa l'accesso del piano, con limiti e funzionalità applicabili. API key usa fatturazione API e non equivale automaticamente al consumo incluso nell'abbonamento. Per il percorso base non chiediamo di creare chiavi API.

Controlla il piano e la disponibilità sul tuo account prima dell'aula: non promettiamo quote fisse o uso illimitato. Piani e Codex. Nella documentazione corrente sono presenti anche piani Free e Go; non è corretto imporre Plus come requisito universale senza verificare.

3. Capire i permessi

Modalità di permesso e sicurezza/sandbox.

Le opzioni possono dipendere da configurazione e policy dell'organizzazione. Le istruzioni «non modificare» guidano il comportamento, ma non creano da sole un recinto tecnico.

Prima di approvare un'azione leggi: quale strumento viene usato, su quali file, che cosa sarà modificato e dove andranno eventuali dati. Se non lo capisci, chiedi una spiegazione e nega finché il perimetro non è chiaro. Nessun invio, pubblicazione, acquisto, cancellazione o deploy nella prova base.

4. Prima prova

Nella cartella di prova, usa il prompt Codex · orientarsi senza scrivere della libreria. Confronta la risposta con i file presenti e le azioni mostrate nell'interfaccia. Una dichiarazione del modello non dimostra che ogni fonte sia stata letta.

Solo quando sai che cosa verrà creato, passa alla scrittura circoscritta dell'output. Apri il file davvero e controlla una citazione tornando alla fonte. Se il login o la possibilità di lavorare sui file non sono disponibili, usa il percorso a coppie; non dichiarare completata l'esecuzione individuale.

5. Il banco di lavoro: istruzioni, skill, plugin, memoria e MCP

Due componenti da distinguere

Nel primo modulo impari a riconoscere questi componenti. Nel secondo costruisci l’agente con file e istruzioni. Nel terzo li metti al lavoro sul tuo metodo: guida knowledge, skill e memoria.

6. Novità verificate e limiti della versione

Appendice tecnica: CLI, solo per chi la vuole

Queste alternative sono documentate, non una sequenza da eseguire integralmente. Non installano nulla leggendo questa guida.

# Alternativa npm: Node/npm devono essere già disponibili
npm install -g @openai/codex
# In alternativa su un sistema Homebrew autorizzato
brew install --cask codex

Dalla cartella del laboratorio:

codex --version
codex --help
codex login
codex --sandbox read-only --ask-for-approval on-request

Per passare alla produzione di file solo nel workspace di prova:

codex --sandbox workspace-write --ask-for-approval on-request

Nella sessione CLI, /permissions permette di ispezionare le impostazioni. workspace-write può modificare file ed eseguire comandi entro il perimetro senza una richiesta per ogni azione. Non usare --yolo o bypass di sandbox come soluzione ai problemi.

Le vecchie guide con approval_policy = "untrusted" sono obsolete dalla CLI 0.149.0 secondo il supporto corrente. È diverso dal trust_level del progetto. Verificare sempre --help della versione effettiva.

Privacy

“Locale” non significa “offline”. File e istruzioni possono essere inviati al servizio del modello. Piano, controlli sui dati, logging, retention e servizi terzi hanno regole proprie. Disabilitare l'uso per training non equivale automaticamente a zero retention o conformità aziendale. Usare soltanto i dati sintetici del kit finché l'organizzazione non approva il caso reale.

Sources

[2] https://learn.chatgpt.com/docs/projects.md — projects [4] https://learn.chatgpt.com/docs/build-skills.md — skills [6] https://learn.chatgpt.com/docs/plugins.md — plugins [8] https://learn.chatgpt.com/docs/agent-approvals-security.md — approvals