Claustodian

A static, versioned, machine-parseable record of every Claude Code CLI flag, environment variable, command, config key, stream-json control message, mods API method, mods event, mods render site, and mods element — each tagged with the version it first appeared in (and, when known, when it was removed). Answer "does feature X exist in Claude Code version Y?" by fetching a file, in any language, with no scraping.

Why

Claude Code ships multiple releases a week and there's no machine-queryable record of when each part of its surface appeared or disappeared. Claustodian is that record: JSON as the single source of truth, published as static files (JSON + generated YAML + TOML) on GitHub Pages.

Quick start

Every version is a static file. To check whether a symbol exists in a version:

# What does the latest snapshot say about --safe-mode?
curl -fsSL https://claustodian.dev/data/latest.json \
  | jq '.symbols[] | select(.symbol == "--safe-mode") | {first_seen, removed_in, status}'

# Is CLAUDE_CODE_SAFE_MODE present in 2.1.169?  (exit code: 0 = yes, 1 = no)
curl -fsSL https://claustodian.dev/data/versions/2.1.169.json \
  | jq -e '.symbols[] | select(.symbol == "CLAUDE_CODE_SAFE_MODE")' > /dev/null \
  && echo "available" || echo "not available"

A symbol is available in version Y when first_seen <= Y and (removed_in is null or > Y).

Use it with an AI agent

Point your agent at llms.txt (served at https://claustodian.dev/llms.txt) or the agent guide in examples/ to teach it how to consume this data and make its features version-accurate. The examples/ directory has runnable, dependency-light clients you can copy — quickstart.sh (curl + jq), claustodian.ts (zero-dep TypeScript), and claustodian.py (stdlib-only Python).

Data layout

Stable, predictable URLs under data/:

Path	What
data/latest.json	Full symbol list as of the newest tracked version
data/versions/X.Y.Z.json	Full symbol list as of version X.Y.Z
data/index.json	All tracked versions + the latest
data/catalog.json	Every symbol ever seen, incl. removed ones
data/docs.json	Symbols harvested from the official docs pages
data/binary-descriptions.json	Per-symbol description timeline
data/schema-version.json	Version of this data format

Each file is also published as .yaml and .toml (generated in CI from the JSON; JSON is the source of truth) — except catalog.json, which is JSON-only because it is built after the export step runs. Each record follows schema/symbol.schema.json (JSON Schema draft 2020-12):

{
  "symbol": "--safe-mode",
  "type": "cli_flag",
  "first_seen": "2.1.169",
  "removed_in": null,
  "status": "active",
  "provenance": "changelog",
  "confidence": "high",
  "description": "Start with all customizations disabled to troubleshoot a broken configuration…",
  "description_source": "docs",
  "source_url": "https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md",
  "category": "cli"
}

Provenance & trust

first_seen is the earliest version Claustodian observed a symbol — not proof of the version it truly appeared in. Treat it as a lower bound. first_seen_estimated: true marks the ones that are an upper bound instead (an incidental changelog mention, or a docs page with no min-version); those carry confidence: medium until the binary lane pins them. control_message grades confidence differently — read first_seen_estimated for the date, not confidence.

The binary lane also creates upper bounds, not only resolves them: a control_message subtype can be invisible to extraction until its declaration becomes provable, so its first_seen is the version it became visible, not the version it appeared.

Every record carries a provenance:

• changelog — the official CHANGELOG.md. Authoritative for existence.
• docs — the official documentation pages (code.claude.com/docs). Supplies the authoritative description and, where a page states a min-version, an anchored first_seen.
• binary — published release binaries, by positive-evidence detection: CLI flags (commander registration or argv checks), env vars (the typed registry), built-in and skill/menu commands, settings.json keys read out of the embedded schema, stream-json control messages (AST of the control protocol), mods API methods (AST of the mods API dispatch table), mods events (AST of the mods event list), mods render sites (AST of the render-site enum and useRenderInput calls), and mods elements (AST of the per-app element lists). Binary flag, env-var, command and settings-key finds land as status: needs_review until a first-party description confirms them.

Coverage limitation — plugin commands. Commands supplied by the plugin/marketplace subsystem register outside the CLI binary, so the binary lane cannot date them at all. Their absence is not evidence they never existed. Skill-provided commands (/schedule, /loop) are captured.

Claustodian uses only material Anthropic has publicly published and distributed. It does not use leaked or otherwise non-public material. See CONTRIBUTING.

Status

Three lanes feed the dataset today:

• changelog lane — schema + validator, the changelog scraper, and Pages publishing.
• docs lane — official docs descriptions and anchored first_seen from min-version annotations.
• binary lane — undocumented-symbol coverage from release binaries (flags, env vars, built-in commands, settings.json keys read out of the embedded schema, stream-json control messages, mods API methods, mods events, mods render sites, and mods elements), plus first_seen corrections and conservative cliff-aware removal detection.

Roadmap / backlog

• Teach the extractor commander's built-in --help/--version. They are auto-registered rather than declared, so the extractor misses them and their first_seen comes from a late changelog/docs mention (2.1.200 / 2.1.205) instead of 0.2.x.
• Parse explicit changelog removal prose to propose removed_in on changelog- and docs-sourced symbols (today only the binary lane sets it) — surfaced for review, never auto-applied: a "Removed" bullet can retire a syntax form rather than the symbol (e.g. DEBUG=true was removed while DEBUG stays live).
• A site "what changed in vX" view — catalog.json already carries the full lifecycle.
• Release dates (released_on) from the docs changelog's <Update> annotations.

Development

npm ci
npm test          # unit tests
npm run validate  # validate all data/ files against the schema
npm run scrape -- --all   # (re)generate the full dataset from the changelog

• Architecture — the three lanes, the script map, and the invariants an extractor change has to hold.
• Regenerating the dataset — the lane order and why it is not the obvious one, plus the reconciliation that has to happen first.
• Publishing — how the site deploys, and the custom-domain trap.

License

Dual-licensed:

• Code (scripts, schema, config) — Apache-2.0 (see LICENSE). Requires preserving attribution/notices; includes a patent grant.
• Data (everything under data/) — CC-BY-4.0 (see LICENSE-DATA). Use it however you like, including commercially — just credit Claustodian, e.g. Data from Claustodian (https://github.com/schubydoo/claustodian), © 2026 Schuby, CC-BY-4.0.