技術資料

Windows版Codexでファイルの内容を確認しようとしたところ、最初のコマンド実行でエラーになることがあります。

今回の環境では、Get-ContentやGet-ChildItemのような読み取り専用コマンドでも、次のエラーが発生しました。

windows sandbox: CreateProcessAsUserW failed: 5 (アクセスが拒否されました。)

このような場合、対象ファイルやプロジェクトの権限を変更する前に、Codexが起動しようとしているPowerShellの実体と解決先を確認すると、原因を切り分けやすくなります。

今回の環境と症状

今回確認した環境は以下の通りです。

• Windows 11
• PowerShell 7.6.4
• Windows版Codex

通常のPowerShellでは同じコマンドを実行できますが、Codexから実行すると最初の読み取りコマンドで失敗しました。エラーの中には、次のようなcmd=の記述がありました。

cmd=C:\Users\<ユーザー名>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

コマンド実行前のエラーかを確認する

CreateProcessAsUserWは、指定したユーザーとしてプロセスを作成するためのWindows APIです。エラー名にこの関数が含まれている場合、PowerShellがコマンドを実行した後ではなく、PowerShellのプロセスを起動する段階で失敗している可能性があります。

MicrosoftのCreateProcessAsUserWの公式ドキュメントでも、この関数は新しいプロセスを作成するためのAPIとして説明されています。

そのため、Get-Contentの書き方や読み取り対象のMarkdownが原因だと決めつける前に、エラー内のcmd=がどのpwsh.exeを指しているかを確認します。

pwshの解決先を確認する

まず、通常のPowerShellまたはWindows Terminalで、pwshの解決先を確認します。

where.exe pwsh

Get-Command pwsh -All |
    Select-Object CommandType, Source

今回の環境では、where.exe pwshの結果は次のようになりました。

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe
C:\Users\<ユーザー名>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

また、Get-Commandでは、次の2つが見つかりました。

CommandType  Source
-----------  ------
Application  C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe
Application  C:\Users\<ユーザー名>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

C:\Users\...\Microsoft\WindowsApps\pwsh.exeはアプリ実行エイリアスです。実際のPowerShell本体がWindowsApps配下にある構成では、通常のターミナルからは起動できても、Codexの制限された実行コンテキストからは起動できない場合があります。

MSIX版PowerShellの導入状況を確認する

必要であれば、PowerShellがMSIXパッケージとして導入されているかも確認します。

Get-AppxPackage -Name Microsoft.PowerShell -AllUsers |
    Select-Object Name, PackageFullName, InstallLocation

ただし、MSIX版を使っていることだけで、必ずCodexのエラーが発生するわけではありません。Codexのバージョン、Windowsのsandbox実装、PATH、セキュリティ設定なども影響する可能性があります。

MSI版PowerShellを導入する

今回の環境では、MSI版PowerShellを導入した後、MSIX版PowerShellをアンインストールしたところ、Codexから最初の読み取りコマンドを実行できるようになりました。PowerShellの導入方法を変更する場合は、まず現在の環境を確認してから行います。

MicrosoftのPowerShell 7のWindowsへのインストール方法では、WinGet、MSI、ZIPなど複数の導入方法が案内されています。WinGetのパッケージ形式や利用できるバージョンは変わる可能性があるため、最初に検索します。

winget search --id Microsoft.PowerShell --exact

MSI版を明示して導入する場合は、次のコマンド。

winget install --id Microsoft.PowerShell --source winget --installer-type wix

同じパッケージがすでに導入済みと判断される場合は、Microsoft公式のPowerShellリリースページから、対象バージョンのx64 MSIをダウンロードしてインストールします。インストール先は、通常は次のような場所になります。

C:\Program Files\PowerShell\7\pwsh.exe

導入後は、実体を直接起動して確認します。

$pwsh = 'C:\Program Files\PowerShell\7\pwsh.exe'

Test-Path $pwsh

& $pwsh -NoProfile -Command '$PSVersionTable.PSVersion'

Test-PathがTrueになり、PowerShellのバージョンが表示されれば、実体の起動確認は完了です。

MSIX版を削除した後の解決確認

今回の環境では、MSIX版PowerShellをアンインストールしました。PATHの変更やWindowsの再起動は行わず、そのままCodexから最初の読み取りコマンドを実行したところ、エラーは発生しませんでした。

PowerShellの解決先が意図したものになっているか、改めて確認します。

where.exe pwsh

Get-Command pwsh -All |
    Select-Object CommandType, Source

MSI版を使う構成では、C:\Program Files\PowerShell\7\pwsh.exeが解決先として表示されることを確認します。複数のPowerShellを残している場合は、先頭に表示される実体がCodexから起動できるものかを確認してください。

続けて、Codexから読み取り専用のコマンドを実行します。

Get-Location
Get-ChildItem -Force
Get-Content -Raw -LiteralPath '.\既存のテキストファイル.md'

最後のコマンドは、実際に存在するテキストファイルへ置き換えてください。ファイルの内容を変更せずに、Codexがコマンドを実行できるかだけを確認します。

やらない方がよい対処

プロセス起動時のエラーに対して、プロジェクト全体のアクセス権を変更するのは適切な対処とは限りません。次のような操作は、原因を確認してから検討します。

• プロジェクトやドライブに、Everyone: FullControlのような広い権限を付与する
• C:\Program Files\WindowsApps配下のファイルを手動で削除する
• Codexのsandboxを恒久的に弱める
• エラーの原因を確認せず、PowerShellやCodexを削除・再インストールする

WindowsAppsはWindowsのパッケージ管理下にあるため、不要なパッケージを削除する場合も、Windowsのアプリ管理や正式なアンインストール手段を使います。

MSIX版だけを原因と決めつけない

今回の環境ではMSIX版PowerShellのアンインストールで改善しましたが、同じエラーが出た環境で同じ結果になるとは限りません。

実際に、CodexのGitHubリポジトリには、Windows版でCreateProcessAsUserW failed: 5が発生した事例が複数報告されています。たとえば、PowerShellの実体とsandboxの組み合わせに関するIssueや、PowerShell 7.6.2のMSI版でもローカル実行に失敗したIssueがあります。

そのため、次の順番で確認すると、切り分けやすいかと思います。

1. エラーがコマンド実行前に発生しているか確認する
2. エラー内のcmd=が指しているpwsh.exeを確認する
3. 通常のPowerShellでは同じコマンドが成功するか確認する
4. where.exe pwshとGet-Command pwsh -Allで解決順を確認する
5. PowerShellの導入形態を見直し、Codexから読み取り専用コマンドを再実行する

まとめ

Windows版Codexで最初のファイル読み取りコマンドからCreateProcessAsUserW failed: 5が発生する場合は、対象ファイルの権限変更を急ぐ前に、PowerShellの起動経路を確認します。

今回の環境では、エラーのcmd=がWindowsApps配下のpwsh.exeを指しており、where.exe pwshでもMSIX版とアプリ実行エイリアスが見つかりました。MSI版PowerShellを導入後、MSIX版PowerShellをアンインストールした後、再起動なしでCodexの最初の読み取りコマンドが成功しました。

ただし、これは今回の環境で確認できた結果です。CodexやPowerShellのバージョン、Windowsのsandbox実装、PATH、セキュリティ設定によって原因は変わる可能性があります。エラー全文と実行環境を記録し、まずはプロセス起動、PowerShellの解決先、通常のターミナルでの動作を順番に確認するのがよいかと思います。