CLODEx: A local-first IDE that treats agent output as input, not authority
Local-first, zero-trust agentic IDE for verifiable autonomous software development.
At a glance
- What is it?
- CLODEx is an open-source, local-first agentic IDE for long-running engineering work. It keeps code, Git, terminal, browser, models, and MCP tools in one durable desktop workspace, with explicit approval and review surfaces for sensitive actions.
- Who is it for?
- CLODEx is for engineers who want a local-first, auditable agentic IDE where model output remains input, not authority. It is not for teams that need a managed cloud service or automated updates, since the current Community builds are unsigned and updates are manual.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What problem does CLODEx solve?
Most AI coding interfaces are optimized for the next message. That works for quick questions but fails for real engineering work, which spans hours or days: understanding a repository, planning a change, editing multiple files, running commands, inspecting the application, reviewing the diff, recovering from failure, and continuing the next day. CLODEx frames that as a durable task rather than a disposable chat. The README states the core principle: 'Model output is input, not authority.' The tool is designed for developers who want to keep the engineering loop visible and controllable, not hidden behind a single 'done' message.
How the durable workspace works
CLODEx keeps task history and workspace state persistent across sessions. The README describes a typical workflow: open a repository, start a task, ask the agent to explain or implement a change, let it inspect files and use approved local tools, then review Pending Edits, line-level diffs, terminal output, browser state, and permission requests. The agent can accept, revise, commit, or continue the same task later. The architecture combines files, Git, terminal, browser, and MCP in one workspace. That means context is not rebuilt from messages; it is retained in the task itself. The README also includes a flow diagram: developer request, agent proposes, permission checks, local tool executes, then diffs and outputs return for review. This is a deliberate contrast to chat-first tools where a patch is the end of the interaction.
Getting it running: Community Observed builds
The current release is Community Observed 21, tagged v1.16.0-communityobserved21. It is built from exact canonical source commit d2dd2b63077c67255d60b8ab53f5c3c0995c7f84, by Actions run 30483341383. The README links to a download page for that release. Packages exist for macOS Apple Silicon, macOS Intel, Windows x64, Debian/Ubuntu x64, and Fedora/RHEL x64. The README also mentions building from source, though it does not give the exact commands in the visible portion. The binaries are unsigned and ad-hoc, not notarized, so the README warns to check the warning before installing. The release includes a SHA256SUMS.txt file and validation manifests and SBOMs in an evidence archive.
Model flexibility: BYOK, custom endpoints, and local Ollama
CLODEx supports several ways to connect models. You can sign in with a CLODEx account, bring your own provider key (BYOK), use a compatible OpenAI-compatible endpoint, or connect a local Ollama instance. This is a meaningful design choice: the tool does not lock you into a single provider. The README lists these options under the 'Models' area of the free product scope. For teams that need to keep data on-premises or avoid sending code to a third party, the local Ollama path is valuable. The trade-off is that you manage the model infrastructure yourself. The BYOK path still sends prompts to an external provider, so the local-first claim applies to the workspace, not necessarily to the model calls.
Approval and review surfaces: the zero-trust angle
The README emphasizes that sensitive operations can require explicit approval and remain reviewable. The flow diagram shows permission and approval checks between the agent's proposal and the local tool execution. This is the 'zero-trust' part of the description: the agent does not act with full authority. The public source includes explicit permission, approval, diff, and review surfaces. The README points to a security model document at docs/developer/security-and-data.md. That document is not included in the visible material, so we cannot verify the exact enforcement mechanism. But the design intent is clear: the user stays in control. This is a different stance from tools that auto-apply patches or run commands without confirmation.
Maintenance and licensing: AGPL-3.0 and manual updates
CLODEx is licensed under AGPL-3.0. That has implications if you modify the source and deploy it as a network service, but it is permissive for internal use. The project is actively maintained: the last push was on 2026-08-05, and releases come out frequently (Community Observed 24, 25, 26 are recent). The update mechanism is manual and fail-closed. In Settings → About, 'Check for Updates' performs a user-triggered release check and can open a newer release page in the external browser. It never downloads or installs an update automatically. That is a security feature, but it also means you must track releases yourself. For a tool that handles code and terminals, that is a reasonable trade-off, but it adds operational overhead.
Limitations and when it is the wrong tool
The most obvious limitation is that the current Community builds are unsigned and not notarized. That makes installation on macOS especially awkward, and it raises the bar for trust. The README itself warns about this. Another limitation is that the free product scope is explicitly bounded by a contract that must fail closed for Community packaging. That means some features present in the managed product may not appear in the free builds. If you need automated updates or a fully managed experience, CLODEx is not that. It is also not a lightweight tool: it combines an IDE, terminal, browser, and MCP client in one desktop app, which is heavy. For simple one-off code generation, a chat tool is faster. CLODEx is for long-running tasks where context and review matter more than speed.
Alternatives and the real difference
The obvious alternative is a chat-first agentic coding tool like GitHub Copilot Workspace or Cursor's agent mode. Those tools are optimized for the next message and often apply patches directly. CLODEx's difference is the durable workspace and the explicit approval gate. Another alternative is a terminal-based agent like Aider, which is also local-first but does not bundle a browser, MCP client, or a full IDE. CLODEx's approach is to keep everything in one desktop workspace, which is more integrated but also more complex. If you prefer a minimal terminal workflow, Aider is lighter. If you want a fully managed cloud IDE, this is not that. The choice depends on whether you value a single durable task context and review surfaces over simplicity.
Conclusion: who should adopt CLODEx
Adopt CLODEx if you are an individual developer or a small team that wants a local-first agentic IDE with explicit approval and review, and you are willing to manage manual updates and verify binaries against the pinned source and build run. Do not adopt it if you need signed/notarized installers, automated updates, or a managed service. Before you install, verify the SHA256 checksums against the release page, check the Free Product Contract to confirm your required features are in the free scope, and read the security-and-data.md document. The project is active and the release cadence is high, so the maintenance cost is mostly on your side: you track releases and re-verify each one. That is the price of a zero-trust, fail-closed distribution model.
Editorial conclusion
CLODEx is for engineers who want a local-first, auditable agentic IDE where model output remains input, not authority. It is not for teams that need a managed cloud service or automated updates, since the current Community builds are unsigned and updates are manual. Before adopting it, verify the pinned source revision and build run for the exact binary you install, and confirm that the Free product contract covers your required workflows. If you need a more mature, signed, or notarized distribution, wait for a later release or use a commercial alternative.
Community notes