Claude Code is the most-discussed terminal agent in software, and almost none of its code is public. The binary you install is proprietary, licensed under commercial terms, and built somewhere you cannot read. So why does the repository deserve a source tour? Because this is not a mirror of the product — it is the product’s open surface, and it is more instructive than most projects’ full source. Four mods that ship compiled into the binary publish their complete TypeScript here. Thirteen official plugins demonstrate the entire extension format in markdown and Python. The infrastructure automation that runs Claude against the project’s own issues sits in the same tree, next to a checker that fails the build the moment any workflow breaks the security rules for calling Claude. If you want to know how the most commercially successful coding agent expects to be extended, hardened, and operated, this repository is the specification, written in working code.

The architecture reads as three rings around a hidden center. The center is the engine itself, present only as a name in README files and as type declarations. The inner ring is the mods — four TypeScript hook modules under mods/ whose README explains a genuinely novel design: each one is a register(on, options) entry that hooks engine events with middleware-style functions, and they coordinate through typed “noun contracts” rather than direct calls. The middle ring is the plugins — self-contained folders of slash commands, subagents, skills, and hooks, from a five-agent review crew to a plugin that watches your conversations and writes enforcement hooks for behaviors it catches you repeating. The outer ring is operations: GitHub workflows that triage issues with the agent itself, a hardening job that polices those workflows, and gateway examples that put corporate cloud endpoints in front of the binary. As always in this series, what follows is an educational tour of published source code.

Claude Code at a glance: the closed engine exposes its contracts and marketplace, four built-in mods seat themselves around it, official plugins demonstrate the extension format, repository automation runs the agent on its own issues under a hardening checker, and gateway examples route enterprise traffic.

Reading the overview from left to right:

• The install story documents the proprietary binary this repository surrounds.
• The typed extension surface is the declaration file mods import against, including the testing kit.
• The plugin catalog lists every official plugin the install command can fetch.
• The security seat keeps an organization’s managed policy out of reach of installed plugins.
• The diff pane module renders uncommitted changes beside the transcript as edits happen.
• The instruction loader gives AGENTS.md files the same treatment the engine gives CLAUDE.md.
• The rule engine matches enforcement rules against tool calls for the hookify plugin.
• The hardening checker fails CI when a workflow calls Claude without the required protections.

Why You Need This

The first reason is the mods, because they are the deepest public look at how a closed product structures its own extension points. The mods README defines the pattern: a mod is a plugin whose behavior lives in one register(on, options) function, where on subscribes to engine events and each handler is a ($, e, next) function — middleware, with next continuing down the chain. The diff module uses it to keep a pane of uncommitted changes current, probing the terminal first through its backend detection. The composition rule is the elegant part: the telemetry module owns the $.telemetry noun and keeps its types in one declaration file, and any mod that records events imports that contract rather than copying it — the typechecker rejects an implementation that drifts from what callers read. The security seat sits outermost on managed machines, and its verdict ranking decides how permission decisions from users and policy tiers outrank each other. Add the testing kit — mock.clock, mock.env, a tier('builtin') harness that answers engine calls from memory — and you have a complete essay on plugin architecture published as a side effect of shipping a binary.

The second reason is the plugin format, because the thirteen folders under plugins/ are the reference implementations Anthropic ships for it. The structure is deliberately boring — a manifest, a hooks manifest, and directories of markdown — and the structure skill teaches it in three hundred seventy lines. The interesting part is what the format can express. hookify is a self-writing enforcement system: a conversation analyzer reads your transcripts for repeated unwanted behavior, the rule engine turns the findings into matchable rules, and a PreToolUse hook intercepts every tool call to apply them. The review command runs five parallel reviewer agents and filters their findings through confidence scoring to suppress false positives. ralph-wiggum loops the same task until completion, with a Stop hook that refuses to let the session end. And security-guidance matches edited code against nine pattern classes — command injection, eval, unsafe deserialization — to warn before risky changes land.

The third reason is the automation, because this repository is a worked example of an agent maintaining its own project under guardrails. The triage workflow labels and routes new issues, claude.yml answers @claude mentions, and a maintenance script handles duplicate reports and lifecycle comments. None of that runs on trust: the hardening workflow invokes three hundred five lines of Python that verify every Claude-calling job runs on an egress-firewall runner, keeps a network allow list in enforce mode, and requires explicit permission modes on every step — with an exemption table for the jobs that cannot comply and a rule that the build fails when protections are weakened. The repository even documents its own rules in a CLAUDE.md written for coding agents, and ships gateway examples showing how enterprises route the binary through AWS Bedrock or GCP Vertex instead of the public endpoint.

The detail view: the engine hub and its contracts on the left, the four built-in mods with their internals, the official plugins from hookify to security guidance, the GitHub automation layer with its hardening checker, and the cloud gateway examples on the right.

The detail view shows how the rings interlock. Every mod edge runs through the declaration file — the diff register probes backend renderers, the agents-md register walks for unseen instruction files, the security seat ranks verdicts and gates admission — so the types are the coordination point, not a shared runtime. On the plugin side, the flows are end-to-end: the hookify command spawns its analyzer, the analyzer feeds the rule engine, the engine is enforced by the PreToolUse process; the security reminder hook matches patterns on every file edit. The automation layer closes on itself — the hardening checker audits both Claude workflows, the triage workflow delegates to the sweep script — which is the picture of a project that lets the agent act but keeps the enforcement in code humans review. The GCP counterpart completes the deployment story with Vertex routing and its own Terraform.

From Install to a Hardened Session

Installation is one line — curl -fsSL https://claude.ai/install.sh | bash on macOS or Linux, irm https://claude.ai/install.ps1 | iex on Windows, or a Homebrew cask and a winget package — after which running claude in any project directory starts the session. To see the extension system from the receiving end, run /plugin and install from the marketplace catalog, or read a built-in mod running from source with claude --plugin-dir mods/diff — the README’s own suggestion. If you want to build rather than observe, the plugin-dev plugin is a bootstrapping kit: its create-plugin command walks eight phases with validator agents, and its seven skills cover commands, subagents, hooks, skills, MCP integration, and settings. For contributors to this repository specifically, tsc -p mods/tsconfig.json typechecks every mod against the contracts, and claude plugin test mods/diff runs a mod’s tests against a mock engine — the same gates the repository’s own CI applies before anything merges.

Honest limits: the engine is not here, so no amount of reading explains the model-facing internals — context management, tool scheduling, the terminal UI all stay opaque. The license is Anthropic’s commercial terms, not an open-source license, so the code you can read is reference material rather than something you can fork into a product. The hooks-module API the mods use is marked early access and may change between releases without notice, and the mods are deliberately excluded from the marketplace listing since the copies that matter ship in the binary. Finally, the plugins are examples by the project’s own description — good ones, but examples — so production teams should treat them as starting points and review the hooks before installing them anywhere that matters.

Enjoyed this post? Never miss out on future posts by following us