Claude Code na Windows ve výchozím stavu používá Bash. Přesněji Git Bash – unixovou vrstvu, která přišla s instalací Gitu. To znamená, že když Claude potřebuje spustit příkaz, sáhne po grep, find a /dev/null místo Select-String, Get-ChildItem a $null. Funguje to. Ale na Windows to znamená, že celá nativní vrstva systému zůstává skrytá.

Anthropic ale vyvinul plnohodnotný PowerShellTool – 144 KB kódu, vlastní AST parser a bezpečnostní engine. Je připravený k použití. Stačí nastavit jednu proměnnou prostředí.

Jak PowerShellTool aktivovat

Jediná změna:

CLAUDE_CODE_USE_POWERSHELL_TOOL=1

Nastavte jako systémovou proměnnou prostředí, nebo do .env souboru v projektu. Po restartu Claude Code se v seznamu nástrojů objeví PowerShell vedle existujícího Bash.

Pro zaměstnance Anthropicu je PowerShellTool zapnutý ve výchozím stavu (s možností ho vypnout). Pro veřejné uživatele je to opt-in. Důvod: nástroj je rozsáhlý a Anthropic ho stále aktivně testuje v interním prostředí.

Co získáte – konkrétní scénáře

Registry Windows

S BashTool (výchozí): Claude nemá přímý přístup k registrům Windows. Může spustit reg query přes Git Bash, ale výstup je nestrukturovaný text.

S PowerShellTool: Claude může přímo pracovat s registry přes PSDrive syntaxi:

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion

Prompt PowerShellTool explicitně učí model správnou syntaxi: „Registry access uses PSDrive prefixes: HKLM:\SOFTWARE\..., HKCU:\... – NOT raw HKEY_LOCAL_MACHINE\....“

Služby a procesy

BashTool: tasklist a sc query vracejí tabulkový text, který se špatně parsuje.

PowerShellTool: Nativní PowerShell cmdlety vracejí objekty:

Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object Name, Status
Get-Process | Sort-Object -Property CPU -Descending | Select-Object -First 10

Claude v PowerShell módu ví, že | v PowerShellu předává objekty, ne text. To mu umožňuje řetězit cmdlety bez obav z parsování mezer a tabulátorů.

Oprávnění souborů

BashTool: ls -la přes Git Bash zobrazí unixová oprávnění – ale na NTFS jsou to syntetické hodnoty bez reálného významu.

PowerShellTool: Přístup k ACL (Access Control Lists):

Get-Acl .\sensitive-file.txt | Format-List

Get-Acl je v kódu explicitně zařazen mezi bezpečné read-only příkazy, takže nevyžaduje potvrzení uživatele.

.NET integrace

PowerShellTool umožňuje přímý přístup k .NET frameworku:

[System.IO.Path]::GetTempPath()
[System.Environment]::OSVersion

To otevírá celou škálu scénářů – od práce s kryptografickými API po manipulaci s certifikáty a systémovými událostmi.

Environment variables

BashTool: echo $PATH funguje v Git Bashi, ale echo $env:PATH ne (to je PowerShell syntaxe).

PowerShellTool: Nativní přístup k proměnným prostředí s plnou PowerShell syntaxí:

$env:PATH
$env:USERPROFILE
[System.Environment]::GetEnvironmentVariable('PATH', 'Machine')

Prompt PowerShellTool explicitně učí: „Environment variables: read with $env:NAME, set with $env:NAME = 'value' – NOT Set-Variable or bash export.“

Bezpečnostní model – proč to trvalo tak dlouho

PowerShellTool nebyl vydán dříve, protože bezpečnostní model PowerShellu je fundamentálně odlišný od bashe.

Vlastní AST parser

Bash příkazy se dají rozumně analyzovat regulárními výrazy. PowerShell ne. Příkaz obsahující script block ({ ... }) může v sobě skrývat libovolný kód. Proto Anthropic napsal parser, který volá nativní .NET [Parser]::ParseInput() – stejný parser, který používá PowerShell samotný.

Parser funguje tak, že příkaz zakóduje do Base64 (prevence injekce), spustí PowerShell proces s parsovacím skriptem a výstupní AST analyzuje v TypeScriptu. Výsledek obsahuje typ každého prvku, bezpečnostní příznaky (subvýrazy, script bloky, member invokace) a přesný rozklad pipeline.

Alias hijacking

PowerShell umožňuje přesměrování příkazů přes aliasy. Příkaz Set-Alias rm Invoke-Expression by způsobil, že každé volání rm spustí místo mazání libovolný kód. Proto PowerShellTool blokuje Set-Alias, New-Alias i zkrácené varianty (sal, nal) a explicitně je označuje jako nebezpečné.

Stejný problém platí pro Set-Variable – nastavení $PSDefaultParameterValues může změnit chování všech cmdletů.

WMI process spawn

Bezpečnostní nález #34 v kódu: Invoke-WmiMethod -Class Win32_Process -Name Create je ekvivalent Start-Process, který obchází standardní bezpečnostní kontroly. PowerShellTool ho proto blokuje samostatně.

Symlink guard

Bezpečnostní nález #18: příkaz New-Item -ItemType SymbolicLink -Path ./link -Value /etc; Get-Content ./link/passwd vytvoří symbolický odkaz a pak přes něj přečte systémový soubor. PowerShellTool detekuje vytváření symbolických odkazů, junction pointů a hard linků v kombinaci s dalšími příkazy a odmítne je automaticky schválit.

PowerShell 5.1 vs 7+ – automatická detekce

PowerShellTool automaticky detekuje verzi PowerShellu a přizpůsobí prompt:

Detekce probíhá bez spuštění procesu – z názvu binárního souboru (pwsh = 7+, powershell = 5.1). Pokud verze není známa, nástroj přepne do konzervativního režimu a zakáže veškerou syntaxi PowerShell 7+.

To je důležitý detail. Claude bez této detekce může vygenerovat && na systému s PowerShell 5.1, kde je to parser error. S detekcí ví, že musí použít A; if ($?) { B }.

Interaktivní příkazy – tvrdý blok

Prompt PowerShellTool obsahuje seznam příkazů, které jsou striktně zakázané, protože by zablokovali terminál. Nástroj běží v neinteraktivním režimu (-NonInteractive):

• Read-Host (čtení uživatelského vstupu)
• Get-Credential (dialog pro heslo)
• Out-GridView (GUI okno)
• $Host.UI.PromptForChoice (výběrový dialog)
• pause (čeká na stisk klávesy)

Destruktivní cmdlety (Remove-Item, Stop-Process) mohou vyžadovat potvrzení. Proto prompt instruuje Claude, aby přidával -Confirm:$false pro záměrné akce a -Force pro skryté/read-only položky.

Here-stringy – nevinná past

PowerShell here-stringy (@'...'@) mají pravidlo, které pravidelně mate i zkušené vývojáře: uzavírací '@ musí být na začátku řádku, bez jakéhokoli odsazení.

# Chybně - odsazení způsobí parser error:
git commit -m @'
  Zpráva commitu
  '@

# Správně - uzavření na sloupci 0:
git commit -m @'
  Zpráva commitu
'@

PowerShellTool prompt na to Claude explicitně upozorňuje a obsahuje příklad. Bez toho by AI model přirozeně odsadil kód a příkaz by selhal s nesrozumitelnou chybou.

Reálné limity

PowerShellTool má omezení, která je důležité znát:

Sandbox na Windows nefunguje. Sandbox (bwrap/sandbox-exec) je dostupný pouze na Linux/macOS. Na Windows nativním nemá PowerShellTool sandboxing. Pokud má organizace politiku vyžadující sandbox, PowerShellTool odmítne spuštění s konkrétní chybou: „Enterprise policy requires sandboxing, but sandboxing is not available on native Windows.“

Limit délky příkazu. Na Windows je maximální délka příkazového řádku 32 767 znaků. Po zakódování příkazu přes dva stupně Base64 zbývá prostor přibližně pro 1 092 UTF-8 bytů. Dlouhé PowerShell skripty mohou narazit na tento limit.

Dva shell nástroje pracují nezávisle. BashTool a PowerShellTool nekoordinují svůj stav. Pracovní adresář se sdílí, ale proměnné prostředí nastavené v jednom shellu se nepřenáší do druhého.

Komu se to vyplatí

PowerShellTool má smysl aktivovat, pokud:

• Pracujete s Windows specifickými technologiemi (IIS, Active Directory, Windows Services)
• Potřebujete přístup k registrům Windows
• Používáte .NET framework z příkazového řádku
• Pracujete s WMI/CIM pro správu systému
• Chcete přirozenější interakci s nativními Windows nástroji

Pokud primárně píšete webové aplikace, používáte Node.js/Python a občas spustíte git – BashTool stačí. Git Bash pokrývá většinu vývojářských scénářů i na Windows.

Ale pokud vás někdy frustrovalo, že Claude na Windows říká /dev/null místo NUL a generuje unixové příkazy na vašem Windows stroji – řešení existuje. Je to jedna proměnná prostředí a 400 KB pečlivě napsaného bezpečnostního kódu.