Open-ClaudeCode: a source-map reconstruction of the Claude Code CLI

What the archive actually contains, and who it is for

The README describes Open-ClaudeCode as a research archive assembled from the source maps Anthropic published inside the Claude Code npm package. The repository holds three distinct things that are easy to conflate. The first is a runnable build under package/: cli.js at 12.5 MB, its accompanying cli.js.map at 57 MB, a package.json, a Bun lockfile, an sdk-tools.d.ts type definition of 117 KB, and a vendor directory with native binaries for audio capture and ripgrep across six platforms. The second is src/, 1,902 recovered TypeScript files split into tools, commands, services, components, ink, utils, hooks and bridge. The third is plugins/, thirteen directories including code-review, commit-commands, feature-dev, pr-review-toolkit and security-guidance. The audience is narrow and specific: engineers who want to read how a production AI coding assistant is structured, and who are willing to treat the code as documentation rather than as a base to build on. The README's own framing is research and study, and the acknowledgement section quotes an apology attributed to Anthropic about publishing map files to npm by mistake. That framing matters. This is not a fork with a roadmap.

The module layout is the real product

If you strip away the runnable CLI, what remains is a map of a large TypeScript application. The counts in the README are the useful part: 184 files under src/tools for more than thirty tool implementations, 207 files under src/commands for more than fifty slash commands, 130 files under src/services covering API, MCP and OAuth, 389 React components, 96 files under src/ink for the terminal UI framework, and 564 utility files. That distribution tells you where the complexity lives. The terminal interface is a React application rendered through Ink, which is why components and hooks together account for nearly five hundred files. The services layer is where the model calls, the MCP client and the OAuth flow sit, and it is the smallest of the large directories at 130 files, which is a reasonable place to start reading if you want to understand the request path rather than the rendering path. The bridge directory, 31 files, has no explanation in the README. I cannot tell you from the supplied material what it connects, and the repository does not say.

Getting it running: clone, version check, authenticate

The README gives a three-step start. Clone the repository, check that node --version reports 18.0.0 or higher, and run node package/cli.js --version, which the README says should print 2.1.88. Then run node package/cli.js. Authentication has three documented paths. The first is a third-party proxy, intended for users in mainland China, configured through a settings.json file containing an env block with ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN, loaded with node package/cli.js --settings settings.json. The second is the official Anthropic API, using the same file with only ANTHROPIC_AUTH_TOKEN set to a key in the sk-ant- format. The third is OAuth against a Claude subscription, which the README says opens a browser on first run. There is a fourth configuration route: a global file at ~/.claude/settings.json, read automatically on every launch. The README states that when both an environment variable and a settings file are present, the environment variable wins. It also notes that OpenAI-format proxies such as MiniMax or OpenRouter need a separate protocol bridge project rather than working directly, which is a real constraint rather than a footnote.

Modes, permissions and the flags that change behaviour

Three run modes are documented. Interactive mode is the default: type, press Enter, use /help, /clear, /compact, /model, /theme and /exit. Non-interactive mode uses -p for a single prompt, optionally with --model, and can emit JSON with --output-format json, which is the form you would want if the CLI is a step in a script. Session continuation uses -c to resume the most recent conversation in the current directory, or -r followed by a session id to resume a specific one. Model selection accepts the aliases sonnet, opus and haiku, or full names such as claude-sonnet-4-6. The permission flags are the ones that deserve attention: --permission-mode acceptEdits stops the confirmation prompt on file edits, and --dangerously-skip-permissions removes the checks entirely. The README labels the latter as sandbox-only, and the name is not decorative. Plugins load with a repeated --plugin-dir flag, so node package/cli.js --plugin-dir ./plugins/code-review --plugin-dir ./plugins/commit-commands loads two at once. The examples directory holds three settings variants named strict, lax and bash-sandbox, which is the closest thing to a documented permission model in the material.

The problems the README does not answer

Three gaps stand out. First, the licence. The repository metadata reports NOASSERTION, and the README points to a LICENSE file described only as a licence statement. Nothing in the supplied material tells you what terms apply to the recovered source, and the acknowledgement section explicitly frames the whole archive as reconstructed from an npm package rather than released by its author. Treat the licence as unresolved until you read LICENSE and ACKNOWLEDGEMENTS.md yourself. Second, maintenance. There are no releases, and the only version signal is the 2.1.88 printed by the CLI. The repository was last pushed in July 2026, but a push date is not a support commitment, and there is no stated policy for tracking upstream changes. Reconstructing a new version means re-extracting from a new source map, which is manual work the README does not describe. Third, the size of the artefact. A 57 MB source map and a 12.5 MB bundle are not things you vendor into another project casually. If you want the behaviour, installing Claude Code from npm gives you a supported package with a version policy; this repository gives you the same behaviour plus the source, and the source is the point.

Where a different tool fits better

If your goal is to run an AI coding assistant rather than to read one, the npm package this archive was derived from is the correct choice: it is published by the vendor, it has a version number you can pin, and it updates. If your goal is to build your own assistant, the honest comparison is a framework such as the Agent SDK rather than a reconstruction. The repository itself includes a plugin named agent-sdk-dev under plugins/, and package/sdk-tools.d.ts is a 117 KB type definition file, which suggests the SDK surface is documented in types even though the README does not walk through it. The difference in approach is ownership of the update path. With the SDK you write against a declared interface that the vendor maintains. With Open-ClaudeCode you read an implementation that was recovered from a build artefact and has no interface contract at all. Reading the recovered source is faster than reverse-engineering the bundle yourself, and that is the entire value proposition.

Upgrade cost and what the licence does not settle

Because there are no releases, there is no upgrade procedure in the conventional sense. The unit of change is the source map: when Anthropic publishes a new npm version, the recovered src/ tree corresponds to the old one until someone re-extracts it, and the README gives no script or command for doing so. That means any finding you take from src/ has a shelf life tied to the version printed by node package/cli.js --version, which the README says is 2.1.88. On licensing, I can only report what the material says: the repository metadata is NOASSERTION, the licence is described as a statement rather than a named identifier, and the README attributes the underlying code to Anthropic while describing the extraction as a mistake. Whether that combination permits redistribution, modification or internal use is not something this article can determine, and it is not legal advice. Read LICENSE and ACKNOWLEDGEMENTS.md, and if the answer matters to your organisation, get it from someone qualified to give it.

Editorial conclusion

Adopt Open-ClaudeCode only as a reading copy of the Claude Code architecture. The material supports inspecting src/tools, src/services and src/ink, and running package/cli.js with --plugin-dir against the bundled plugins. Do not adopt it as a product dependency: there are no releases, no upgrade path, and the repository's LICENSE is NOASSERTION, which means the terms are not stated in a form a tool can classify. Verify two things before anything else: the contents of LICENSE and ACKNOWLEDGEMENTS.md, and whether the 12.5 MB cli.js you intend to execute matches the source map you intend to read.

Official sources

1. Issues
2. LING71671/Open-ClaudeCode on GitHub
3. README