Part 9 of 16
Crux Daemon internals
How the daemon is built and run: planes, crates, startup and its refusal conditions, the full configuration surface, the memory substrate, receipts and what they do not prove.
- Internals and operationWhat the Crux Daemon is, the mental model behind one process with three network planes, and a router from who you are to the chapter you need.
- ArchitectureOne process with three network planes, the fail-closed bind rails that stop you exposing it by accident, the 28-crate map, and the exact path a request takes from socket to store.
- The config wizardRun one command and your workspace's CLAUDE.md and AGENTS.md are composed from thirteen versioned, source-controlled rule fragments: with drift detection, a CI check, and a refusal to silently overwri
- The crate mapAll 28 workspace crates plus the three out-of-workspace shell crates: purpose, size, shape, public surface and dependents, including the orphan crate and the router that never checks revocation.
- Startup and lifecycleThe 67-step boot sequence in order, the complete list of 25 conditions that make the daemon refuse to start with the exact fix for each, the 14 background tasks, and the shutdown path.
- Configuration referenceAll 393 environment variables and 26 YAML keys, with type, default, effect and reading code path: plus the nine incompatible boolean rules, the silent config-file failures, and the relative default da
- The data directoryThe on-disk layout directory by directory and file by file, the code that writes each one, what breaks if you delete it, which locks guard what, and what grows without bound.
- Auth and scopesEvery CORECRUXD_AUTH_MODE value, the complete scope list, how scopes are checked at two independent layers, the token formats accepted, and the route-auth middleware that logs violations rather than b
- ErrorsThe RFC 9457 problem body every failure returns, the roughly 40 real HTTP error codes grouped by subsystem, and a plain statement that the repository's error catalogue documents a different taxonomy.
- ObservabilityLogging and its precedence traps, the complete 142-metric inventory, tracing, and the nine readiness gates: including the data-dir capacity gate that takes a healthy daemon out of rotation when the di
- The memory substrateReference for the fact store: the JSONL journal, the entity/key/value record, private scoping, bi-temporal as_of, freshness decay, contradiction detection and consolidation, with every durability limi
- Retrieval and budgetsReference for how a query is answered: query_facts is a substring OR-match, BM25 lives only on the segment lane, fusion and graph expansion are unwired, the default embedder is feature hashing, and ho
- Sessions, cases, handoffsReference for the three stores that carry agent working state: session JSON with no fsync and no size limit, cases retrieved by lexical Jaccard, and handoff packages authenticated by a symmetric BLAKE
- Receipts and proofReference for CROWN receipts: BLAKE3 hashing, Ed25519 signing, verify_strict, the offline verifiers and the tamper test, and the exact boundary of what a receipt does and does not prove.
- Identity and capabilityReference for passports, revocation and RCX capability tokens: what a passport is (a record, not a credential), why the shipped example config bypasses scope checks, and the one control in this set th
- Coordination and costReference for the coordination plane (advisory, with client-side edit enforcement), the cost lens (tokens, never currency), .cruxpack export and its stubbed sections, and the config audit: which is ad
- Known defectsA standing, dated disclosure of eight verified blocker-severity defects in the daemon and its shipped deployment artefacts, each with its evidence, its consequence and its operator workaround.
- OperationsRunning the daemon in production: the three shipped deployment artefacts and their differences, health and readiness, what to back up, how to upgrade, and how to diagnose the failures you will actuall
- Runtime code intelligenceWhat the daemon knows about your code and what it did when it ran, how the two are joined, which tenant an answer came from, and the two limits that bound retained runtime history.