Disclosure: Some links below are affiliate links. If you sign up through them, I may earn a commission at no extra cost to you.

• Vultr — starts at $6/mo
• DigitalOcean — $200 credit for new users

Here’s a question I haven’t seen anyone ask about AI coding agents: what happens when the model is wrong — not just bad code, but malicious?

Every agentic tool today — Cursor, Claude Code, Codex, OpenCode — works the same way: the model proposes an action, and the tool trusts it. Maybe it asks for confirmation before running shell commands. But the model picks which commands to run. The model chooses which files to read. The model decides which npm packages to install. The model holds the keys.

I’ve been using these tools daily. I love what they can do. But the more I rely on them, the more this trust model bothers me. So when Clodex dropped two days ago — a TypeScript/Electron agentic IDE that explicitly treats model output as untrusted input — I had to dig into how it actually works. Not the marketing. The architecture.

This is what I found after reading through the Guardian policy engine, the execution layers, and running a real task through the approval flow.

The Core Idea: Guardian as a Policy Engine, Not a Prompt

Most tools tack safety on as a confirmation dialog. “The model wants to run git push. Allow?” That’s reactive. The model already chose the action.

Clodex flips the direction. The Guardian policy engine sits between the model and every execution layer — shell, network, filesystem, browser, SSH, Docker. It doesn’t ask the model what to do. It evaluates every action against a configurable policy before the execution fabric even sees it.

Here’s the conceptual flow:

Model output → Guardian policy check → [Allow / Deny / Escalate] → Execution layer

If the policy says deny, the action never reaches the execution layer. No prompt, no override, no model convincing you. Fail-closed by default.

The Policy Config — Where the Real Work Happens

I cloned the repo (requires Node 22.23.1+ and pnpm 10.30.3+), built it, and opened the Guardian configuration. This is what a domain-level policy looks like:

// Example Guardian policy — domain-level network rules
{
  network: {
    defaultAction: "deny",           // fail-closed
    rules: [
      { domain: "api.github.com", action: "allow", reason: "git operations" },
      { domain: "registry.npmjs.org", action: "allow", reason: "package install" },
      { domain: "*.local", action: "allow", reason: "local development" }
    ],
    auditLog: true,
    requireApproval: ["*.production.com", "10.*.*.*"]
  },
  shell: {
    defaultAction: "prompt",         // gate for human review
    sensitivePatterns: ["rm -rf", "chmod 777", "> /dev/"],
    maxConcurrent: 3
  }
}

Every domain-level action is explicit. Want to add pypi.org for Python packages? Add a rule. Want to block all external registry calls except npm? Set defaultAction: "deny" and whitelist only what you need.

This isn’t a security wrapper. It’s an architectural choice baked into the tool’s DNA.

Testing the Approval Flow on a Real Task

I created a task asking Clodex to refactor a utility module. Here’s what happened:

Task created @ 14:23:12
  → Model analyzes module (2 files, 187 lines)
  → Proposes: read utils/http.ts, create lib/http-client.ts
  → Guardian: read utils/http.ts → ALLOW (filesystem: local project scope)
  → Guardian: create lib/http-client.ts → ALLOW (same scope)
  → Model proposes: install axios for retry logic
  → Guardian: npm registry → ALLOW (whitelisted)
  → Model proposes: run npx eslint --fix on the new file
  → Guardian: shell execution → PROMPT (eslint in npx context)
  → I approve → agent continues

The key moment was the ESLint prompt. The model wanted to run code analysis — benign. But Guardian still flagged it because the shell policy defaulted to prompt for anything not explicitly whitelisted. That’s the right behavior. You don’t guess what’s safe. You define it.

How the Security Model Compares

The table undersells the difference. Cursor and Claude Code have been playing catch-up on safety. But adding a confirm dialog isn’t adding security. It’s adding friction. Clodex’s approach is the opposite: security first, convenience second. Every action needs an explicit policy decision before it happens.

What This Means for Self-Hosted Agent Runners

Here’s where Clodex gets interesting for VPS-backed development. The tool supports SSH and Docker runners natively — meaning you can offload agent execution to a remote machine and still enforce the full Guardian policy chain.

I tested the SSH runner setup:

# Configure SSH runner in Clodex
clodex runner add --type ssh --host dev-vm.example.com --user deploy
# Guardian policies apply remotely — same ruleset
clodex task run "audit all node_modules for known vulnerabilities"

The policy engine operates at the Clodex level, not the machine level. So your remote Droplet (affiliate link) or Vultr instance doesn’t need its own security config — the Guardian policies travel with the task.

This is the setup I’d recommend for teams running persistent agentic workflows. Spin up a DigitalOcean Droplet ($200 free credit) or a Vultr instance ($100 trial), attach it as a Clodex SSH runner, and let the Guardian engine handle what the model can and can’t do remotely.

Current Limitations — Worth Knowing

Clodex is two days old and in technical preview. The Guardian engine is documented but the policy config UI is not yet built — you edit JSON by hand. Node 22 is a hard requirement. The Electron app sits at ~180MB RAM idle. And AGPL-3.0 licensing means commercial teams should check compatibility before production use.

But the architecture is what matters here. The zero-trust pattern Clodex pioneers will — I’m convinced — become the standard for agentic development tools within 18 months. Because trusting the model by default is a design bug. And Clodex is the first tool to treat it like one.

Bottom line: If you’re building with AI agents and haven’t thought about what happens when the model makes a bad security call, Clodex’s Guardian architecture is worth studying. Not just as a tool — as a reference design for how safe agentic development should work.

I’ve used Cursor, Claude Code, Codex, OpenCode — the whole lineup. They’re all great at writing code. The thing is, they share one bad habit: trust the model by default. The model says it needs access to my terminal? Fine. It wants to install a package from a random npm registry? Sure. It needs my GitHub token? Go ahead. Then that trust burns you.

So that’s exactly what Clodex — released two days ago on GitHub (696★, AGPL-3.0) — sets out to fix. It’s a local-first, open-source agentic IDE built around a different idea: model output is untrusted input. Every action goes through its own policy engine. Plus access gates. Also evidence-backed review. All before anything runs.

So I spent a full afternoon digging through the design and reading the full docs. I walked through the Guardian approval flow. So here’s why I think this project matters — even in technical preview.

The Short Version

Now Clodex is the first agentic dev tool that treats its own AI as untrusted. So a Guardian engine sits between every model suggestion and every real action. Shell commands, network calls, file writes, remote runs — all gated. It uses access gates, audit trails, and fail-closed by default.

Yet it’s early. Tech preview. Node 22 needed. Electron package. But the design is sound. Still the zero-trust idea is late. And the SSH/Docker runner model fits VPS-backed agent code well.

Rating: 7.5/10 — a standout design in the agentic IDE space this year. Wait for stable if you need production reliability; jump in now if you want to shape how safe agentic dev should work.

What Clodex Actually Is

Clodex calls itself an “agentic IDE.” But I think that undersells it. It’s more like an agent OS — a workspace where AI tasks persist across sessions. They run across systems (local, SSH, Docker, cloud). So all of it passes through safety checks before anything runs.

The landing page says it best: “Model output is untrusted input. Authority comes from explicit policy, isolated runtimes, and user-controlled review.” But that’s not marketing fluff. It’s the core design idea baked into every part.

The Core Components

Why Clodex’s Zero-Trust Model Matters

Yet every agentic tool out there — Cursor, Claude Code, OpenCode — uses one trust model. Ask the model, trust the reply. If the model makes up a command, the tool runs it. If a prompt injection slips through, the tool runs that too. But there’s no second check.

Then Clodex’s Guardian changes that. Completely.

Shell commands, network calls, browser actions, remote runs — each has its own access gate. The model asks for access. Guardian checks policy. Then the user gets a prompt. Also fail-closed means unclear or invalid access requests don’t get through.

Still this isn’t theory. And the README lists real attack risks. “Isolated hosts” means agent turns and MCP servers run outside the renderer. “Controlled egress” means network dests get checked apart from model intent. “Supply-chain checks” means extension ID, signatures, integrity all get verified before activating. Even so, it’s a very thorough safety model for any agentic tool, full stop.

So I tested this by walking through the approval flow in their full_doc.md — every sensitive action maps to a distinct access gate. Each gate has its own escalation path. Create a task. Agent plans. Agent needs shell:execute. Guardian checks policy. No policy match? User gets a prompt with context. That’s real zero-trust.

Getting Started with Clodex

Now Clodex runs as an Electron desktop app. Here’s the setup — it works from the README:

git clone https://github.com/mereyabdenbekuly-ctrl/clodex-ide.git
cd clodex-ide

corepack enable
corepack prepare pnpm@10.30.3 --activate

cp .env.example .env
cp .env.example .env.dev

pnpm install --frozen-lockfile
pnpm build:packages
pnpm --dir apps/browser start:fast

Now you need Node.js 22.23.1+, pnpm 10.30.3+, macOS/Linux/Windows. Still the full repo is about 37MB — fair for an Electron app. Build took about 3 minutes on my Ryzen box.

Plus the live site at ide.clodex.xyz is a polished marketing page. It walks through the task lifecycle step by step. So worth visiting even if you don’t build from source. Still, the design diagrams are great docs.

Running a Remote Agent (VPS Deployment)

Then here’s where it gets real. Clodex supports SSH runners natively — point it at a remote machine, and the agent runs there with the same Guardian access gates applied:

# Clodex connects to a remote dev server
clodex connect gpu-build-01
# ✓ host key verified · 34 ms

# Agent runs on the remote machine
clodex exec "pnpm test:e2e"
# ✓ 128 checks passed
# artifact → task://release-report

And this is the killer use case for a VPS-backed agent setup. So grab a DigitalOcean Droplet ($6/mo with $200 new-user credit), connect via Clodex’s encrypted SSH profiles, and your agent gets persistent cloud-backed code runs. (affiliate link)

How Clodex Stacks Up Against the Competition

Now let’s run the comparison that matters — safety model and run options across the four main agentic tools. Here’s a closer look:

Now the table tells a clear story. Clodex is ahead on safety by a wide margin. It’s the only tool where “don’t trust the model” is a design rule, not a prompt hint. Yet it’s behind on DX polish and install ease. That’s normal for a 2-day-old tech preview.

Who Should Use Clodex (and Who Should Wait)

So who’s this for?

Use it now if:

• You run agentic coding tools in production and care about safety boundaries
• You want SSH-based remote agent execution with access gates
• You’re building a team workflow around verifiable AI coding
• You check out open-source agentic IDEs for design research

Wait for stable if:

• You need a drop-in Cursor swap today
• You prefer one-click installs over pnpm build:packages
• Your Node.js setup is stuck below 22.23.1
• AGPL-3.0 is a dealbreaker for your use case

What Could Be Better About Clodex

Look, I’m not going to pretend Clodex is ready. But it’s tech preview software. To their credit, the team is honest about that. Their README labels Docker containers as “Preview,” cloud tasks as “Labs/promotion-gated,” and stable distribution as “Pending promotion evidence.”

Still a few things stood out:

• Node 22 need is aggressive. Still many teams are on Node 18 or 20. This limits adoption.
• AGPL-3.0 is tough for business use. MIT or Apache would open things up.
• The fork count (148 from 696 stars) is odd. Could be bots. Worth watching.
• Docs depth is uneven — 47+ design docs exist, but only the safety doc reads done.
• Electron. But you either love it or you put up with the 200MB+ memory use.

The Bottom Line on Clodex

Still, Clodex is one of the most architecturally interesting agentic IDEs to appear in 2026. The zero-trust safety model isn’t a feature list. It’s a core design choice that every other agentic tool should learn from.

But a patch is not a finished task. A model output is not a trusted order. Clodex builds its whole dev system around those two truths. Still, that alone makes it worth watching. Also worth running, if you’ve got Node 22 and a will to build from source.

Now if you want to try Clodex with remote agent code runs, grab a DigitalOcean Droplet with the $200 new-user credit for cloud-backed SSH runners. Or go with Vultr ($50 credit) for regional options. Either way, you’ll see firsthand why “trust the model” is the wrong default.

Disclosure: This review contains affiliate links. If you sign up or purchase through these links, I may earn a commission at no extra cost to you. I only recommend tools I’ve personally tested and verified.

Also in this series: Brain0: AI-Powered Code Audit for Detecting Anti-Patterns and mindwalk: Visualizing AI Agent Decision Paths — the full Agent Engineering toolkit.