Best Open Source Coding Harnesses in 2026
A practical comparison of the source-available coding harnesses developers can run, inspect, extend, and connect to the models they choose.
Open source harnesses
Open code. Different contracts.
critique.sh
The best open source coding harness depends on what you want to own. Choose CritiqueCode for an MIT-licensed author harness with controller-owned independent review and verified repair. Choose Codex CLI for OpenAI’s open-source local coding agent and its surrounding CLI, IDE, app, and cloud ecosystem. Choose Pi for a minimal MIT-licensed terminal harness that is intentionally extended through TypeScript. Choose Oh My Pi for a Pi fork with a large native tool surface, LSP, debugging, subagents, memory, and review workflows. Choose OpenCode for an MIT-licensed, model-flexible agent with terminal, desktop, IDE, Plan/Build, subagents, SDK, and granular permissions.
Open source coding agents are having a moment because developers want more than a chat window that can edit a file. They want to inspect the runtime, change the tool policy, bring their own model, run locally, and understand what happens between a prompt and a patch.
But “open source” is not one feature. It does not tell you whether the default runtime is sandboxed, whether the model is open, whether a hosted provider sees your code, whether the project supports the editor you use, or whether an author can be forced through independent review. Those questions need separate answers.
What does “open source harness” mean?
A harness is the runtime that turns a model into a coding agent. It supplies tools for reading, searching, editing, and running commands; controls permissions; stores session state; routes requests to providers; and decides how work is reviewed or completed.
For this comparison, “open source” means the relevant project publishes source under a recognized open-source license. Pi, Oh My Pi, and OpenCode publish MIT-licensed projects. The Codex CLI is open source, while Codex also includes hosted and product surfaces. CritiqueCode publishes its author harness under MIT, while Critique Inference is an optional hosted model route. The code, model, service, and deployment are related, but they are not the same thing.
| Dimension | CritiqueCode | Codex | Pi | Oh My Pi | OpenCode |
|---|---|---|---|---|---|
| Source and license | Public CritiqueCode repository and MIT-licensed @critiquedotsh/harness author package. | Open-source Codex CLI; the wider Codex product also includes hosted, app, and IDE surfaces. | MIT-licensed Pi Agent Harness repository and packages. | MIT-licensed Pi fork; third-party and vendored components keep their own notices. | MIT-licensed OpenCode repository and open-source coding agent. |
| Model strategy | Critique Inference critique/auto by default after login, with BYOK provider routes available. | OpenAI-native models and product flows; the CLI is part of a broader Codex harness. | Unified multi-provider LLM API with custom models and provider setup. | 60+ providers and role-based routing are advertised by the project; local OpenAI-compatible endpoints are supported. | Multi-provider and local-model workflows; OpenCode also offers its optional Zen route. |
| Core tools | Repository tools, approved critique_run, skills, workers, review, and verified repair. | Local file and command tools, approvals, images, web search, MCP, and connected cloud workflows. | Small built-in terminal tool set extended by TypeScript tools, commands, skills, and packages. | Native read/search/shell, Python, browser, LSP, DAP, typed task results, memory, and review. | Read, edit, shell, Plan/Build, task, web, MCP, structured output, and configurable custom tools. |
| Safety posture | User approves each critique_run; networked checks require an enforced sandbox; author narration is not Evidence. | Documented approval modes and system-level sandboxing; permissions depend on the selected mode and environment. | No built-in permission system or sandbox; use containerization or a policy-controlled runtime when needed. | Native tool and policy features are extensive; review the project’s configuration and external boundaries before deployment. | Per-tool allow/ask/deny rules, path and command patterns, external-directory controls, and agent-specific permissions. |
| Independent completion | Required controller-owned review and verified repair loop after authoring. | Code review is a Codex capability, but not the same CritiqueCode separation between author and reviewer. | You assemble review with extensions, prompts, tests, or a separate tool. | Includes /review, reviewer/advisor concepts, and dedicated review subagents. | Plan mode and custom read-only agents help review; an independent controller is your configuration choice. |
| Best for | Teams that want the author loop and the completion loop to remain separate. | Developers invested in OpenAI models and a connected local, IDE, app, and cloud workflow. | Developers who want a small, understandable, extensible terminal foundation. | Power users who want a deep terminal-native surface without giving up provider choice. | Developers who want a broad open-source agent interface with configurable permissions. |
1. CritiqueCode: open source authoring with a completion boundary
CritiqueCode is the outlier in this list because its defining feature is not simply that it can write code. It is an author agent designed to implement in an interactive session and then pass through a controller-owned review and verified-repair loop.
Install @critiquedotsh/harness and run critique-code inside the repository you want to change. You can use Critique Inference through critique-code login, bring provider keys through /keys, or run the local TTY and browser modes. The author can request a workspace check with critique_run; you approve or deny the request.
That separation is useful when your concern is not “can an agent edit this file?” but “who challenges the patch before we call it finished?” CritiqueCode does not claim that a clean review proves correctness. It makes the uncertainty visible and keeps the author from promoting its own narration into evidence.
2. Codex CLI: open-source local agent inside a broader product
Codex is a strong choice if you want OpenAI’s models and a connected experience across the terminal, IDE, desktop app, and cloud. OpenAI describes the Codex CLI as an open-source command-line coding agent that can read, modify, and run code locally. The wider Codex experience adds skills, worktrees, cloud tasks, and parallel agent workflows.
The trade-off is scope. The open-source CLI is inspectable, but Codex is not only a repository you clone. It is also a model and service ecosystem. Evaluate the exact surface you intend to standardize: local CLI behavior, IDE integration, cloud execution, account requirements, approval mode, and network policy.
Codex is a good fit for teams that want a polished OpenAI-native workflow and do not need every layer of the surrounding service stack to be self-hostable. Add a separate review boundary when your organization needs reviewer independence rather than an author’s built-in review command.
3. Pi: the minimal open source terminal foundation
Pi is the right kind of small. Its official documentation describes a minimal terminal coding harness extended through TypeScript extensions, skills, prompt templates, themes, and Pi packages. The repository also includes a unified multi-provider API and agent runtime, so the core is more than a one-off shell wrapper.
The honest trade-off is security composition. Pi’s security documentation says it runs with the permissions of the user account that starts it and does not include a built-in permission system or sandbox. That can be a reasonable design for a local tool you understand, but it means the operator owns the container, micro-VM, or policy layer when stronger isolation is required.
Choose Pi when you value a small core, transparent extension points, and control over the shape of the session. Do not choose it because “open source” sounds like a security feature. The runtime boundary still needs engineering.
4. Oh My Pi: Pi’s batteries-included fork
Oh My Pi is a fork of Pi that pushes in the opposite direction from minimalism. The project describes a Rust core, 60+ providers, 31 built-in tools, LSP operations, debugger operations, native search and shell behavior, first-class subagents, memory, collaboration, and a reviewer/advisor model.
Its distinguishing idea is that the harness should understand more of the developer’s environment. LSP can inform renames and diagnostics. Debug adapters can help an agent inspect a live failure. Typed subagent results and isolated worktrees can make fan-out less dependent on parsing prose. The project also documents a /review workflow that produces priorities and a verdict.
That power comes with a larger operational surface. Provider routing, native binaries, debugger adapters, memory backends, permissions, and model roles all deserve a threat-model review. Oh My Pi is compelling for power users who want depth out of the box; it is less attractive if your goal is the fewest moving parts.
5. OpenCode: the broad open-source generalist
OpenCode is the generalist in this comparison. Its official docs position it as an open-source AI coding agent available in terminal, desktop, and IDE forms. You can initialize a repository with /init, switch between Plan and Build, define custom agents, invoke subagents, connect tools through MCP, and request structured output through the SDK.
OpenCode also documents granular permissions. A project can set a catch-all rule to ask, allow, or deny, then override commands or paths—for example, allowing git * while denying rm *, or permitting edits only in a specific documentation path. Agents can have their own permissions, and external directories have a separate control.
Choose OpenCode when you want a widely used open-source agent with a large interface surface and a configurable policy model. Its review story is flexible rather than automatic: Plan mode and a custom read-only reviewer are useful, but a team that needs mandatory independent adjudication must add that workflow around the author.
Open source is not the same as safe, local, or model-agnostic
These terms are often used interchangeably in comparison posts. They should not be.
| Question | What it actually asks | Why it matters |
|---|---|---|
| Is the code open source? | Can you inspect, modify, fork, and redistribute the relevant project under its license? | Useful for auditability and ownership, but it says nothing by itself about runtime defaults or hosted services. |
| Does it run locally? | Does the agent process and repository work happen on your machine or your own infrastructure? | Local execution can reduce control-plane dependence, but model calls may still send code or prompts to a provider. |
| Is it model-agnostic? | Can you change providers or models without replacing the harness? | Provider choice can help with cost, latency, capability, residency, and fallback strategy. |
| Is it safe by default? | What can the agent read, write, execute, access over the network, or reach outside the worktree before approval? | The default permission boundary determines the blast radius of a bad prompt, compromised dependency, or prompt injection. |
How to choose the best open source coding harness
- 1Do you want to self-host the author runtime and keep the core small?Shortlist Pi, then add your own sandbox and review layer. Pi gives you a clean extension model, but the security boundary is your responsibility.
- 2Do you want a deep, open, multi-provider developer environment?Shortlist Oh My Pi or OpenCode. Pick Oh My Pi for native tooling depth and Pi-derived power-user workflows; pick OpenCode for broad interfaces, Plan/Build, and policy configuration.
- 3Do you want OpenAI models and a connected product experience?Shortlist Codex. Evaluate the local CLI separately from the app, IDE, and cloud surfaces your team will use.
- 4Do you want the author to be challenged before completion?Shortlist CritiqueCode, or keep your preferred open author and add the separate Critique CLI sidecar for an independent finish pass. CritiqueCode is the author package; Critique CLI is the sidecar package.
- 5Do you need auditability at the merge boundary?Choose a workflow that records what changed, what checks actually ran, which findings were promoted, and how repairs were verified. A transcript or green test summary alone is not an audit trail.
A note about CritiqueCode and the Critique CLI
Critique publishes two different packages, and this comparison is a good place to make the distinction explicit. CritiqueCode is @critiquedotsh/harness, binary critique-code: the author agent. Critique CLI is @critiquedotsh/cli, binary critique: the sidecar reviewer for an author you already run, such as Codex, Pi, Oh My Pi, or OpenCode.
| If you already use… | Use… | Why |
|---|---|---|
| Codex, Pi, Oh My Pi, or OpenCode | @critiquedotsh/cli → critique | Keep your existing author and add a separate review pass when you want an independent challenge before merge. |
| No preferred author, or you want Critique’s loop | @critiquedotsh/harness → critique-code | Let CritiqueCode implement locally, then force the author through controller-owned review and verified repair. |
Final verdict
Pi is the best open source coding harness for developers who want a minimal, extensible foundation. Oh My Pi is the best fit for power users who want a Pi-derived harness with native tooling, LSP, debugging, memory, subagents, and review already close to the surface. OpenCode is the best generalist for developers who want a broad open-source product with terminal, desktop, IDE, agents, SDK, and granular permissions. Codex is the best fit for teams who prioritize OpenAI’s models and a connected local-to-cloud workflow while accepting that the CLI is one part of a larger product. CritiqueCode is the best fit when the key requirement is a separate completion contract: author, review, repair, verify.
The most robust setup may not be one harness. Use the author you like, then put independent review at the boundary where code becomes a merge candidate. Open source gives you more visibility and control. It does not remove the need to define permissions, inspect providers, pin dependencies, test failure modes, and decide what evidence is strong enough to ship.