Claustodian

A static, versioned, machine-parseable record of every Claude Code CLI flag, environment variable, command, config key, and stream-json control message — 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, and stream-json control messages (AST of the control protocol). 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, and stream-json control messages), 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.