Sandbox Codexu pro Windows selhává na části strojů hned při spuštění příkazu

Agentní nástroj Codex pouští na Windows každý příkaz v sandboxu, tedy v ohraničeném prostoru, kde smí zapisovat jen do pracovní složky a ven nemá síť. U části uživatelů se ten prostor ale neotevře vůbec. Místo výstupu přijde jediný řádek: CreateProcessAsUserW failed: 5 (Access is denied.)

Není to čerstvá vada. Nejstarší otevřené hlášení, které tu hlášku uvádí, vzniklo 28. ledna 2026 u verze 0.92.0; poslední stabilní vydání má číslo 0.147.0. Vyhledávání v repozitáři projektu vrátilo 8. srpna 2026 celkem 45 otevřených hlášení, která tu chybu jmenují, a 19 uzavřených.

Příkaz skončí dřív, než se stihne spustit

Pětka je ve Windows odepřený přístup a CreateProcessAsUserW je systémové volání, kterým se zakládá proces pod cizím přístupovým tokenem. Dokumentace Microsoftu u něj uvádí, že volající proces obvykle potřebuje oprávnění SE_INCREASE_QUOTA_NAME a u tokenu, který nejde přiřadit, i SE_ASSIGNPRIMARYTOKEN_NAME. Sandbox tímhle voláním spouští každý příkaz, takže když selže, neproběhne z příkazu nic; agent dostane místo výstupu chybu.

Měření ukazuje na PowerShell z obchodu Microsoftu

Nejpodrobnější rozbor je v hlášení z 29. července. Jeho autor pustil na jednom stroji dvacet pokusů pro každý shell a počítal výskyty té hlášky, ne návratový kód. PowerShell 7 z Microsoft Storu, tedy balíčkovaný ve formátu MSIX, selhal dvacetkrát z dvaceti. Windows PowerShell 5.1 ze složky System32, cmd.exe i Git Bash neselhaly ani jednou. Když z proměnné PATH zmizely položky WindowsApps, sáhl Codex po PowerShellu 5.1 a příkaz proběhl.

Sedí to s výpisy dalších hlásících: u spouštěného příkazu v nich stojí cesta do složky AppData\Local\Microsoft\WindowsApps, tedy zástupce balíčkované aplikace, ne její vlastní soubor. Jeden z přispěvatelů si prošel hlavní větev projektu a napsal, že výběr shellu přijme nález příkazu pwsh dřív, než dojde na nebalíčkované záložní cesty. Nikdo z projektu se pod hlášením nevyjádřil; jediná reakce z té strany je automatické upozornění na možnou duplicitu.

Hlášení se rozcházejí v tom, který režim vadu spouští

Nápověda popisuje dva režimy. Silnější elevated zakládá vlastní uživatele s nižšími právy, hranice v souborovém systému a pravidla brány firewall. Slabší unelevated pouští příkazy pod omezeným tokenem odvozeným z účtu, pod kterým člověk pracuje, a odpojení od sítě řeší přes prostředí místo firewallového pravidla.

Autor měření tvrdí, že k selhání je potřeba obojí naráz, tedy režim elevated a balíčkovaný cíl: v režimu unelevated mu z dvaceti pokusů neselhal ani jeden. O den později ale jiný uživatel popsal, že mu příkazy Get-Location a git --version padají v obou režimech stejně. Z veřejných hlášení se nedá rozhodnout, které z obou pozorování platí obecně.

Ústup na slabší režim něco stojí

Přepnutí do unelevated doporučuje i nápověda, a to jako dočasnou náhradu, dokud se potíž vyšetřuje. Autor měření k němu připsal dvě věci, které v nápovědě nestojí. PowerShell v tom režimu spadne do omezeného jazykového režimu ConstrainedLanguage, takže volání metod .NET ani Add-Type uvnitř agentních skriptů neprojdou. A chybí vrstva pro běh jen se čtením: samotný program podle jeho zápisu hlásí, že omezený přístup jen ke čtení vyžaduje elevated.

Co v nápovědě a v poznámkách k vydání není

Oddíl nápovědy o řešení potíží popisuje, co dělat, když příprava režimu elevated neprojde, co znamená přepnutí do unelevated a co dělat u chyby 1385, kdy Windows odpírá typ přihlášení, který uživatel sandboxu potřebuje. Chyba 5 v tom oddílu není. Objeví se jen nepřímo v seznamu údajů, které má člověk poslat s hlášením: má uvést, jestli viděl 1385, nebo jinou chybu Windows či PowerShellu.

Poznámky k vydání 0.147.0 ze 7. srpna 2026 mají mezi opravami jednu položku o Windows a ta se týká přerušování procesů na pozadí a jednotného zacházení s cestami. Spouštění příkazů v sandboxu mezi nimi není. Táž verze přitom zpřísnila zacházení s tajnými údaji v zobrazených příkazech.

Co s tím dnes jde dělat

Podle měření v hlášeních zabraly tři kroky: odebrat z proměnné PATH složku WindowsApps, spustit příkaz výslovně přes powershell.exe ze System32, nebo přepnout na unelevated a smířit se s jeho omezeními. Vyzkoušené to tu není, jde o postupy z cizích zápisů. Žádný z nich navíc není oprava: všechny jen obcházejí to, jak si nástroj vybírá shell.