v1.8.6-rc.5 (2026-09-14)

This opt-in release candidate is published on npm’s next channel. The stable latest channel remains v1.8.4. RC5 adds first-install reliability fixes; it does not widen Sanctuary’s capability claims.

npm install -g @sanctuary-framework/mcp-server@1.8.6-rc.5

The public prerelease is v1.8.6-rc.5, built from source commit bced40d3934073ae8a4405a38a82aa44de70e739. The signed and notarized Sanctuary-CastleWall.app.zip has SHA-256 bd19890ad40d8c15b0c44201d537d6d7c9d6c82437db6a4611f8d841837409aa.

v1.8.5 was tagged and built but never published. Its fresh acceptance run exercised the exact next step that sanctuary install prints for a new fortress, with no passphrase supplied, and found that the dashboard boot did not use the custody factor init had enrolled. RC5 carries every v1.8.5 change and the corrections found by subsequent acceptance and independent review.

What changed

Fixed

• The dashboard opens a fortress with the enrolled keyring factor. The MCP server boot and the dashboard boot resolve their credential through one shared path (explicit passphrase, environment passphrase, environment recovery key, then the enrolled keyring factor and the stored passphrase, each checked against the fortress); a boot never mints a credential, and a refusal names exactly the accepted sources.
• A fortress created before custody envelopes still opens with its stored passphrase when a keyring custody item exists that no envelope can verify; the item is reported as present but unverifiable rather than used. The keyring factor a boot receives is cleared from memory across its whole lifetime, including a failed read between resolution and establishment.
• Default init no longer touches the machine-wide Castle Wall trust anchor. It provisions only the fortress-local vault; the machine-wide anchor is published or migrated only through an explicit, confirmed castle-wall re-pin. Every surface that reports wall state (doctor, status, the dashboard, the MCP health and attestation tools) renders whether a vault has completed that step, and treats an unreadable record as not walled rather than as protected; a record that is absent carries no claim.
• A confirmed re-pin uses the custody credential enrolled for that exact fortress. It refuses when no usable custody credential exists, clears resolved key material after use, and reports failure if its required audit record cannot be persisted.
• A dashboard launch session now follows the dashboard’s read traffic. Same-origin reads and event streams retain the session that authenticated the initial page, while mutations and cross-origin destinations remain unchanged.
• The macOS installer now uses the verified signed app’s bundled CLI for memory and full profiles. A first install advances with the exact candidate already in the app rather than requiring a separately installed global package, and an inconsistent app runtime is refused.
• Memory and Rung 1 installation now require a usable Tier-1 approval channel before reporting completion. Dashboard approval requires an explicit strong operator bearer, while auto remains read-only. Unreadable configuration, or configuration replaced while being read, is refused.

Carried from v1.8.5 (unpublished)

See docs/releases/v1.8.5.md: the shared credential resolver for protect, export-passphrase, the install planner and the server boot; the recovery key staged beside the fortress; the default principal policy; explicit pin adoption or refusal; honest failure cleanup. The capability bounds in the v1.8.4 notes are unchanged.