# Open Interpreter: a Rust fork of Codex whose build still calls the binary codex

> The project is an OpenAI Codex fork that reimplements provider harnesses in Rust, and its stated purpose is getting better results out of cheap models. The interesting parts are the ten switchable harnesses, the Codex-compatible path, and how much of the upstream repository is still visible underneath.

**openinterpreter/openinterpreter** — Open Interpreter is a terminal coding agent optimized for low-cost open models like Kimi K3, reimplemented in Rust with a Codex-like interface and switchable harnesses.

- Repository: https://github.com/openinterpreter/openinterpreter
- Website: http://openinterpreter.com/
- Stars: 68,476 · Forks: 5,884
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/openinterpreter-openinterpreter

## The fork's own build still calls its binary codex

Open Interpreter is a fork of OpenAI's Codex, and the upstream layout is still visible in the repository. The top level carries `codex-cli/`, `codex-rs/` and `sdk/`, alongside `FORK_BRANDING.md`, a `NOTICE` file, `patches/` and `third_party/`. The root package.json is still named `codex-monorepo` with the description "Tools for repo-wide maintenance", and its only real scripts are documentation locale checks, a Prettier format pass, and a hook schema writer that shells into `codex-rs/Cargo.toml`.

The developer entry points match. The justfile sets its working directory to `codex-rs` and runs `cargo run --bin codex` for the main binary, with separate recipes for `exec`, the file-search crate and a code-mode host. The consequence is that building from source means building Codex's crate layout, and a contributor looking for where Open Interpreter's own logic lives has to distinguish the forked structure from the new work. That is normal for a young fork, and it is also why reading the tree tells you more about the project's age than its version number does.

## Ten harnesses, and /harness is the only control

The stated aim is emulating the agent harness that gets the best performance out of low-cost models, and `/harness` switches the active one. The list in the README runs to ten: `native`, `claude-code`, `claude-code-bare`, `zcode`, `kimi-code`, `kimi-cli`, `qwen-code`, `deepseek-tui`, `swe-agent` and `minimal`. The recent work has been on the Kimi end, with the provider-recommended Kimi Code harness reimplemented in Rust for a Codex-like interface.

The consequence is that the agent's behaviour is a runtime setting rather than a property of the build. A prompt tuned under `swe-agent` is not the same prompt under `minimal`, and a model that performs well in one harness may not in another, which makes any benchmark you run conditional on the harness you selected. It also means the harness list is a compatibility surface: each entry is an emulation of someone else's agent loop, and the project is betting that keeping up with those loops is a better use of effort than improving one of them.

## Adopting it under the Codex SDK is a one-line path override

The compatibility story is unusually concrete. Open Interpreter speaks the same Codex exec protocol, so a codebase already built against the Codex SDK keeps the SDK and changes one argument:

```diff
-const codex = new Codex();
+const codex = new Codex({ codexPathOverride: "interpreter" });
```

For editors, the integration is the Agent Client Protocol, with the client configured to launch `interpreter acp`. There is also a local check you can run without a provider, `scripts/test-codex-sdk-compat.sh`, described as a provider-free compatibility test.

The consequence is that you are substituting a binary rather than adopting an API, and everything that follows from that applies. You inherit the protocol's capabilities and its limits, you cannot use a Codex SDK feature that this binary does not implement, and the only offline signal you get is that shell script. For an existing Codex integration this is the cheapest possible migration path in this article. For a new one, it is worth knowing that the protocol, not the Rust code, is the real contract.

## Skills live in two directories, and the old one is read-only in practice

Portability is an explicit product goal: prefer shared, tool-neutral standards, keep user-authored data in readable files, and make moving to or from another compatible agent straightforward. Today that means repository `AGENTS.md`, shared `.agents/skills` directories, MCP, ACP and the Codex exec protocol.

The boundary is stated just as precisely. Product-specific storage under `~/.openinterpreter` is reserved for configuration and runtime state that does not yet have a practical shared standard. Legacy product-specific skill directories remain readable for compatibility, but new skills belong in `.agents/skills` or `~/.agents/skills`. The consequence is a two-location reality for anyone who used the earlier layout. Existing skills keep working, which is the point, and nothing warns you that the directory you have been writing to is the one the project has stopped extending. A migration step is implied and not automated.

## Computer use is delegated to agent-browser and trycua

The project ships a QA skill that lets any model operate and test interfaces. What drives them is not in this repository. Web apps are driven in a real browser through agent-browser, and native desktop apps are operated and tested through trycua, both separate projects with their own release cycles.

The consequence is that the computer-use path is only as dependable as those two dependencies, and the QA skill is the integration rather than the driver. A team standardising on this project for interface testing is standardising on a skill that wraps code it does not control, so an upstream breaking change arrives as a failure in Open Interpreter with no changelog entry here. It is a reasonable division of labour, since browser automation and native app automation are large problems on their own, and it is worth naming so that nobody assumes the capability is first-party.

## Installation pipes a script from a URL on both platforms

On macOS and Linux the documented install is a single line:

```bash
curl -fsSL https://www.openinterpreter.com/install | sh
```

On Windows it is the PowerShell equivalent:

```powershell
irm https://www.openinterpreter.com/install.ps1 | iex
```

Afterwards you type `i` or `interpreter` to start a session. The consequence is that installation executes a script fetched at the moment you run it, with nothing pinned and nothing to inspect first. On a workstation that is a normal convenience, and on a machine with credentials or a restrictive change process it is the step that gets blocked or demands an exception. The README also links a full install guide and a terminal quickstart, which is where a team that needs a pinned or audited install should start, since the one-liner itself offers no version selector.

## The release line is 0.0.x, and the client story lives in another repo

Releases are tagged with a `rust-v` prefix and sit below 1.0: rust-v0.0.45 on 2026-09-20, rust-v0.0.44 on 2026-09-15 and rust-v0.0.43 on 2026-09-14, with the last push to the repository on 2026-09-27. Three releases in six days on a 0.0.x line, under Apache-2.0, with `CHANGELOG.md`, `RELEASE_NOTES.md` and `SECURITY.md` at the root and readmes maintained in English, Spanish, Simplified Chinese and Japanese.

Client software is where the fork is thinnest. For a browser interface the README points at a local streaming web chat guide and describes it as a small UI over raw Open Interpreter, and for anything complete it points to Interpreter Workstation as a separate repository covering desktop, browser and headless use. The consequence is that a 0.0.x line plus an external GUI means you are choosing a moving binary and a separately versioned front end, so pinning the CLI does not pin the experience.

## Conclusion

Open Interpreter makes sense if your constraint is model cost rather than capability, and if you already live in the Codex ecosystem, because the SDK override and the exec protocol mean adopting it is a binary swap rather than a rewrite. Three things narrow that. The harness is a runtime choice, so behaviour is not fixed and results are not comparable across harnesses. Computer use is delegated to two external projects, and the first-party client story is a small web chat guide plus a separate Workstation repository. And the install path pipes a script straight from a URL. Before adopting it, verify three things: which harness you are actually running, whether the Codex SDK override covers the calls you need, and where your skills live, because new ones belong in `.agents/skills` while the legacy location stays readable only.

## FAQ

### How do I install open interpreter?

On macOS and Linux run `curl -fsSL https://www.openinterpreter.com/install | sh`, and on Windows run `irm https://www.openinterpreter.com/install.ps1 | iex`. Then type `i` or `interpreter` in your terminal to start a session. A full install guide and a terminal quickstart are linked from the README.

### How do I use open interpreter?

Start a session and pick a harness with `/harness`, which switches between `native`, `claude-code`, `claude-code-bare`, `zcode`, `kimi-code`, `kimi-cli`, `qwen-code`, `deepseek-tui`, `swe-agent` and `minimal`. You can switch providers and models from the TUI with `/model`, and run any OpenAI-compatible provider through Chat Completions with `interpreter --chat-completions`.

### Can I use open interpreter with Ollama?

The README does not name Ollama. What it documents is that any selected OpenAI-compatible provider can run through Chat Completions using `interpreter --chat-completions` or `interpreter exec --chat-completions`, with dedicated provider setup guides for Kimi K3, DeepSeek, and Z.AI, GLM and ZCode. The provider guides page is where an unlisted provider would be covered.

### What are the differences between Open Interpreter and Claude Code?

Open Interpreter is a fork of OpenAI's Codex, and `claude-code` and `claude-code-bare` are two of the ten harnesses it can emulate through `/harness`. It speaks the Codex exec protocol and runs as an Agent Client Protocol agent via `interpreter acp`, so the comparison is between a multi-harness binary and a single agent, not between two equivalent tools.

### Does open interpreter work in VS Code?

It works through the Agent Client Protocol, which covers ACP-compatible editors and clients. You configure the client to launch `interpreter acp`, and the ACP guide in the documentation has the configuration examples.

## Sources

- [Official documentation](http://openinterpreter.com/)
- [Official README](https://github.com/openinterpreter/openinterpreter#readme)
- [Project repository](https://github.com/openinterpreter/openinterpreter)
- [Release notes](https://github.com/openinterpreter/openinterpreter/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openinterpreter-openinterpreter