Clodex es un IDE agéntico open-source (AGPL-3.0) que combina tareas persistentes, código, terminal, navegador, Git y modelos en un workspace Electron. El principio arquitectónico: el output del modelo es entrada no confiable, y la autoridad proviene de políticas explícitas, runtime aislados y revisión del usuario.

Una tarea en Clodex mantiene estado a través de sesiones largas y reinicios, opera sobre archivos, Git, terminales, navegador y herramientas MCP, y solicita aprobación antes de acciones de alto impacto (shell, red, navegador, operaciones remotas). Puede ejecutarse localmente o trasladarse a Docker, SSH o cloud, y devuelve diffs, recibos, artefactos y un resultado final autocontenido.

Por qué te importa. Si construyes con agentes de coding o buscas self-hosting con control granular, Clodex traza una evolución respecto a los IDE agentivos cloud-first: ejecución local verificable, políticas declaradas, y handoffs explícitos en lugar de confianza implícita. El repositorio acumuló 635 estrellas en 14 días, señal de un tema candente en la comunidad builder.

Dónde mirar. El proyecto está en Technical Preview: la arquitectura core está implementada, las lanes de ejecución avanzadas permanecen feature-gated hasta evidencia y sign-off manual. La documentación completa (full_doc.md) explica el modelo de seguridad y las lanes de ejecución.

En detalle

El contexto

Los IDE agentivos actuales (Cursor, Windsurf, extensiones Copilot) ejecutan código propuesto por modelos con poca fricción. La confianza es implícita: si el modelo propone un comando o llamada API, la herramienta lo ejecuta tras confirmación rápida. Clodex parte del supuesto opuesto: model output is untrusted input. Cada acción propuesta por el agente pasa por políticas declaradas, runtime aislados y, para operaciones de alto impacto (ejecución shell, acceso red, cambios Git, navegación del navegador), aprobación explícita del usuario.

Esta elección arquitectónica responde a un problema real: cuando un agente tiene acceso a terminales, sistema de archivos y herramientas externas, un error o inyección de prompt pueden tener consecuencias graves (archivos eliminados, credenciales expuestas, llamadas API costosas). Los mecanismos de sandboxing y las lanes de ejecución de Clodex buscan reducir este riesgo sin perder flexibilidad.

Qué cambia

Clodex modela el trabajo de desarrollo como tareas duraderas con estado propio. Una tarea puede:

• Mantener contexto a través de sesiones largas y reinicios de aplicación, en lugar de perder todo al cerrar la ventana.
• Operar sobre workspaces múltiples: archivos, Git, terminales, tabs del navegador, herramientas MCP, runners remotos.
• Enrutar trabajo entre modelos sin cambiar el flujo circundante: puedes cambiar entre GPT-5.6, Claude Fable, Muse Spark o modelos locales sin reconfigurar el entorno.
• Solicitar aprobación antes de acciones de alto impacto (shell, red, navegador, remoto). No es un bloqueo total: es un handoff explícito al usuario en puntos críticos.
• Ejecutar en entornos distintos: local (por defecto), Docker, SSH, cloud-backed, con la misma interfaz.
• Devolver artefactos verificables: diffs, logs, recibos, output final autocontenido.

Las lanes de ejecución son el mecanismo de aislamiento: cada tarea corre en un entorno controlado con permisos declarados. Las lanes avanzadas (Docker, SSH, cloud) permanecen feature-gated hasta validación: el equipo quiere evidencia de que funcionan en casos reales antes de promoverlas a disponibilidad general.

Limitaciones y estado actual

El proyecto declara Technical Preview: el core está implementado y testeado localmente, pero las lanes avanzadas no están abiertas aún. Esto es honesto, pero significa que si quieres usarlo hoy debes aceptar trabajar sobre un sistema en evolución rápida, con documentación que en algunos puntos precede a la implementación completa.

Aún no hay métricas públicas sobre con qué frecuencia una tarea solicita aprobación (muy frecuente genera fricción, muy rara invalida el zero-trust), ni benchmarks contra otros IDE agentivos en SWE-bench o tareas reales. El modelo de seguridad se describe en SECURITY.md, pero sin auditoría externa por ahora.

La licencia AGPL-3.0 requiere que las modificaciones distribuidas se compartan: si construyes un servicio sobre Clodex, debes liberar el código. Para uso interno o self-hosting puro no hay problema.

Qué hacer con esto

Si construyes agentes de coding o estás evaluando alternativas a herramientas cloud-first, Clodex merece una prueba. La comparación directa es con Ornith-1.0 (modelo abierto diseñado para agenticidad) y con las arquitecturas descritas en El código limpio ayuda realmente a los agentes: repositorios bien estructurados reducen el trabajo del agente, y un IDE que mantiene estado y contexto a lo largo amplifica esta ventaja.

Para quien sigue a los agent builders, esta es una trayectoria evolutiva clara: de “ejecutar todo” a “ejecutar con políticas verificables”. El sitio cuenta esta trayectoria desde Qué es realmente un agente hasta Dar las herramientas correctas y sus límites: Clodex aplica esos principios a un IDE completo.