Clodex est un IDE agentique open-source (AGPL-3.0) qui combine des tâches persistantes, du code, un terminal, un navigateur, Git et des modèles dans un espace de travail Electron. Principe architectural : la sortie du modèle est une input non fiable, et l’autorité vient de politiques explicites, de runtimes isolés et de la révision utilisateur.

Une tâche dans Clodex maintient l’état à travers de longues sessions et redémarrages, opère sur des fichiers, Git, des terminaux, un navigateur et des outils MCP, et demande une approbation avant les actions à fort impact (shell, réseau, navigateur, opérations distantes). Elle peut s’exécuter en local ou se déplacer vers Docker, SSH ou le cloud, et retourne des diffs, des reçus, des artefacts et un résultat final autonome.

Pourquoi c’est pertinent. Si vous construisez avec des agentes de codage ou souhaitez un auto-hébergement avec contrôle granulaire, Clodex trace une évolution par rapport aux IDE agentiques cloud-first : exécution locale vérifiable, politiques déclarées, et transferts explicites à la place de la confiance implicite. Le repo a récolté 635 étoiles en 14 jours, signal d’un sujet brûlant dans la communauté des builders.

Où regarder. Le projet est en Aperçu technique : l’architecture core est implémentée, les pistes d’exécution avancées restent feature-gated en attente de preuves et d’approbation manuelle. La documentation complète (full_doc.md) explique le modèle de sécurité et les pistes d’exécution.

En détail

Le contexte

Les IDE agentiques actuels (Cursor, Windsurf, les extensions Copilot) exécutent le code proposé par les modèles avec peu de friction. La confiance est implicite : si le modèle propose une commande ou un appel API, l’outil l’exécute après une confirmation rapide. Clodex part du postulat opposé : model output is untrusted input. Chaque action proposée par l’agent passe par des politiques déclarées, des runtimes isolés et, pour les opérations à fort impact (exécution shell, accès réseau, modifications Git, navigation du navigateur), une approbation explicite de l’utilisateur.

Cette architecture répond à un vrai problème : quand un agent a accès à des terminaux, au système de fichiers et à des outils externes, une erreur ou une injection de prompt peut avoir des conséquences graves (fichiers supprimés, credentials exposées, appels API coûteux). Les mécanismes de sandboxing et les pistes d’exécution de Clodex visent à réduire ce risque sans sacrifier la flexibilité.

Ce qui change

Clodex modélise le travail de développement comme tâches durables avec état propre. Une tâche peut :

• Maintenir le contexte à travers de longues sessions et redémarrages de l’application, au lieu de tout perdre quand vous fermez la fenêtre.
• Opérer sur des espaces de travail multiples : fichiers, Git, terminaux, onglets du navigateur, outils MCP, runners distants.
• Router le travail entre des modèles sans changer le workflow environnant : vous pouvez basculer entre GPT-5.6, Claude Fable, Muse Spark ou des modèles locaux sans reconfigurer l’environnement.
• Demander une approbation avant les actions à fort impact (shell, réseau, navigateur, remote). Ce n’est pas un blocage total : c’est un transfert explicite vers l’utilisateur aux points critiques.
• S’exécuter dans des environnements différents : local (par défaut), Docker, SSH, cloud-backed, avec la même interface.
• Retourner des artefacts vérifiables : diffs, logs, reçus, sortie finale autonome.

Les pistes d’exécution sont le mécanisme d’isolement : chaque tâche s’exécute dans un environnement contrôlé avec des permissions déclarées. Les pistes avancées (Docker, SSH, cloud) restent feature-gated jusqu’à validation : l’équipe veut des preuves qu’elles fonctionnent dans des cas réels avant de les promouvoir en disponibilité générale.

Limites et état actuel

Le projet déclare Aperçu technique : le core est implémenté et testé localement, mais les pistes avancées ne sont pas encore ouvertes. C’est honnête, mais cela signifie que si vous voulez l’utiliser aujourd’hui, vous devez accepter de travailler sur un système en évolution rapide, avec une documentation qui précède l’implémentation complète par endroits.

Il n’y a pas encore de métriques publiques sur la fréquence des demandes d’approbation (trop souvent crée de la friction, trop peu annule le zero-trust), ni de benchmarks par rapport à d’autres IDE agentiques sur SWE-bench ou des tâches réelles. Le modèle de sécurité est décrit dans SECURITY.md, mais sans audit externe pour l’instant.

La licence AGPL-3.0 exige que les modifications distribuées soient partagées : si vous construisez un service au-dessus de Clodex, vous devez publier le code. Pour un usage interne ou un auto-hébergement pur, il n’y a pas de problème.

Qu’en faire

Si vous construisez des agentes de codage ou évaluez des alternatives à des outils cloud-first, Clodex mérite un essai. La comparaison directe se fait avec Ornith-1.0 (modèle ouvert conçu pour l’agenticité) et avec les architectures décrites dans Le code propre aide-t-il vraiment les agentes : les repositories bien structurés réduisent le travail de l’agent, et un IDE qui maintient l’état et le contexte à travers les sessions amplifie cet avantage.

Pour ceux qui suivent les agentes builder, c’est une trajectoire évolutive claire : de « exécute tout » à « exécute avec des politiques vérifiables ». Le site raconte cette trajectoire depuis Qu’est-ce qu’un agent vraiment jusqu’à Donner les bons outils et leurs frontières : Clodex applique ces principes à un IDE complet.