Claude Code vs Codex vs OpenCode vs Kendr Code: a structural comparison

What all four now share

It is worth stating the convergence before the differences, because it is the most important fact about the 2026 field. All four send the full conversation and the full tool catalogue to the model each step, execute what it calls, return results including real error text, and stop when the model stops calling tools. All four read an instruction file from the repository root. All four speak MCP. All four support subagents or delegated contexts, a read-only or plan mode, and a headless invocation for scripting.

That convergence means the loop is no longer where you should be shopping. Two of these four could swap loops tomorrow and most users would not notice for a week. What they would notice, immediately, is a different answer to the question: what happens when a command is dangerous, when the process dies mid-edit, when the provider you want is not the vendor’s own.

Isolation: Codex is genuinely ahead

Codex is the clearest single-dimension winner in this group. Its sandbox is enforced by the operating system rather than by the agent’s own restraint: Seatbelt on macOS, Landlock plus seccomp on Linux, a native Windows sandbox, and network access off by default so a compromised dependency cannot phone home during a test run.^[1] Because the sandbox is kernel-level, it holds even when the model is wrong about what a command does.

Claude Code sandboxes on macOS and Linux and offers a container-based path, with the practical caveat that native Windows is the weakest posture across this whole category. Kendr Code publishes an explicit three-way execution taxonomy — a guarded host mode, a container mode with pinned image digests and network-off flags, and a WSL mode it labels as shell parity rather than containment — plus an external guardian process that watches for parent death and a durable quarantine for workspaces whose containers cannot be proven cleaned up.^[2] Its 14 August release added the piece that was missing: a kernel sandbox on the host backend, so a process launched by a tool is now confined rather than merely the tool itself. On Linux that is Landlock plus a network namespace, verified end to end on a 5.15 kernel. On macOS a Seatbelt profile is implemented and pinned by tests but its enforcement is unverified. On Windows the product reports the mechanism as unenforced rather than claiming a sandbox, and points users at the container backend — which is the correct answer and still a gap against Codex.

OpenCode is the weakest of the four here. Isolation is available through Docker and through permission configuration, but it does not ship the kernel-level default the others do.

Model freedom: OpenCode is the reason to look past the vendors

OpenCode’s structural bet is that the harness should not be tied to whoever trained the model. It resolves provider metadata from a shared catalogue rather than hardcoding integrations, which is how it supports 75 or more providers without a per-vendor code path, and it integrates the Language Server Protocol so the agent sees real diagnostics from your own toolchain rather than guessing at type errors.^[3]

Its client-server architecture is the second reason to take it seriously. The backend owns inference, tool execution, session persistence, and MCP servers; terminal, desktop, web, and mobile clients connect over HTTP and server-sent events. The agent still runs on your machine, but you are no longer required to be sitting at that machine — a materially different answer to the remote-access problem than shipping a hosted runner.

Claude Code and Codex both point at their own models by default. Claude Code’s terminal and VS Code surfaces support third-party providers, and Codex is open source enough that forks such as open-codex and Every Code widen it, but neither is provider-neutral by design. Kendr Code sits between the two, and its own transport audit is unusually candid about where. Anthropic, OpenAI, and Google-direct routes carry native tool calling and live streaming. Everything else — the hosted gateway that fronts Bedrock, Kimi, and Sarvam, plus local Ollama — runs Code actions over a constrained JSON protocol instead, with the hosted path rendering the conversation into the prompt string rather than sending a structured message array, and xAI has no Code adapter at all. So the catalogue is a real 70-plus models across six vendors, but the audit’s own summary is that these are “70 degraded ones”. That is a different unit again from OpenCode’s 75-plus providers, and it is why the score is 7 rather than 10 — compounded by a missing escape hatch, since without a generic OpenAI-compatible endpoint a vendor Kendr has not written a module for cannot be used at all. This is the one dimension the August release did not move.

Durability and approvals: where Kendr Code leads

Kendr Code’s distinguishing bet is that the invocation log should be the authoritative state of the system, not a transcript for your convenience. In practice that means a mutating turn holds a renewable single-writer lease with a background heartbeat and stops closed if the lease is lost, the turn start is claimed atomically in the database so a desktop runtime and a command-line runtime sharing one store cannot both start it, and a restart reconciles and replays pending approvals oldest-first.^[2]

The approval model follows from that. Each pending approval persists the exact proposed arguments with an audit fingerprint, so it survives a process kill and is still meaningful when you return. Approve or reject is one conditional database transition, so two clients cannot both decide it or overwrite a decision. A rejection can carry free-text feedback that is stored verbatim and handed back to the model instead of failing the turn. An approval can mint a project-scoped standing rule keyed to a tool, a command prefix, or a path prefix, and those rules are listable and deletable. Crucially, subagent tool calls pass through the same gate as the parent turn.

The other three are competent here rather than exceptional. All three resume sessions; all three have approval modes; none of them treats concurrent decision resolution, lease ownership, and ledger replay as first-class engineering problems. For most interactive work that difference never surfaces. For unattended or regulated work it is the whole question.

Cloud and reach: where Kendr Code trails

Claude Code’s surface list is the widest in the category: terminal, VS Code, JetBrains, a desktop app, the web, and mobile, with sessions that move between them, cloud-side Routines that keep running when the machine is off, GitHub Actions and GitLab CI integration, and Slack routing from a bug report to a pull request.^[4] Codex pairs a headless execution mode that drops cleanly into CI with an OpenAI-hosted cloud that runs a task in a container and returns a diff. Both pass the walk-away test.

Neither OpenCode nor Kendr Code does, and they fail it differently. OpenCode’s client-server split means you can reach your machine from a phone, but the machine still has to be on. Kendr Code moved from 5 to 7 here on its August release by shipping a frozen non-interactive execution contract with structured JSON output, a GitHub composite action, and a GitLab template — so it now runs in CI, which is an execution plane you do not own a laptop for. It is still not off-machine execution: with no CI job running, closing the laptop stops the work. Kendr’s cloud remains an immutable-plan routing service, a credit ledger, an encrypted connector service, hosted knowledge bases, and a public model API — a control plane for model access, not an execution plane for the agent.^[5] That is the largest remaining gap in its architecture and it is not a positioning choice.

• Choose Claude Code if surface reach, ecosystem, and unattended cloud runs matter more than model freedom.
• Choose Codex if the repository is untrusted, or the compliance question is about what a process can reach on Windows specifically.
• Choose OpenCode if provider independence, LSP-grade diagnostics, or driving your own machine from any client is the requirement.
• Choose Kendr Code if the work must be transactional, individually approved, and reconstructable after a crash — and if local or CI execution is acceptable in place of a hosted runner.

What this comparison is not

None of these numbers are task-success rates. A harness with a weaker architecture paired with a stronger model will beat a better-engineered harness on a coding benchmark most days, and published SWE-bench-style results measure a model-plus-harness pair rather than the harness alone. Read this table as a description of what each system guarantees, not of how good its output is.

All four also ship frequently enough that a quarter-old comparison is materially wrong. The correct use of this page is as a checklist of questions to re-ask against the current release: which sandbox on my operating system, which providers stream, what survives a kill, what runs when I close the laptop.

Sources and evidence

Primary and authoritative sources used for factual claims. Company research and executive forecasts are labeled as such in the article.

1. 1
   OpenAI Codex documentationOpenAI
2. 2
   Kendr Code architecture, execution backends, and approval modelKendr
3. 3
   OpenCode documentationOpenCode
4. 4
   Claude Code overview and surfacesAnthropic
5. 5
   Kendr developer API and model contractsKendr