Radar · 12/07/2026 · coding

Clodex: Agentic IDE with local-first execution, zero-trust, and local verification

Clodex is an open-source agentic IDE (AGPL-3.0) that combines persistent tasks, code, terminal, browser, Git, and models in an Electron workspace. Core architectural principle: model output is untrusted input, and authority comes from explicit policies, isolated runtimes, and user review.

A task in Clodex maintains state across long sessions and restarts, operates on files, Git, terminals, browsers and MCP tools, and requests approval before high-impact actions (shell, network, browser, remote operations). It can run locally or move to Docker, SSH, or cloud, and returns diffs, receipts, artifacts, and a self-contained final result.

Why this matters to you. If you’re building with coding agents or want self-hosted deployment with granular control, Clodex charts an evolution beyond cloud-first agentic IDEs: verifiable local execution, declared policies, and explicit handoffs instead of implicit trust. The repo collected 635 stars in 14 days—a signal of an active theme in the builder community.

Where to look. The project is in Technical Preview: the core architecture is implemented, advanced execution lanes remain feature-gated pending evidence and manual sign-off. Full documentation (full_doc.md) explains the security model and execution lanes.

In depth

The context

Current agentic IDEs (Cursor, Windsurf, Copilot extensions) execute model-proposed code with little friction. Trust is implicit: if the model proposes a command or API call, the tool runs it after quick confirmation. Clodex starts from the opposite assumption: model output is untrusted input. Every action the agent proposes passes through declared policies, isolated runtimes, and for high-impact operations (shell execution, network access, Git changes, browser navigation), explicit user approval.

This architectural choice addresses a real problem: when an agent has access to terminals, filesystems, and external tools, an error or prompt injection can have serious consequences (files deleted, credentials exposed, costly API calls). Clodex’s sandboxing mechanisms and execution lanes aim to reduce this risk without losing flexibility.

What changes

Clodex models development work as durable tasks with their own state. A task can:

  • Maintain context across long sessions and application restarts, instead of losing everything when you close the window.
  • Operate across multiple workspaces: files, Git, terminals, browser tabs, MCP tools, remote runners.
  • Route work between models without changing the surrounding workflow: you can switch between GPT-5.6, Claude Fable, Muse Spark, or local models without reconfiguring the environment.
  • Request approval before high-impact actions (shell, network, browser, remote). It’s not a total block: it’s an explicit handoff to the user at critical points.
  • Execute in different environments: local (default), Docker, SSH, cloud-backed, with the same interface.
  • Return verifiable artifacts: diffs, logs, receipts, self-contained final output.

Execution lanes are the isolation mechanism: each task runs in a controlled environment with declared permissions. Advanced lanes (Docker, SSH, cloud) remain feature-gated until validated: the team wants evidence they work in real cases before promoting them to general availability.

Limitations and current state

The project declares Technical Preview: the core is implemented and tested locally, but advanced lanes aren’t open yet. This is honest, but means if you want to use it today you need to accept working on a rapidly evolving system, with documentation that in some points outpaces full implementation.

There are no public metrics yet on how often a task requests approval (too often becomes friction, too rarely defeats zero-trust), nor benchmarks against other agentic IDEs on SWE-bench or real tasks. The security model is described in SECURITY.md, but without external audit for now.

The AGPL-3.0 license requires that distributed changes be shared: if you build a service on top of Clodex, you must release the code. For internal use or pure self-hosting there’s no issue.

What to do with it

If you’re building coding agents or evaluating alternatives to cloud-first tools, Clodex is worth a try. Direct comparison is with Ornith-1.0 (open model designed for agenticty) and the architectures described in Does clean code actually help agents: well-structured repositories reduce agent work, and an IDE that maintains state and context at length amplifies this advantage.

For those following agent builders, this is a clear evolutionary track: from “execute everything” to “execute with verifiable policies”. The site traces this trajectory from What an agent really is through Giving tools the right boundaries: Clodex applies those principles to a full IDE.

Type to search across course, playbooks, skills, papers…