claude-code - 💡(How to fix) Fix [DOCS] Settings docs missing `wslInheritsWindowsSettings` policy for WSL [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52193Fetched 2026-04-23 07:34:07
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
labeled ×3
RAW_BUFFERClick to expand / collapse

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://code.claude.com/docs/en/settings

Section/Topic

Managed settings configuration scopes and WSL policy behavior

Current Documentation

The docs currently say:

MDM/OS-level policies: delivered through native device management on macOS and Windows:

  • macOS: com.anthropic.claudecode managed preferences domain (deployed via configuration profiles in Jamf, Iru (Kandji), or other MDM tools)
  • Windows: HKLM\SOFTWARE\Policies\ClaudeCode registry key with a Settings value (REG_SZ or REG_EXPAND_SZ) containing JSON (deployed via Group Policy or Intune)
  • Windows (user-level): HKCU\SOFTWARE\Policies\ClaudeCode (lowest policy priority, only used when no admin-level source exists)

File-based: managed-settings.json and managed-mcp.json deployed to system directories:

  • macOS: /Library/Application Support/ClaudeCode/
  • Linux and WSL: /etc/claude-code/
  • Windows: C:\Program Files\ClaudeCode\

And the server-managed settings page says:

Claude Code supports two approaches for centralized configuration. Server-managed settings deliver configuration from Anthropic's servers. Endpoint-managed settings are deployed directly to devices through native OS policies (macOS managed preferences, Windows registry) or managed settings files.

No documentation currently exists for wslInheritsWindowsSettings or for WSL inheriting Windows-side managed settings.

What's Wrong or Missing?

Changelog v2.1.118 added: "WSL on Windows can now inherit Windows-side managed settings via the wslInheritsWindowsSettings policy key".

The current docs explain Windows-managed settings and WSL/Linux-managed settings as separate delivery paths, but they do not document that WSL can inherit Windows-side managed settings or how administrators should use the wslInheritsWindowsSettings key.

That leaves a gap for enterprise deployments that manage Claude Code through Windows policy but run the CLI inside WSL.

Suggested Improvement

Add a short subsection to the managed settings documentation that:

  • Introduces wslInheritsWindowsSettings as a managed policy key
  • Explains that WSL sessions on Windows can inherit Windows-side managed settings when this key is enabled
  • Clarifies how this interacts with the existing WSL/Linux path at /etc/claude-code/ and Windows registry/file-based policy sources
  • Includes one concrete admin example showing where to set the key in Windows-managed policy JSON

The same change should also be cross-referenced from the managed settings section in the permissions docs.

Impact

Medium - Makes feature difficult to understand

Additional Context

Affected Pages:

PageContext
https://code.claude.com/docs/en/settingsPrimary managed settings documentation, including Windows registry and Linux/WSL file-based locations
https://code.claude.com/docs/en/permissionsManaged settings overview and managed-only settings table
https://code.claude.com/docs/en/server-managed-settingsCross-reference page that distinguishes server-managed vs endpoint-managed settings

Total scope: 3 pages affected

Source: Changelog v2.1.118

Exact changelog entry: WSL on Windows can now inherit Windows-side managed settings via the wslInheritsWindowsSettings policy key

extent analysis

TL;DR

Add documentation for the wslInheritsWindowsSettings policy key to explain how WSL sessions on Windows can inherit Windows-side managed settings.

Guidance

  • Introduce the wslInheritsWindowsSettings policy key in the managed settings documentation and explain its purpose.
  • Provide an example of how to set the key in Windows-managed policy JSON for administrators.
  • Clarify how the wslInheritsWindowsSettings key interacts with existing WSL/Linux and Windows registry/file-based policy sources.
  • Cross-reference the new documentation from the managed settings section in the permissions docs.

Example

No code snippet is provided as the issue is related to documentation, not code.

Notes

The documentation update should cover the interaction between the wslInheritsWindowsSettings key and the existing policy sources to avoid confusion for administrators.

Recommendation

Apply workaround: Update the documentation to include the missing information about the wslInheritsWindowsSettings policy key, as this will provide clarity for administrators and resolve the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [DOCS] Settings docs missing `wslInheritsWindowsSettings` policy for WSL [1 participants]