{"version":"2.1.321","anchor":"managed-settings-read-failures-now-re-read-and-report-reason","canonical_anchor":"managed-settings-read-failures-now-re-read-and-report-reason","heading":"Managed settings that fail to load are read again, with a clearer message","tier":"notice","area":"Elsewhere","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.321\/e\/managed-settings-read-failures-now-re-read-and-report-reason","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.321","markdown":"### Managed settings that fail to load are read again, with a clearer message\n\nIf managed settings cannot be read, Claude Code tries again during the session and says plainly that the settings were not checked\n\n**Unclear.** It is not settled whether Claude Code holds back restricted actions or carries on when the managed settings still cannot be read.\n\n**What**\n\nManaged settings are rules an organisation's administrator sets on a machine through its device management or operating system. When Claude Code cannot read them, it now reads them again partway through the session instead of giving up after the first try.\n\nWhen the read still does not finish, Claude Code says so: \"The read did not finish, so the settings themselves were not checked.\" The same message now appears for the `allowedProviders` restriction, which limits which API providers a machine may use. Claude Code also records the reason the read failed.\n\n**Why**\n\nOn machines where policy reads are slow or unreliable, a second attempt makes it more likely the organisation's rules are actually picked up. The message also makes it clear when they were not checked.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: org\n- Heads-up: no"}