Chi utilizza ogni giorno Codex Desktop sa bene che, dopo qualche settimana di lavoro, una conversazione non è più soltanto una chat. Diventa la memoria del progetto. È lì che si trovano le decisioni architetturali, le motivazioni dietro certe scelte, le alternative scartate, i problemi già risolti e tutto quel contesto che sarebbe praticamente impossibile ricostruire da zero.
Per questo motivo, quando ho aperto Codex Desktop e mi sono accorto che un progetto non esisteva più e, insieme ad esso, era sparita anche la conversazione, il primo pensiero è stato uno solo: ho perso mesi di lavoro.
La storia, fortunatamente, è andata in maniera molto diversa.
Codex Desktop quanto crea un progetto “di default” lo va a creare nella cartella Documents del Mac. Successivamente, per risparmiare spazio sul disco interno, avevo spostato l’intero progetto su un SSD esterno utilizzando un symbolic link per consentire a Codex di continuare a lavorare sul progetto senza dover iniziare daccapo visto che non esiste una procedura “standard” per spostare un progetto da una directory ad un’altra.
Dal mio punto di vista era una soluzione perfetta: Codex Desktop continuava a vedere il progetto nello stesso punto, mentre i file reali risiedevano sul disco esterno. Era una soluzione ottimale ed ampiamente usata in ambiente Linux e che non mi aveva mai dato il minimo problema.
Qualche giorno fa ho dovuto liberare spazio sul disco interno e ho lasciato che macOS gestisse l’ottimizzazione dello storage facendogli spostare vecchie Directories dal disco rigido interno ad iCloud. In teoria non avrebbe dovuto succedere nulla di particolare. Non posso affermare con certezza assoluta che sia stata quella la causa, ma da quel momento quel symbolic link non esisteva più. Il progetto continuava a essere tranquillamente presente sul disco esterno, ma il collegamento nella cartella Documents era sparito.
Quando ho riaperto Codex Desktop è iniziata la parte “interessante” se vogliamo chiamarla in questo modo. Il progetto non compariva più nella lista dei workspace e, soprattutto, era sparita anche la conversazione che lo accompagnava. La sensazione iniziale è stata quella che avrebbe avuto chiunque: pensare che tutto fosse stato cancellato.
La mia prima reazione e’ stata quella di scaricare un programma per il recupero di files cancellati. Poi, dopo che non si potevano recuperare (non essendo stati cancellati), ho fatto un passo indietro e cercato di approcciare il problema come avrei fatto con qualsiasi altro bug: senza fare supposizioni e cercando invece di raccogliere quante piu’ informazioni fosse possibile.
La prima domanda che mi sono posto è stata molto semplice: la conversazione è davvero sparita oppure è soltanto Codex Desktop a non riuscire più a mostrarla?
Può sembrare una differenza sottile, ma in realtà cambia completamente il modo di affrontare il problema.
Chi usa Codex Desktop vede soltanto l’interfaccia grafica, ma sotto la superficie esistono diversi livelli di informazioni. C’è un database SQLite che contiene i metadati dei thread, un indice delle conversazioni, i file di rollout che rappresentano il transcript completo di ogni sessione e una serie di riferimenti che permettono a Codex di associare ogni conversazione al relativo workspace. Se uno di questi collegamenti si rompe, l’interfaccia può dare l’impressione che tutto sia sparito, anche quando i dati sono ancora perfettamente presenti sul disco.
Ho quindi iniziato a verificare ogni singolo elemento. Il thread esisteva ancora nel database SQLite. Era presente anche nell’indice delle conversazioni. Il percorso del progetto risultava correttamente registrato. A quel punto mancava soltanto una verifica: il file di rollout esisteva ancora?
La risposta è stata sorprendente. Il file era ancora presente, occupava circa 13 MB e conteneva quasi quattromila (!!!) record JSON perfettamente validi. In quel momento è cambiato completamente il modo di interpretare il problema. Se il transcript era ancora lì, non stavamo cercando di recuperare dati perduti; stavamo cercando di capire perché Codex Desktop non fosse più in grado di associarli al progetto.
La conferma definitiva è arrivata utilizzando il comando codex resume, che ha riaperto l’intera conversazione senza il minimo problema. Se la riga di comando era in grado di ricostruire perfettamente il thread, significava che il lavoro non era mai stato perso.
Rimaneva soltanto da capire perché la Desktop App continuasse a comportarsi come se quella conversazione non esistesse.
Analizzando i metadati del thread mi sono accorto di un dettaglio fondamentale. Io continuavo a pensare al progetto come se fosse nella cartella Documents, perché per mesi avevo lavorato attraverso un symbolic link. Codex, invece, aveva registrato il percorso reale del progetto sul disco esterno. Quando il symbolic link è scomparso, io continuavo ad aprire il percorso “logico”, mentre Codex continuava ad aspettarsi quello fisico. È bastato aprire in Codex Desktop il percorso reale registrato nei metadati del thread perché la conversazione ricomparisse immediatamente, completa di tutta la sua cronologia.
Questa esperienza mi ha insegnato due cose. La prima è che i symbolic link rimangono uno strumento straordinariamente utile e non c’è alcun motivo per smettere di usarli. La seconda, però, è che quando entrano in gioco filesystem, sincronizzazione cloud, dischi esterni e strumenti complessi come Codex Desktop, un livello di indirezione può rendere molto più difficile capire cosa stia realmente succedendo.
Se dovesse capitarvi una situazione simile, il consiglio è molto semplice: non date per scontato che la conversazione sia andata persa solo perché non compare più nella Desktop App. Verificate che il progetto esista ancora nel suo percorso reale, controllate che il file di rollout della sessione sia presente, assicuratevi che il thread esista ancora nel database SQLite e provate a riaprire la conversazione con codex resume. Se tutto questo funziona, è molto probabile che il problema riguardi soltanto l’associazione tra il workspace e la conversazione, non i dati stessi.
Ripensando a tutta questa vicenda, la parte più interessante non è stata il recupero del progetto. È stato il percorso che mi ha portato alla soluzione. Invece di cercare scorciatoie, ho trattato Codex Desktop come qualsiasi altro software complesso osservando i sintomi, verificato le ipotesi, eliminato una possibilità dopo l’altra e seguito le prove fino ad arrivare alla causa del problema. Alla fine non avevo perso mesi di lavoro. Dovevo soltanto riaprire il progetto nel posto giusto.