[DOCS] Windows: document that PowerShell-tool grandchildren inherit pwsh 7's PSModulePath and break Windows PowerShell 5.1 module loading

Preflight

• [x] I have searched existing issues.
• [x] This is a single request (documentation).
• [x] Version: 2.1.221 (latest at time of filing: 2.1.223). This is a documentation request, not version-specific.

What's missing

On Windows, the PowerShell tool runs commands under pwsh 7. Any process started from that tool inherits pwsh's PSModulePath — including a powershell.exe (Windows PowerShell 5.1) launched indirectly, for example through a Python test harness that Claude wrote.

pwsh sanitizes PSModulePath for Windows PowerShell processes it launches directly, but that sanitization does not survive an intermediate process. A 5.1 grandchild therefore inherits the PowerShell 7 module directory ahead of its own system module directory, resolves shared module names (Microsoft.PowerShell.Utility, Microsoft.PowerShell.Management, …) to the 7.0.0.0 builds, and fails module auto-loading. Get-FileHash and every cmdlet from those modules then raise CommandNotFoundException.

Measured on this machine (pwsh 7.6.4, Windows PowerShell 5.1.26100.8972, Windows 11 10.0.26200):

pwsh -> powershell.exe 5.1  (direct)      PSModulePath entries: 4   Get-FileHash OK
pwsh -> python -> powershell.exe 5.1      PSModulePath entries: 6   CommandNotFoundException
PSModulePath stripped from child env      PSModulePath entries: 4   Get-FileHash OK

Root cause and full reproduction: PowerShell/PowerShell#27774. The defect itself belongs to PowerShell, not to Claude Code — I am not asking for a code change here.

Why it is worth a line in the docs

Claude routinely writes Python harnesses that shell out to powershell.exe. When this fires, every case in the suite fails identically with a non-zero exit code that looks like a defect in the harness or in the script under test. The natural first check — running powershell.exe directly — shows nothing wrong, because the direct path is sanitized. In my case a 38-case suite failed uniformly and the cause took several iterations to find; the agent had no way to know the environment was the culprit.

Request

Add a short note to the PowerShell tool description (and/or the Windows page of the docs), along the lines of:

The PowerShell tool runs under pwsh 7. Processes started indirectly from it — for example a powershell.exe 5.1 process launched by a Python script — inherit pwsh's PSModulePath, which shadows Windows PowerShell's own modules and breaks cmdlet auto-loading (Get-FileHash → CommandNotFoundException). When a harness must launch Windows PowerShell 5.1, strip PSModulePath from the subprocess environment: ``python env = {k: v for k, v in os.environ.items() if k.upper() != "PSMODULEPATH"} ``

The tool description already carries Windows-specific guidance (/dev/null vs NUL, PowerShell here-strings, $env:VAR vs %VAR%), so this fits the existing pattern.