v1.6.1 (2026-07-01)

Patch release: the install path works again, and the first-run experience tells the truth. No new capability, no breaking changes, no config migration.

Why this release exists

npx @sanctuary-framework/mcp-server had been broken since v1.4.0 with “could not determine executable to run”: the package declared no bin matching its unscoped name, which is what npm’s scoped-package basename resolution needs. Worse, the wrap flow wrote that same broken, unpinned form into harness MCP configs, leaving a dead MCP entry at the next harness restart and drifting to whatever latest becomes.

What changed

• Install (#846): the bare npx form resolves again (mcp-server bin added); sanctuary protect/wrap now writes a version-pinned entry (npx -y -p @sanctuary-framework/mcp-server@<version> sanctuary) into harness configs; the update notice suggests the exact announced version instead of @latest; a new CI workflow packs the real publish tarball every run and proves both invocation forms plus every declared bin resolve.
• First-run honesty (#843): the “protected” banner is now evidence-gated on a real, fresh Castle Wall enforcement verdict (dashboard standard, fail-closed on probe error); MCP stdio stdout stays JSON-pure; the wrap metadata behind --unwrap is written only after every wrapped surface verifies, with full rollback on failure and loud explicit guidance in the residual corner cases, so a failed or interrupted wrap can no longer cost you your pristine pre-wrap config silently.

Install

npx @sanctuary-framework/mcp-server

or explicitly pinned:

npx -y -p @sanctuary-framework/mcp-server@1.6.1 sanctuary

Capability bounds (unchanged)

The macOS Castle Wall bounds are unchanged from v1.6.0: per-uid allow/deny plus attended reboot-survival are proven; there is no per-flow rule-attributed audit trail.