{"version":"2.1.281","anchor":"memory-sync-org-policy-now-decides-the-sync-state-instead-o","canonical_anchor":"memory-sync-org-policy-now-decides-the-sync-state-instead-o","heading":"Memory sync: org policy now decides the sync state instead of turning off memory sync outright","tier":"notice","area":"Memory","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/memory-sync-org-policy-now-decides-the-sync-state-instead-o","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Memory sync: org policy now decides the sync state instead of turning off memory sync outright\n\nWhen an organization disallows memory sync, it now counts as configured but \"closed\" instead of switched off entirely\n\n**Unclear.** The finding does not say what a user sees differently when memory sync is blocked by the organization.\n\n**What**\n\nMemory sync has three states: \"open\", \"held\" and \"closed\". Your organization can allow or disallow it through a managed setting called `allow_memory_sync`.\n\nBefore, when the organization disallowed it, memory sync was treated as not set up at all. Now it still counts as set up, and its state is \"closed\".\n\n**Why**\n\nThis lets Claude Code tell apart \"memory sync is not set up\" from \"memory sync is set up but your organization has blocked it\", which parts of Claude Code that check for the closed state can now act on.\n\n- Area: Memory\n- Names: `allow_memory_sync`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}