Clodex è un IDE agentico open-source (AGPL-3.0) che combina task persistenti, codice, terminale, browser, Git e modelli in un workspace Electron. Il principio architetturale: l’output del modello è input non fidato, e l’autorità viene da policy esplicite, runtime isolati e revisione utente.

Un task in Clodex mantiene lo stato attraverso sessioni lunghe e riavvii, opera su file, Git, terminali, browser e tool MCP, e chiede approvazione prima di azioni ad alto impatto (shell, rete, browser, operazioni remote). Può girare in locale o spostarsi su Docker, SSH o cloud, e restituisce diff, ricevute, artefatti e un risultato finale autocontenuto.

Perché ti riguarda. Se costruisci con agenti di coding o vuoi self-hosting con controllo granulare, Clodex traccia un’evoluzione rispetto agli IDE agentici cloud-first: esecuzione locale verificabile, policy dichiarate, e handoff espliciti al posto della fiducia implicita. Il repo ha raccolto 635 stelle in 14 giorni, segnale di un tema caldo nella comunità builder.

Dove guardare. Il progetto è in Technical Preview: il core architetturale è implementato, le lane di esecuzione avanzate restano feature-gated fino a evidenza e sign-off manuale. La documentazione completa (full_doc.md) spiega il modello di sicurezza e le lane di esecuzione.

Nel dettaglio

Il contesto

Gli IDE agentici attuali (Cursor, Windsurf, le estensioni Copilot) eseguono codice proposto dai modelli con poca frizione. La fiducia è implicita: se il modello propone un comando o una chiamata API, lo strumento lo esegue dopo una conferma veloce. Clodex parte dal presupposto opposto: model output is untrusted input. Ogni azione proposta dall’agente passa attraverso policy dichiarate, runtime isolati e, per le operazioni ad alto impatto (esecuzione shell, accesso rete, modifiche Git, navigazione browser), un’approvazione esplicita dell’utente.

Questa scelta architettonica risponde a un problema vero: quando un agente ha accesso a terminali, file system e strumenti esterni, un errore o un prompt injection possono avere conseguenze serie (file cancellati, credenziali esposte, chiamate API costose). I meccanismi di sandboxing e le lane di esecuzione di Clodex mirano a ridurre questo rischio senza perdere la flessibilità.

Cosa cambia

Clodex modella il lavoro di sviluppo come task duraturi con stato proprio. Un task può:

• Mantenere il contesto attraverso sessioni lunghe e riavvii dell’applicazione, invece di perdere tutto quando chiudi la finestra.
• Operare su workspaces multipli: file, Git, terminali, tab del browser, tool MCP, runner remoti.
• Instradare il lavoro fra modelli senza cambiare il workflow circostante: puoi switchare fra GPT-5.6, Claude Fable, Muse Spark o modelli locali senza riconfigurare l’ambiente.
• Chiedere approvazione prima di azioni ad alto impatto (shell, rete, browser, remote). Non è un blocco totale: è un handoff esplicito all’utente nei punti critici.
• Eseguire in ambienti diversi: locale (default), Docker, SSH, cloud-backed, con la stessa interfaccia.
• Restituire artefatti verificabili: diff, log, ricevute, output finale autocontenuto.

Le lane di esecuzione sono il meccanismo di isolamento: ogni task gira in un ambiente controllato con permessi dichiarati. Le lane avanzate (Docker, SSH, cloud) restano feature-gated fino a quando non sono validate: il team vuole evidenza che funzionano in casi reali prima di promuoverle a disponibilità generale.

Limiti e stato attuale

Il progetto dichiara Technical Preview: il core è implementato e testato localmente, ma le lane avanzate non sono ancora aperte. Questo è onesto, ma significa che se vuoi usarlo oggi devi accettare di lavorare su un sistema in evoluzione rapida, con documentazione che precede l’implementazione completa in alcuni punti.

Non ci sono ancora metriche pubbliche su quanto spesso un task chiede approvazione (troppo spesso diventa friction, troppo poco vanifica lo zero-trust), né benchmark contro altri IDE agentici su SWE-bench o task reali. Il modello di sicurezza è descritto in SECURITY.md, ma senza audit esterno per ora.

La licenza AGPL-3.0 richiede che modifiche distribuite siano condivise: se costruisci un servizio sopra Clodex, devi rilasciare il codice. Per uso interno o self-hosting puro non c’è problema.

Cosa farci

Se costruisci agenti di coding o stai valutando alternative a strumenti cloud-first, Clodex vale una prova. Il confronto diretto è con Ornith-1.0 (modello aperto progettato per agenticità) e con le architetture descritte in Il codice pulito aiuta davvero gli agenti: repository ben strutturati riducono il lavoro dell’agente, e un IDE che mantiene stato e contesto lungo amplifica questo vantaggio.

Per chi segue gli agenti builder, questa è una traccia evolutiva chiara: da “esegui tutto” a “esegui con policy verificabili”. Il sito racconta questa traiettoria da Cos’è davvero un agente fino a Dare gli strumenti giusti e i loro confini: Clodex applica quei principi a un IDE completo.