Codexでnpm.ps1を実行できない｜PowerShellの制限を切り分ける

CodexがWindows上で「npm.ps1を読み込めない」と表示した場合、指示文の書き方より先に、PowerShellがスクリプトの実行を止めていないか確認します。ただし「アクセス拒否」「承認が必要」「コマンドが見つからない」は別の状態です。表示されたエラーを一括して同じ設定で直そうとしないことが、調査の出発点です。

エラー文で、調べる設定を選ぶ

表示の例	最初の確認先
running scripts is disabled、PSSecurityException	PowerShellの実行ポリシー
承認待ち・許可されていない操作	Codex側の実行許可と対象操作
特定ファイルへのAccess denied	そのパスのアクセス権、使用中かどうか
npmがコマンドとして認識されない	インストール先とPATH、実行環境

OpenAIのWindows向け公式資料にも、npm.ps1が実行ポリシーで止まる例があります。一方、エージェントの承認設定やWindowsのファイル権限は別の仕組みです。一つの層で許可されても、他の層の条件は変わりません。この記事は2026年9月5日に公式資料を確認して整理した手順で、各社PCの管理設定を再現したものではありません。

まずは設定を変更せずに読む

失敗したのと同じPowerShellで次を確認します。別のターミナルで調べた結果を混ぜると、実行環境が違う問題を見落とします。表示された個人フォルダーのパスは、共有時に伏せてください。

$PSVersionTable.PSVersion
Get-ExecutionPolicy
Get-ExecutionPolicy -List
Get-Command npm -All | Select-Object Name,CommandType,Source

引数なしのGet-ExecutionPolicyは有効なポリシーを、-Listは各スコープの設定を示します。一部がUndefinedでも、PC全体で制限がないとは限りません。会社管理の端末なら、表示を持って管理担当者に確認します。インターネットで見つけた一行を貼り付け、端末全体の制限を下げることから始める必要はありません。

Codexの実行環境と、開いている端末を確認する

WindowsネイティブとWSLでは、パスやインストール済みツールが異なります。さらに、アプリの統合ターミナルとエージェントの実行環境は別々に設定できるため、目の前の端末で成功しただけではエージェント側も同じとは判断できません。

記録には「どのアプリの、どの端末で、どのコマンドが失敗したか」を残します。たとえば「PowerShellの手動実行は成功、Codexから同じ作業を頼むと承認で停止」という事実があれば、実行ポリシーの再変更より、依頼した操作と許可範囲を確認する方が調査を進められます。

管理担当者へ渡す確認票

必要な業務：例）社内ページのプレビュー
失敗したコマンド：
実行した場所：Windows／WSL／アプリ内
PowerShellのバージョン：
有効なポリシーと各スコープ：
停止したファイル名：
同じ操作を手動で試した結果：
必要な操作範囲と、変更を戻す条件：

対処後は、対象のコマンドが実行できることと、作りたかった成果物が正しく開くことを別々に確認します。プレビューの起動が成功しても、画面にエラーが出ていれば業務は完了していません。設定変更が必要だった場合は、変更者、対象範囲、理由を残して引き継ぎます。

復旧の記録にはAIツールの障害メモを使えます。ツールの選択段階なら、Claude Code・Codex・Grokの比較記事も参照してください。

確認に使った資料

• OpenAI：Windowsアプリの環境とトラブルシューティング
• Microsoft：Get-ExecutionPolicy