Claude Desktop MSIX版でterminalが60秒で閉じる原因と切り分け

Windows版Claude Desktop(MSIXパッケージ)のCodeタブで、Claudeがrun_in_terminalを呼ぶと「had not reached a prompt after 60 s」で失敗し、タブが閉じる報告があります。手で開いたタブは普通に動くのが特徴です。

報告されている原因は、シェルの統合ファイルがMSIXのAppData仮想化の内側にだけ書かれ、パッケージの外で動くシェルから見えないことです。症状の見分け方、自分の環境で確かめる手順、試されて失敗した回避策、動いたと報告された回避策の順に書きます。

症状: 手で開くタブは動き、run_in_terminalだけが落ちる

Claudeにrun_in_terminalでコマンドを実行させると、新しいターミナルタブが開き、約60秒後に次の趣旨のエラーでタブが閉じます。

the shell in new terminal tab had not reached a prompt after 60 s ... The tab was closed

タブには、閉じられる前に次の警告も出ています。英語環境での文面です。

WARNING: Claude terminal integration did not load: Exception calling "ReadAllText" with "1" argument(s):
"Could not find a part of the path 'C:\Users\<user>\AppData\Roaming\Claude\terminal-shell-integration\pwsh\claude-desktop.ps1'."

ドイツ語やポルトガル語の環境でも同じ警告が出ており、文面は表示言語で変わります。見分けの目印はReadAllTextとterminal-shell-integrationのパスです。

プロンプト自体は画面に出ていて、手で入力すれば動きます。Claude Code CLIのネイティブインストール版はこの影響を受けない、と最初の報告は書いています。

報告者の環境は、Windows 11(Home・Pro)、Windows PowerShell 5.1またはPowerShell 7.6.6、Desktopのバージョン2.16120.0.0〜2.26454.2.0です。2.26454.2.0でも再現した、と2026年10月8日のコメントが書いています。

原因: シェルが統合ファイルを見つけられない

最初のissueの分析では、原因はMSIXのAppData仮想化です。

Desktopアプリはパッケージの内側で動くため、%APPDATA%\Claude\terminal-shell-integration\への書き込みが、実際には次の仮想化された場所に入ります。

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\terminal-shell-integration\

一方、Terminalパネルのシェルはパッケージの外で動きます。シェルは本物の%APPDATA%にあるclaude-desktop.ps1を読もうとして、見つけられません。

spawn\フォルダーに置かれるタブごとのnonceファイルも同じ状況です。nonceは、シェルが出す「プロンプトに到達した」という印を信頼してよいかを確かめる合言葉のようなものです。環境変数CLAUDE_DESKTOP_TERMINAL_NONCE_FILEがそのファイルを指します。

結果として、シェルは統合スクリプトを読み込めず、Desktop側は準備完了の印を受け取れません。60秒待って失敗とみなし、タブを閉じます。

自分の環境が当てはまるか確かめる

確かめるコマンドは、手で開いたTerminalパネルのタブ、またはWindows Terminalから実行します。Claudeのツール経由で実行すると、仮想化された側の見え方になり、結果が変わります。

# シェルから見える本物のパス(原因の報告どおりなら False)
Test-Path "$env:APPDATA\Claude\terminal-shell-integration\pwsh\claude-desktop.ps1"
 
# 仮想化された側のパス(True ならアプリは書けている)
Test-Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\terminal-shell-integration\pwsh\claude-desktop.ps1"

前者がFalse、後者がTrueなら、報告されている症状と同じ状態です。issueでは、Terminalパネルのタブから実行した結果として、この組み合わせが示されています。

アプリ側のログも手がかりになります。ログは%LOCALAPPDATA%\Claude\Logs\main.logにあり、ShellPtyManagerの行を探します。

Select-String -Path "$env:LOCALAPPDATA\Claude\Logs\main.log" -Pattern "ShellPtyManager"

フォルダーをコピーしただけの環境では、OSC 133 marks no longer trusted(nonceが漏れたか、集められなかった)という警告がログに出た、という報告があります。

試されて失敗した回避策: コピーとjunction

issueのコメントでは、手軽に思いつく2つの方法がどちらも失敗したと確かめられています。

junctionの失敗は、MSIXの書き込み仮想化がリパースポイントを扱えない問題として、別のissue(#83584)で報告されている制約と同じものです。%APPDATA%\Claudeの配下にリンクを置くと、排他的な新規作成が実際にはファイルが無いのにEEXISTで失敗します。

最初の報告でjunctionを試した人も、後のコメントで「動かなかった」と訂正しています。junctionを作ってしまった場合は、リンクだけを外します。ファイルの実体を消す必要はありません。

cmd /c rmdir "$env:APPDATA\Claude\terminal-shell-integration"

rmdirはリンクだけを外します。実行前に、そのパスが本当にjunctionかはGet-Item -ForceのLinkTypeで確認できます。

動いたと報告された回避策: パッケージの外のブリッジ

コメントの1つが、動いたとする回避策を報告しています。パッケージの外でPowerShellスクリプトを常駐させ、必要なファイルを本物の%APPDATA%へ写し続ける方法です。PowerShell 7.6.6、Desktop 2.19675.1.0で、run_in_terminalがコマンドを入力し、出力を読み戻すところまで確認されています。

仕組みは次のとおりです。

• %APPDATA%\Claude\terminal-shell-integrationには、リンクではなく本物のフォルダーを置く
• 仮想化された側のspawn\に現れる新しいnonceファイルを、25ミリ秒ごとの確認でコピーする。シェルはタブ起動後の数百ミリ秒で読むためで、各nonceは1回だけコピーする(シェルが読んだ後に消すので、復活させない)
• pwsh・bash・zsh・fishの統合スクリプトは、変更があったときだけ1秒ごとにコピーする
• Claudeのアプリの中ではなく、Windows Terminalなどパッケージの外から起動して開いたままにする。アプリのツール経由で起動すると、仮想化された見え方になるため

止めるときはCtrl+Cで、元に戻すときは%APPDATA%\Claude\terminal-shell-integrationを削除します。

スクリプトの全文はissue #99192のコメントにあります。ただし、投稿者自身が「応急処置」と位置づけ、アプリ側の修正が本筋だと書いています。常駐プロセスがファイルを複製する方式なので、会社支給のPCでは実行ポリシーやセキュリティ製品との相性を、管理者と確かめてから使う種類のものです。

同じ「60秒」でも別の問題の場合

「60秒」「PowerShell」「Desktop」が並ぶ症状は他にもあり、原因は別です。切り分けの目印を挙げます。

MSIX版ではほかにも、非ページプールの増加などAppData仮想化まわりの症状が報告されています。その一例は非ページプールが増え続ける原因にあります。MSIXでの一括導入そのものはWindowsでの一括導入手順にまとめています。

別の仮説: 競合状態という見立て

同じ症状を報告した別のissue(#98979)は、原因をMSIXの仮想化とは書いていません。Microsoft Store経由のインストールで、PowerShell 5.1を使う環境の報告です。

そのissueの見立ては次のとおりです。

• スクリプトは存在し、通常のPowerShellからはReadAllTextで読める
• 更新日時が、タブを開くたびに新しくなる
• 例外がFileNotFoundExceptionではなくDirectoryNotFoundExceptionで、ディレクトリの途中が欠けていた形である

そこから、pwsh\フォルダーがシェルの起動中に削除・再作成されているのではないか、と推測しています。提案は、スクリプトをシェルの起動前に書き、毎回ディレクトリを消さずに上書きすることです。

この見立ては推測の段階で、仮想化説との優劣はissue上で決着していません。仮想化説の側には、本物のパスがFalseで仮想化されたパスがTrueになるという直接の確認があります。切り分けには、前の節のコマンド結果を使えます。

修正の見通しと、待つ間の使い方

#99192は2026年10月3日に起票され、10月8日のコメントでもDesktop 2.26454.2.0での再現が報告されています。修正されたバージョンは示されていません。

コメントで提案されている修正方向は3つです。

• マニフェストにFileSystemWriteVirtualizationの除外として$(KnownFolder:RoamingAppData)\Claudeを加える(#83584で提案された1行の変更)
• フックのスクリプトとnonceを、シェルから見える場所(%TEMP%など)に書く
• nonceをファイルではなく環境変数で渡す

どれも提案で、採用されたとは書かれていません。

待つ間の使い方としては、次のように切り分けられます。

• Claudeにコマンドを走らせたい: Terminalパネルを介さず、Claudeの通常のシェルツール(Bash・PowerShell)で実行させる。パッケージの内側で動くので、この問題の影響を受けません。
• 対話入力が必要なコマンド: 手で開いたタブで自分が実行する。issueには、確認入力が要る取引系のCLIをClaudeから渡せず、ユーザーが自分のタブで実行した例があります。
• どうしてもrun_in_terminalが要る: 前の節のブリッジを、リスクを理解したうえで試す。

公式のDesktopドキュメントは、統合ターミナルを「セッションの作業ディレクトリで開き、Claudeと同じ環境を共有する」機能として説明しています。Desktopドキュメントの統合ターミナルの説明には、MSIX固有の制限が載っていません。Desktop全般のつまずきはDesktopのトラブルシューティングで扱っています。