Claude Code DesktopのPowerShellが毎回約154秒待たされる原因と切り分け

Windows版のClaude Desktop(Codeタブ)で、PowerShellツールの呼び出しだけが毎回約150秒止まってから動き出す。そんな報告がGitHubのissue #94344にあります。Get-Date のような一瞬で終わるコマンドでも待たされ、同じマシンのBashツールは数秒で返ります。

この症状の原因は、報告者が追加のA-B-A検証で突き止めています。Claude Code本体の不具合ではなく、ウイルス対策ソフトがPowerShellの起動を保留していたという結論です。以下では、報告の中身、切り分けの手順、待ちを避ける方法を順に追います。

どんな症状か:PowerShellだけが約154秒止まる

issueの報告者は、Windows 11でClaude Desktop(同梱のClaude Code 2.1.270)を使っています。Windows PowerShell 5.1が入っていて、PowerShell 7(pwsh)は未導入、BashツールはGit Bashで動いている環境です。

報告された計測は、同じマシンでのツール別の所要時間です。

PowerShellの呼び出しのうち851件(68%)が60秒を超え、その合計は121セッションで37.8時間に達しています。待ちはClaude Code 2.1.220から2.1.270までのどのバージョンでも出ていました。

特徴は次の4点です。

• エラーは出ず、待ったあとに成功する
• 同じコマンドをもう一度投げると、2〜3秒で返ることがある
• 自動モードでも手動モードでも、サンドボックスの有無でも変わらない
• 許可ダイアログは待ちのあとに出る。待ちはダイアログより前にあります

重い処理が走っているのではなく、コマンドが始まる前に固定の長さで止まっている症状です。

先に結論:原因は報告者の環境のウイルス対策ソフト

当初のissueは「Claude Codeの不具合」として出されました。ところが報告者はのちに、次のように訂正しています。

根本原因はClaude Codeではなくアンチウイルス(Avira Free)だった

訂正の根拠は、リアルタイム保護だけを切り替えたA-B-A検証です。CLI 2.1.270で同じ依頼を4回流しています。

3回目は2回目と同じコマンドで、保護をオンに戻した途端にまた遅くなっています。キャッシュや繰り返しの効果ではありません。4回目はAviraを削除して再起動したあと、Windows Defenderのリアルタイム保護・改ざん防止・クラウド保護をすべてオンにした状態で、待ちは出ていません。

報告者の解釈では、Claude Codeが起動する powershell.exe -EncodedCommand ... をAviraが止めています。同じ powershell.exe でも、Bashツール経由で起動したものは遅れません。

ここで注意したいのは範囲です。この検証が示したのは、報告者の環境でAviraが原因だったことと、Windows Defenderでは再現しなかったことまでです。ほかのセキュリティ製品でも同じ待ちが出るかは、このissueからは分かりません。「約150秒」という長さの理由も、報告には書かれていません。

なぜPowerShellツールだけが影響を受けるのか

報告者が観察した、待ちの正体に近い事実を並べます。

1. プロセスの起動を監視すると、ツール呼び出しの直後に powershell.exe が -NoProfile -NonInteractive -NoLogo -EncodedCommand ... 付きで起動する。これはコマンドを解析する小さなスクリプトで、手で同じものを動かすと約1秒で終わる
2. その後、約150秒のあいだ呼び出しに関するプロセスの動きがなく、そのあとで実際のコマンドが走る
3. PreToolUseフックで deny を返すと、PowerShellの呼び出しは1.59秒で拒否される。フックの評価は待ちより前に終わっている

待ちは「フック評価のあと、コマンド開始のまえ」に位置します。報告者は、Claude Codeの起動引数が -EncodedCommand であることに着目しました。報告者が紹介するKilo Codeの変更(kilocode#11526)には、Windowsのエンドポイントセキュリティ製品が powershell.exe -EncodedCommand を難読化されたコマンド実行として扱うことが多い、という理由が書かれているそうです。

一方、Bashツール経由の powershell.exe は引数が違うので、同じ検査に引っかからなかったと読めます。ただし、これは報告者の推定であり、Aviraの内部動作を確かめた結果ではありません。

なお、Claude Codeの公式ドキュメントによれば、PowerShellツールは -ExecutionPolicy Bypass をプロセス単位で付けて起動します。実行ポリシーはこの待ちの原因として報告されていません。待ちが出るのは Get-Date のような単純なコマンドでも同じだからです。

自分の環境で切り分ける手順

症状が自分の環境に当てはまるか、順番に確かめます。

手順1:PowerShellとBashを同じ依頼で比べる

ツール呼び出しを1つずつ順番に走らせるのがコツです。報告者は、PowerShellとBashを同じブロックで呼ぶと、あとのツールが前の待ちを引き継いで遅く見えると書いています。依頼文に「結果を待ってから次を実行」と入れます。

echo "Run Get-Date using the PowerShell tool. Wait for its result, then run date using the Bash tool. Output only the two results." \
  | claude -p --permission-mode auto --allowedTools "PowerShell,Bash"

報告者の再現では、PowerShellが約154秒、Bashが2〜3秒でした。所要時間はセッションのトランスクリプトから読んでいます。出力の時刻が数秒ずれているだけなのに、Bashの欄が150秒台に見えたら、順番に呼ばれていない可能性があります。

このコマンドは claude -p を使うCLIの再現です。つまり、この待ちはデスクトップアプリ固有ではなく、Claude Codeを起動するPCで起きるものとして報告されています。デスクトップアプリとCLIの両方で同じ待ちが出るなら、アプリの画面側ではなく、PCの側を疑う手がかりになります。

手順2:リアルタイム保護だけをオンオフして比べる

報告者の検証と同じく、条件を1つだけ変えます。

1. セキュリティ製品のリアルタイム保護をオンにして、手順1を実行する
2. リアルタイム保護だけをオフにして、同じコマンドを実行する
3. オンに戻してもう一度実行し、遅さが戻るか確かめる

オフで速くなり、オンに戻すと遅くなるなら、その製品が原因の第一候補です。3回目を省かないでください。2回目だけ速いのは、キャッシュや初回起動の違いでも起こるからです。

保護をオフにしたまま作業を続けるのは勧められません。比較が終わったらオンに戻し、続きは次の節の方法で進めます。

手順3:Windows Defenderだけの状態と比べる

サードパーティ製品を削除できる環境なら、Windows Defenderだけの状態で同じ計測をすると決着がつきます。報告者はAvira削除後に2.1秒まで戻っています。会社支給のPCなど、自分で削除できない場合は、情報システム部門に伝える材料として手順2の結果を持っていくのが現実的です。

待ちを避ける方法

原因の製品を入れ替えられないとき、報告者のissueと公式ドキュメントから取れる選択肢です。

BashをメインにしてPowerShellツールを使わない

Git Bashが入っているWindowsなら、PowerShellツールを切れます。公式ドキュメントでは、Git Bash導入済みのWindowsで CLAUDE_CODE_USE_POWERSHELL_TOOL=0 にするとツールが無効になります。

{
  "env": {
    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "0"
  }
}

これを settings.json の env に入れると、ClaudeはBashツールだけでコマンドを実行します。ただし、Git Bashが入っていない環境ではPowerShellツールが自動で有効になるため、切ると使えるシェルがなくなります。事前にGit Bashの有無を確認してください。

誤って呼んだときの待ちをフックで短くする

報告者は、PreToolUseフックでPowerShellを deny すると1.59秒で断れることを確かめ、待ちを避ける副次的な方法として挙げています。拒否メッセージにBashへの誘導を書いておけば、モデルがBashで言い直します。フックの出力形式は公式ドキュメントの hookSpecificOutput です。

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "PowerShellツールは使わず、Bashツールで同じ操作を実行してください"
  }
}

これをマッチャー PowerShell のフックが標準出力に返す形です。フックの command 側の書き方は、お使いのシェルに合わせてください。Git Bash導入済みのWindowsでは、シェル形式のフックはGit Bashで実行されます。

どちらの方法も、待ちの原因を取り除くわけではありません。原因側の対処は、セキュリティ製品の設定を見直すか入れ替えるかです。除外設定の具体的な手順は製品ごとに違い、このissueは扱っていません。

似た症状との見分け方

PowerShellやBashまわりの不調は、症状ごとに原因が違います。

待ちの長さが毎回ほぼ同じ(報告では約150〜155秒で、ばらつきは0.4秒)なら、負荷や通信ではなく固定のタイムアウトに近い挙動です。数秒から数十秒でばらつくなら、別の原因を疑うほうが自然です。報告者も、1セッションに数回だけ33〜38秒になる呼び出しがあったと書いていますが、規則性は見つかっていません。

報告者が挙げたClaude Code側の改善案

報告者は、環境要因と分かったうえで、Claude Code側にできることを3つ挙げています。

1. PowerShellの起動を -EncodedCommand ではなく -Command(平文)にする。別のコーディングツールであるKilo Codeが2026年6月に同じ変更を入れた
2. PowerShellの解析やツール起動が数秒を超えたら警告を出す。いまは待ちが完全に無言で、同じ約150秒の症状を示す過去のissueが複数あるのに、誰もセキュリティ製品を疑わなかった
3. ドキュメントのWindows向けの節に、ウイルス対策ソフトやEDR(エンドポイント検知・対応)の干渉を書く

1つ目については、同じ要望が以前のissue(#62348)にもあり、「対応予定なし」で閉じられていたと報告者は書いています。2つ目は、待ちの無言こそが切り分けを難しくしている点を突いています。待たされている間、画面にもログにも手がかりが出ません。

まとめ

PowerShellツールだけが毎回約150秒止まるなら、Claude Codeの設定より先にセキュリティ製品を疑う価値があります。報告者のケースでは、リアルタイム保護のオン・オフ・オンで待ちが再現し、Windows Defenderだけにすると消えました。

手元での確認は、PowerShellとBashを順番に呼ぶ比較、リアルタイム保護だけを切り替える比較、の2段で足ります。原因が製品側にあると分かったら、除外設定や製品の入れ替えを検討し、当面はBashを主にするか、フックでPowerShellを早めに断る運用が回避策になります。WindowsでのDesktopの導入全体はClaude Desktop Windows版のインストールと初期設定にあります。