HitCC: a documentation knowledge base for the Claude Code CLI runtime

A knowledge base, not a code repository

The README opens by removing the most common misunderstanding. HitCC is not a source code repository, it is a documentation knowledge base for learning, analysis and rewrite work, and the stated goal is not to reconstruct the original file tree. What it aims to recover is Claude Code CLI's core runtime logic, module boundaries, configuration system and surrounding ecosystem, as faithfully as possible, so it can serve as a stable reference for a runnable alternative or a high-similarity rewrite. The repository description calls it complete reverse-engineering documentation of the full logic of the Node.js version v2.1.197, and the top-level entries match that framing: .gitignore, LICENSE, README.md, a Chinese README, a docs directory and a recovery_tools directory. There is no build system, no package manifest and no test suite here, which is the first thing to check if you arrived expecting a runnable project.

The evidence model behind the v2.1.197 baseline

The documentation rests on a specific and unusual chain of evidence. The README describes the current distribution shape as a wrapper package, a platform native binary package, and a JavaScript bundle extracted from the native executable's .bun section. The bundle is the point: the code that runs is recovered from a compiled artefact rather than from a published source tree, which is why the analysis is described as local analysis of the CLI obtained through the package method, together with the extracted bundle from its native binary package. The project also states that it does not rely on Anthropic PBC network services, including LLM inference services, so the documentation is a reading of client-side code rather than an observation of a live service. The version 2.1.197 update also refreshes the runtime entry chain, command surface, background and remote capabilities, Plugin and Skill topics, TUI, control plane, telemetry, abuse, risk and refusal handling, tool execution and contextLayers, and splits several evidence-heavy pages into parent navigation pages and child topic pages so the evidence can be followed along a runtime path.

Getting the input package the analysis is built on

The README gives one command for obtaining the Claude Code CLI package that the repository analyses, and the project states that its findings are based on local analysis of that package plus the bundle extracted from the native binary. The command is:

npm pack @anthropic-ai/[email protected]

That is the whole reproduction recipe for the input, and the pinned version is what makes the documentation verifiable, since the analysis describes one release rather than a moving target. The Python scripts under recovery_tools/ handle the next step, performing an initial round of cleanup on obfuscated or encrypted source code so the extracted bundle can be read. The README is careful about what this is not: the repository does not contain Claude Code original source code, cracking content, or implementations intended to bypass product policies or permission mechanisms, and it is not affiliated with Anthropic PBC. That boundary matters for how you use the output, because the goal on the page is analysis and reference, not circumvention.

docs/ is organised by runtime topic, not by source tree

The knowledge base is explicitly not arranged like the program it describes. The main body lives under docs/docs/, with standalone cross-cutting topics under docs/standalone/, and the navigation runs from 00-overview through 05-appendix. 00-overview holds scope boundaries, evidence sources, confidence terminology and documentation maintenance conventions. 01-runtime covers the CLI entry, command tree, runtime mode dispatch, Session and Transcript persistence and recovery, the input compilation pipeline, the main Agent Loop, the compact branch, model adapter, provider selection and auth, stream events, request telemetry and refusal, remote transport, the two built-in network tools web-search and web-fetch, and the settings sources, paths, merging, caching, write-back and CLI injection schema. 02-execution handles the tool execution core, concurrent execution, the Hook runtime, Permission, Sandbox and Approval, instruction discovery, prompt assembly and context layering. 03-ecosystem covers Resume, Fork, Sidechain, Subagent, agent team, remote persistence, the bridge and its credentials, the Plan system, MCP, Skill, Plugin and TUI. 04-rewrite holds candidate layering, a directory skeleton, open-question tiers and blocking judgments, while 05-appendix keeps the glossary, evidence map and topic maps. For a reader hunting one behaviour, the topic tree is the index; the original file tree, which is not reproduced, would not have helped.

The boundary the project refuses to cross

A list of what is not provided is as informative as the coverage list. The repository does not reconstruct the original source file structure, does not include private server-side implementation details, does not guarantee 1:1 behavioral reproduction, and does not provide a directly runnable CLI, SDK or installation script. The same restraint shows up inside the documentation itself, most clearly in the new standalone page on abuse control and telemetry, which groups prompt markers, request identity, telemetry and logging channels, managed policy limits, execution gates, remote-control trust, gateway safeguards and refusal and fallback handling into a client-side view while keeping private server-side enforcement outside the documented evidence boundary. Read that as a limit on inference as much as on scope. A page describing an execution gate on the client tells you what the client does, not what the server would do with a request that looks abusive, and a rewrite that assumes the latter is guessing.

Parent pages as navigation, child pages as evidence

The maintenance conventions are unusual enough to be worth quoting in spirit, because they explain why the tree looks the way it does. The index page 00-overview/00-index.md is only the global entry point and does not duplicate main content. Parent pages provide navigation and boundary descriptions, not long-form mechanism analysis. Child pages hold the actual content, evidence points, counter-evidence and open questions. Unknowns are centralized in the scope page and the rewrite judgment page so that they are not maintained twice across directory pages, and when new evidence appears the relevant topic page is updated first, with the glossary and evidence map backfilled afterwards. The detailed conventions live in docs/docs/00-overview/02-document-style-and-structure-conventions.md. The practical effect for a reader is that a long page is always traceable back to a specific boundary, and a claim without evidence attached is meant to stand out rather than blend in.

A baseline pinned to one release, and the gap it leaves

The knowledge base is versioned like a software package even though it contains no software. The releases are 2.1.197 on 2026-07-05 and 2.1.84 on 2026-07-01, and the README describes the v2.1.197 update as a rebase of the docs/ knowledge base from the previous v2.1.84 baseline, plus a new standalone topic page and the page-splitting work. The last push to the repository was on 2026-07-05, the same date as the newest release. That gives a clear maintenance picture: the project follows a specific CLI version, rebase work is substantial, and the documentation is not continuously synchronised with whatever version the npm registry currently serves. For a rewrite effort that is a real constraint rather than a defect. Every claim about a runtime path has to be re-verified against the release you are actually building against, and the value of the base grows or shrinks with how close your target version is to 2.1.197.

Scale, licence and the alternative to reading code

The README publishes the size of the knowledge base, with the caveat that the data may not be updated in real time:

TOTAL
  Files: 110
  Lines: 32013
  Chars: 961767
  Bytes: 1288945

That is the scale of what a reader is being asked to absorb, and it frames the practical alternative to this repository. Instead of static analysis of an obfuscated bundle and a topic-by-topic evidence base, a team can observe a running CLI, record its behaviour, and build its own understanding of the command surface and the agent loop from observation, which costs time but requires no reverse-engineering effort and follows whatever version is installed. The two approaches differ in what they can and cannot tell you. Observation captures what the program does on the paths you happen to exercise, including anything enforced server-side, while static analysis of the local package can reach branches you would never trigger and can expose the internal module boundaries, but it stops at the client edge. HitCC also states plainly that it offers boundary judgments, candidate architecture and next evidence work rather than a finished artifact, and its licence is a custom one that GitHub cannot classify, so the LICENSE file is the thing to read before reusing any of the wording.

Editorial conclusion

HitCC is worth reading if you are reverse-engineering a Node.js CLI, if you are planning a from-scratch implementation of a comparable agent loop, or if you need a map of where the tool execution, permission, telemetry and context layering code sits inside one release. It is the wrong tool if you need something you can install and run, since the README states plainly that no directly runnable CLI, SDK or installation script is provided, and the wrong tool if your question is about server-side enforcement, which the project deliberately leaves outside its evidence boundary. Verify first which CLI version the documentation actually describes, because the knowledge base was rebased from v2.1.84 to v2.1.197 and the last push was on 2026-07-05, then read LICENSE directly, because the licence is a custom one that GitHub cannot classify and the README's own License section is cut off after its first characters.

Frequently asked questions

Official sources

1. hitmux/HitCC on GitHub
2. Issues
3. Project website
4. README
5. Releases