# open-claude-code rebuilds the Claude Code CLI from decompiled source intelligence

> open-claude-code is an MIT licensed clean-room reimplementation of Anthropic's Claude Code CLI, built with AI assisted decompilation of the published npm package and shipped as nightly verified releases. It suits developers who want to read, extend or self-host an agent CLI rather than install a proprietary binary, and the project is explicit that full parity with upstream is not established.

**ruvnet/open-claude-code** — Nightly Claude Code CLI Decompile — Reverse Engineered & Rebuilt

- Repository: https://github.com/ruvnet/open-claude-code
- Website: https://github.com/ruvnet/RuVector
- Stars: 542 · Forks: 166
- Language: JavaScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ruvnet-open-claude-code

## What the project is, and what it deliberately is not

The README's own framing is precise and worth quoting, because the marketing around projects like this is usually vague. Open Claude Code is a ground-up open source rebuild of Anthropic's Claude Code CLI, informed by ruDevolution's AI powered decompilation of the published npm package.

The next line sets the boundary: it's not a copy, it's a clean-room implementation that mirrors the actual Claude Code architecture, with an async generator agent loop, 25 tools, 4 MCP transports, 6 permission modes, hooks, a settings chain and sessions. The repository topics use the same vocabulary, with claude-code, clean-room, clean-room-reimplementation and decompiler.

So the interesting question for an engineer is what decompilation of a published npm package actually buys you, and the answer is written into the architecture claim. You get the observable behaviour of the upstream tool, the shapes of its extension points and a licence you can read, in a codebase you can change. What you do not get is upstream's source, and the README does not claim it does.

The scale is stated in the badges and repeated in the text: 1,008 unit tests plus installed-package behavioral checks, and then the sentence that matters most for anyone considering production use, that full upstream parity is not established. The homepage points at ruvnet/RuVector, and the decompilation toolchain lives in the separate ruvnet/rudevolution repository, which is also a submodule of this one.

The licence is MIT, and the package is published to npm as @ruvnet/open-claude-code.

## The nightly release pipeline that gates what gets published

The badges in the README advertise a nightly verified release pipeline with four stages, detect, validate, test and publish, and the release automation note explains the rule: a successful run is the evidence of completion, and failed runs do not advance checkpoints.

That is a more interesting design than it first appears. A decompilation-driven rebuild changes when the upstream package changes, and a project that tracked upstream by hand would be stale most of the time. So the pipeline runs every night, and what gets published depends on automated checks rather than on a person deciding to cut a release.

The listed releases show the cadence and the versioning. There is v2.1.3-nightly.20261020.212 from 2026-10-20, v2.1.3-nightly.20261019.211 from 2026-10-19 and v2.1.3-nightly.20261017.209 from 2026-10-17, and the release names carry the word Verified. The numbers after the date are a sequence number, which is what you would expect from a pipeline that publishes as often as it passes.

The README also notes that capability proposals require review before implementation, and points at ADR-004 for the release workflow. The repository structure supports the picture: there is a .github/ directory holding the workflows, a docs/ directory with an adr/ subdirectory for the architecture decision records, a scripts/ directory for the end-to-end test scripts, and a skills/ directory holding the shared skills.

## Running it: npx, global install, and the API key requirement

The quick start gives three ways in, and the first needs no installation at all.

```bash
# Run instantly (no install)
npx @ruvnet/open-claude-code "explain this codebase"

# Or install globally
npm install -g @ruvnet/open-claude-code
occ "hello"

# Interactive mode
occ
```

The global install gives you the occ command, and the README's usage section shows both modes. One-shot mode passes a prompt directly, for example occ "explain the auth module" or occ "find all TODO comments in this project". The interactive REPL starts with occ and then takes commands, with /help, /tools, /model, /cost and /exit among them, and a model switch such as /model claude-opus-4-6.

The CLI options list shows the shape of the tool. The command is occ [options] [prompt], with -m and --model for the model and a default of claude-sonnet-4-6, and -p and --print.

One requirement is non-negotiable and stated in bold in the README: the ANTHROPIC_API_KEY environment variable has to be set.

```bash
export ANTHROPIC_API_KEY=sk-ant-...
npx @ruvnet/open-claude-code "what files are in this directory?"
```

This is worth pausing on. A clean-room rebuild of the CLI is not a self-hosted model. The open implementation is the client, and it talks to Anthropic's API with your key, exactly as the packaged tool does. What you gain from the rebuild is a readable and modifiable client, not a way to run without a provider account.

Building from source is also documented, and it involves a submodule, since the rudevolution directory in the tree is a submodule rather than vendored code:

```bash
git clone https://github.com/ruvnet/open-claude-code.git
cd open-claude-code/v2
export ANTHROPIC_API_KEY=sk-ant-...
node src/index.mjs "hello"
```

The source lives in the v2/ directory, which explains the .gitmodules entry and the separate v2/ and archive/ directories at the top level, the latter presumably holding earlier generations of the work.

## The upstream behaviour fixes that define what 2.1.3 actually does

The most useful section in the README is the table of upstream behaviour fixes, because it tells you exactly which upstream features this rebuild has caught up with. It was implemented and tested against the public Claude Code 2.1.295 and 2.1.296 changelog.

The hook failure policy is covered: command and HTTP hooks honour onFailure: "block", and an exit 2 vetoes execution. The PreToolUse veto is covered, where continue: false and a structured deny block the call and return an error result to the next model turn. PostToolUse MCP output is covered, with updatedMCPToolOutput replacing results for MCP tool names.

Three of these are safety behaviours rather than features, which is the right thing to copy first. Large text reads honour Read.allow_large: true to bypass the implicit 2,000 line limit, though explicit offset and limit arguments stay active. Encoding safety means Edit, MultiEdit and NotebookEdit reject invalid UTF8 before any write. Delegation safety means child tools intersect parent tools and inherit permission checks and hooks.

There are hard numbers attached, and they are the kind of detail that separates an approximation from an implementation. Large text reads have ceilings of 16 MiB and 100,000 lines. HTTP hook responses are capped at 1 MiB. Typed hook timeouts use seconds while legacy flat hook timeouts keep milliseconds, which is a genuine source of bugs in a port. Plain command stdout remains supported.

The agent limits are stated too: subagents default to at most 10 model calls, delegation depth 2 with a hard maximum of 3, and at most 4 running background agents. An explicit empty child tool list grants no tools, and worktree isolation requests are rejected until isolation is implemented, which is a refusal rather than a stub.

## Three skills, and the plugin that installs them

The project ships three shared skills covering CLI usage, diagnosis and release verification, and the README is explicit that you should choose one installation method to avoid duplicate skills.

The skills installer route requires Node 22.20 or newer, with Node 24 recommended, and the tested installer version is skills 1.7.2. OCC itself needs Node 20 or newer, a lower floor than the installer, which is worth knowing if you run the CLI on an older Node.

```bash
npx skills@1.7.2 add ruvnet/open-claude-code --agent claude-code --skill occ-use occ-diagnose occ-verify-release
```

There is also a native Claude Code plugin, installed from inside Claude Code with slash commands:

```text
/plugin marketplace add ruvnet/open-claude-code
/plugin install occ@ruvnet-occ
/occ:occ-use
/occ:occ-diagnose
/occ:occ-verify-release
```

You restart Claude Code after installation if the current session has not loaded the new skills, and the plugin can be updated or removed with claude plugin update occ@ruvnet-occ and claude plugin uninstall occ@ruvnet-occ.

Two details in that paragraph matter for anyone installing this into an existing setup. The occ plugin uses the same skills/ sources and installs no hooks, no MCP servers, no credentials and no background processes, so it is a passive set of instructions rather than an active extension. It also does not imply compatibility between OCC's custom PluginLoader and all third party Claude plugins, which is a warning about coexistence with other plugins in the same session.

Project-level skills also load from .claude/skills, including the installer's symlinks, and project skills override user skills, so a repository can carry its own version of the skill and shadow the one in your home directory. That is the mechanism to be aware of if you find your behaviour changing after cloning a repository.

The README documents how to reproduce the installation tests yourself, with node scripts/plugin-e2e.mjs, optionally with the repository slug to test public GitHub distribution after publishing. The suite installs and removes real skills and plugins in disposable profiles and checks all three skill expansions against a local model fixture, with live provider behaviour tested separately by scripts/live-package-e2e.mjs. The tested Claude Code version is 2.1.283.

## The gaps, and how this differs from the packaged tool

The README keeps a list of what this release does not do, and it is the most decision-relevant part of the document. Prompt and agent hook evaluators, asynchronous hooks, complete session and checkpoint lifecycle wiring, and full provider parity remain outside this release. The lifecycle issue is still open for those gaps, and ADR-006 documents the upstream behavioural contracts.

Those are not small omissions. Complete session and checkpoint lifecycle wiring is what makes a long-running agent session resumable, and without it the rebuild is a capable one-shot tool rather than a durable agent. Asynchronous hooks are how a hook can trigger work without blocking a tool call. Neither is present.

The alternative approaches differ in kind rather than in degree. Using the packaged Anthropic CLI gives you upstream's own implementation and its own update path, with no source to read and no licence to inspect. Running a different open agent CLI gives you a readable implementation but a different behaviour model, so your prompts, hooks and tool expectations have to be rewritten rather than ported. Driving the Anthropic API directly from your own code gives you full control and the entire cost of implementing the loop, the permission model and the tool protocol yourself.

open-claude-code sits in the middle of that last pair. It is the same protocol and the same provider, so the same ANTHROPIC_API_KEY and the same model names apply, but the implementation is yours to read and change, and the gaps above are where the behaviour will differ from what you are used to.

For most people evaluating this, the sensible first step is not to replace their daily tool. It is to read the implementation, because it is MIT licensed and the architecture is documented, and to check ADR-006 against the upstream changelog for the version of Claude Code they actually use.

## Conclusion

Adopt open-claude-code if you want to read the internals of an agent CLI, extend it, or run it without installing Anthropic's packaged binary, since the whole repository is the implementation and the skills ship with it. Do not adopt it as a drop-in replacement for the upstream CLI in production work, because the README states that full upstream parity is not established and that prompt and agent hook evaluators, asynchronous hooks, complete session and checkpoint lifecycle wiring and full provider parity remain outside this release. Before you commit, check the ADR-006 document for the behavioural contracts and the still open lifecycle issue, and confirm your Claude Code version against the upstream changelog the 2.1.3 fixes were tested against. The licence is MIT, the nightly pipeline published v2.1.3-nightly.20261020.212 on 2026-10-20, and the last push was on 2026-10-20.

## FAQ

### What is open-claude-code?

It is a ground-up open source rebuild of Anthropic's Claude Code CLI, informed by ruDevolution's AI powered decompilation of the published npm package. The README describes it as a clean-room implementation rather than a copy, mirroring the upstream architecture with an async generator agent loop, 25 tools, 4 MCP transports, 6 permission modes, hooks, a settings chain and sessions.

### How do I run open-claude-code without installing it?

Use npx @ruvnet/open-claude-code "your prompt here". To install it globally, run npm install -g @ruvnet/open-claude-code, which gives you the occ command, and occ with no arguments starts the interactive REPL.

### Does open-claude-code need an Anthropic API key?

Yes. The README states that the ANTHROPIC_API_KEY environment variable is required, with the example export ANTHROPIC_API_KEY=sk-ant-... . The rebuild is a client implementation, not a self-hosted model, so it talks to Anthropic's API with your own key.

### How do I install the open-claude-code skills?

Either with the skills installer, npx skills@1.7.2 add ruvnet/open-claude-code --agent claude-code --skill occ-use occ-diagnose occ-verify-release, which needs Node 22.20 or newer, or as a native Claude Code plugin with /plugin marketplace add ruvnet/open-claude-code followed by /plugin install occ@ruvnet-occ. The README says to choose one method to avoid duplicate skills.

### What does open-claude-code not yet support?

Prompt and agent hook evaluators, asynchronous hooks, complete session and checkpoint lifecycle wiring, and full provider parity remain outside this release, and the README states that full upstream parity is not established. The lifecycle issue for those gaps is still open and ADR-006 documents the upstream behavioural contracts.

### What licence is open-claude-code released under?

MIT, published to npm as @ruvnet/open-claude-code. The repository also ships nightly releases tagged with a Verified suffix, such as v2.1.3-nightly.20261020.212, gated on source validation, tests, AI analysis and registry checks.

## Sources

- [License: MIT](https://github.com/ruvnet/open-claude-code/blob/main/LICENSE)
- [Project website](https://github.com/ruvnet/RuVector)
- [README](https://github.com/ruvnet/open-claude-code/blob/main/README.md)
- [Releases](https://github.com/ruvnet/open-claude-code/releases)
- [ruvnet/open-claude-code on GitHub](https://github.com/ruvnet/open-claude-code)

---

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