{"version":"2.1.300","anchor":"signed-cache-verification-now-returns-a-structured-trust-res","canonical_anchor":"signed-cache-verification-now-returns-a-structured-trust-res","heading":"Signed settings check now reports why it did not trust a cache","tier":"internal","area":"Managed Settings","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300\/e\/signed-cache-verification-now-returns-a-structured-trust-res","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300","markdown":"### Signed settings check now reports why it did not trust a cache\n\nThe check on signed cached settings now returns whether they are trusted and a reason, such as an unknown organization pin\n\n**Unclear.** What this changes for someone whose settings are managed by an organization is not shown.\n\n**What**\n\nSome settings can be signed and tied (pinned) to an organization so they can be checked before use. When Claude Code checks a stored copy of such settings, it now also considers a list of pinned organizations, and returns a result saying whether the copy is trusted and, if not, why. When the organization pin cannot be read, the result is untrusted with the reason `org_pin_unknown`. Before, the check returned only a short status word.\n\n**Why**\n\nThis touches how Claude Code decides whether to trust managed or signed settings.\n\n- Area: Managed Settings\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 3\/5\n- Scope: org\n- Heads-up: no"}