{"version":"2.1.282","anchor":"wsl-managed-settings-a-windows-side-policy-file-that-fails","canonical_anchor":"wsl-managed-settings-a-windows-side-policy-file-that-fails","heading":"WSL no longer ignores a Windows policy file that fails to load","tier":"notice","area":"Elsewhere","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/wsl-managed-settings-a-windows-side-policy-file-that-fails","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### WSL no longer ignores a Windows policy file that fails to load\n\nOn WSL, a Windows-side managed policy that is broken or unreadable now wins instead of falling back to the Linux managed-settings.json\n\n**Unclear.** It is not clear exactly which policy source outranks the Linux file when inheritance is off.\n\n**What**\n\nWSL (Windows Subsystem for Linux) lets you run Linux on a Windows machine. Managed settings are policy settings an organisation's administrator sets, which users cannot override. On WSL, Claude Code can take these from the Windows side as well as from the Linux file `managed-settings.json`.\n\nClaude Code now tracks whether each policy source loaded, was absent, or failed to load.\n\n- **With Windows policy inheritance on:** a Windows-side policy source you cannot edit now takes charge if it holds policy or failed to load. Before, when it gave no usable settings, Claude Code quietly used the Linux `managed-settings.json` instead.\n\n- **With inheritance off:** when a higher-priority policy source is present, the Linux `managed-settings.json` is now treated as absent.\n\n**Why**\n\nBefore, someone could escape an organisation's policy on WSL by breaking or blocking the Windows-side file. A policy that fails to load now stays in charge.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5"}