はじめに
この記事は以下の記事のアップデート版です。 ynagaoka.hatenablog.com
最近（2026年5月頃から？）、VSCodeをスリープから復帰させると、
「拡張機能がディスク上で変更されています。ウィンドウを再読み込みしてください。」や、「ウィンドウを読み込めませんでした」が頻発し、再起動を余儀なくされていました。 さすがに不便だったので原因の調査を行った（GitHub CopilotとCodexが）ので、その時の覚書を残しておきます。 基本的に自分が忘れないために書き残していますが、誰かの役に立てば幸いです。
その後も同じ環境を使いながらログを追っていたところ、最初に記事を書いた時点では分かっていなかった原因や設定箇所もいくつか見つかりました。 特にVSCode + Remote-WSLでは、
- Windows側のUser settings
- WSL側のRemote User settings
- Remote-WSL Server側のMachine settings
- Workspace settings
- VSCode起動時の
argv.json
など設定ファイルが複数存在します。
今回の問題では、「どの設定を書くか」だけでなく「その設定をどのファイルに書くか」もかなり重要でした。
そのため、当初の記事の内容にその後分かった内容を加えて更新しています。
以下の記事と重複することも書いてます。 ynagaoka.hatenablog.com
原因の調査
まず、自分の環境にはPythonやR関係、Remote - SSH、Dev Containers、Docker、GitHub Copilot、Codexなど様々な拡張機能がインストールされています。
直近ではCodexを導入し、その頃から頻発するようになったので、
「原因はこいつか？」
と睨んで思い切ってアンインストールしました。
がしかし、事態は変わらず。
自力では無理か……と思いGitHub Copilotに原因の精査と対応をお願いしました。
調査したところ、単一の原因というより、
- 拡張機能の再配置・削除
- 設定の保存場所の不整合
- Extension Host起動時の拡張機能エラー
などが重なっていたようです。
具体的には以下です。
1. VSCode Serverによる拡張機能の更新・削除
VSCode Serverが再接続時に拡張機能を自動更新、または古いバージョンを削除しており、その結果として拡張ディレクトリの中身が変化していました。
ログでは例えば、
ms-ceintl.vscode-language-pack-ja openai.chatgpt
などの古いバージョンが削除されていました。
これが、
拡張機能がディスク上で変更されています。 ウィンドウを再読み込みしてください。
という通知の直接的な引き金の一つになっていたようです。
つまり、「拡張機能が完全に壊れていた」というより、
VSCodeが再接続時に拡張機能を入れ替え、その変更を検知していた
という状態です。
2. Workspace settingsに置くべきでない設定が入っていた
もう一つ問題だったのが設定ファイルです。
対象プロジェクトの、
<project>/.vscode/settings.json
に、
"extensions.autoCheckUpdates": false, "extensions.autoUpdate": "off"
が入っていました。
Remote-WSLで例えば、
/home/<username>/work
をWorkspaceとして使用している場合、
/home/<username>/work/.vscode/settings.json
に相当します。
しかし、拡張機能全体に関係する設定をWorkspace settings側に置くことで、VSCodeが設定を書き込もうとした際にエラーが発生していました。
さらにPython Environments側でも、
python-envs.terminal.autoActivationType
をWorkspace設定へ書き込もうとして失敗していました。
つまり、
拡張機能の更新処理と設定書き込み失敗が同時に発生し、復帰時にエラーや通知が連続していた
という状態でした。
3. Extension Host起動時にも複数のエラーが出ていた
さらにExtension Host起動直後には、
Roo Code: PendingMigrationError: navigator is now a global in nodejs openai.chatgpt: PendingMigrationError: navigator is now a global in nodejs GitHub.copilot-chat: No bundle location found for extension GitHub.copilot-chat
なども記録されていました。
このあたりもExtension Hostの再初期化時の不安定化要因になっていたと考えられます。
実施した対応
原因が見えてきたので修正を行いました。
ここで重要だったのが、
VSCode + Remote-WSLではsettings.jsonが一つではない
という点です。
今回使用した主な設定場所は以下です。
| 種類 | 設定ファイル |
|---|---|
| Windows User settings | C:\Users\<username>\AppData\Roaming\Code\User\settings.json |
| WSL Remote User settings | /home/<username>/.vscode-server/data/User/settings.json |
| WSL Machine settings | /home/<username>/.vscode-server/data/Machine/settings.json |
| Workspace settings | <project>/.vscode/settings.json |
| VSCode起動設定 | C:\Users\<username>\AppData\Roaming\Code\argv.json |
以下、それぞれ何を変更したか記載します。
1. Workspace settings
まず対象プロジェクトの、
<project>/.vscode/settings.json
です。
例えばWorkspaceが、
/home/<username>/work
であれば、
/home/<username>/work/.vscode/settings.json
になります。
ここから、
"extensions.autoCheckUpdates": false, "extensions.autoUpdate": "off"
を削除しました。
Workspace settingsには、基本的にそのプロジェクトだけに必要な設定を残します。
今回の環境では最終的に、
{ "r.lsp.promptToInstall": false, "python.terminal.activateEnvironment": false }
のようなプロジェクト固有の設定のみを残しました。
つまり、
VSCode全体や拡張機能全体の挙動を変更する設定を、何でも.vscode/settings.jsonへ書かない
ということです。
2. Windows側のUser settings
Windows上で動いているVSCode本体のUser settingsは、
C:\Users\<username>\AppData\Roaming\Code\User\settings.json
です。
環境変数を使えば、
%APPDATA%\Code\User\settings.json
です。
拡張機能の自動更新については、こちらに設定しました。
VSCode 1.129.1を使用している現在の環境では、
{ "extensions.autoCheckUpdates": false, "extensions.autoUpdate": "off" }
としています。
これによって、VSCode起動・Remote再接続時に拡張機能が勝手に入れ替わる頻度を抑えています。
CodexをRemote-WSL側で使用しているため、現在の環境ではさらに、
"chatgpt.composerEnterBehavior": "cmdAlways", "chatgpt.runCodexInWindowsSubsystemForLinux": true, "remote.extensionKind": { "openai.chatgpt": [ "workspace" ] }
も設定しています。
ただし、これらは今回の「ウィンドウを読み込めませんでした」問題に対して誰でも必要な設定というわけではありません。
Remote-WSL + Codexを使用している今回の環境固有の設定です。
特に、
remote.extensionKind
は拡張機能をLocal側またはRemote側のどちらのExtension Hostで実行するかに関係するため、必要がなければ無理に設定しない方がよいと思います。
3. WSL側のRemote User settings
Remote-WSLでVSCodeを使用すると、WSL側にもRemote専用のUser settingsがあります。
場所は、
/home/<username>/.vscode-server/data/User/settings.json
です。
今回、Python Environmentsが、
python-envs.terminal.autoActivationType
をWorkspace settingsへ書き込もうとして失敗していました。
そこで、
/home/<username>/.vscode-server/data/User/settings.json
側に、
{ "python-envs.terminal.autoActivationType": "off" }
を設定しました。
つまり、
<project>/.vscode/settings.json
ではなく、
/home/<username>/.vscode-server/data/User/settings.json
に設定しています。
今回のトラブルでは、この
Workspace settingsとRemote User settingsの区別
がかなり重要でした。
4. Remote-WSL Server側のMachine settings
その後もOpenAI/Codex拡張で、
PendingMigrationError: navigator is now a global in nodejs
が発生したため、さらに調査しました。
extensions.supportNodeGlobalNavigator=true自体はUser settingsに入っていたのですが、実際に起動しているRemote Extension Hostには設定が反映されておらず、起動引数に
--supportGlobalNavigator
が付いていませんでした。
そこで、Remote-WSL ServerのMachine settingsとして、
/home/<username>/.vscode-server/data/Machine/settings.json
を作成しました。
内容は、
{ "extensions.supportNodeGlobalNavigator": true }
です。
今回の環境ではmicromambaも使用しているため、実際のファイルには、
{ "extensions.supportNodeGlobalNavigator": true, "python.condaPath": "/home/<username>/.local/bin/micromamba" }
と記載しています。
ただし、
"python.condaPath": "/home/<username>/.local/bin/micromamba"
は今回のVSCode読み込み問題とは直接関係なく、Python環境固有の設定です。
設定後にRemote Extension Hostを再生成し、Linux側で実際のプロセスを確認したところ、
--supportGlobalNavigator
が起動引数に追加されていることを確認できました。
その後のログでは、OpenAI拡張で発生していたPendingMigrationErrorは再発していません。
5. Windows側のargv.json
スリープ復帰時にはElectron rendererやGPU周辺の問題も疑ったため、補助的な対策として、
C:\Users\<username>\AppData\Roaming\Code\argv.json
も作成しました。
内容は、
{ "disable-hardware-acceleration": true }
です。
これはVSCodeのハードウェアアクセラレーションを無効化する設定です。
ただし、ログから、
ハードウェアアクセラレーションが今回の直接原因だったと断定できたわけではありません。
あくまでスリープ復帰時のElectron renderer / GPU周辺を疑って追加した補助的な対策です。
そのため、この設定は全員に必要なものではないと思います。
また、argv.jsonはVSCode起動時に反映されるので、変更した場合はVSCodeを完全終了してから再起動する必要があります。
VSCode Server側に残っていた拡張機能も整理
設定ファイル以外に、Windows側とWSL側の拡張機能ディレクトリも確認しました。
WSL側では、
/home/<username>/.vscode-server/extensions/
Windows側では、
C:\Users\<username>\.vscode\extensions\
です。
調査時には、
- Roo Code
- OpenAI / Codex
- Python Environments
- Jupyter
などについて、旧バージョンや一時的に展開されたと思われるディレクトリが残っていました。
最初の調査では例えば、
rooveterinaryinc.roo-cline-3.54.0 openai.chatgpt-26.623.70822-linux-x64 ms-python.vscode-python-envs-1.36.0-linux-x64
などについて重複や退避用ディレクトリを整理しました。
後日の調査ではWindows側のJupyter拡張が複数バージョン登録されていたり、Windows / WSL双方に.uuid形式のstaging directoryが残っていることも確認できました。
ただし、ここは注意が必要です。
拡張機能ディレクトリに複数のフォルダがあるからといって、いきなり全部削除するのはおすすめしません。
今回は、
extensions.jsonに登録されている拡張機能を確認- 実際のextension directoryと比較
- 古いバージョンや未登録directoryを確認
- いきなり削除せずバックアップへ退避
- VSCodeを完全再起動
- 問題なく起動することを確認
という順番で整理しました。
なぜこの対策が効くのか
今回の対策を整理すると、
Workspace settingsから不適切な設定を外す
Workspace設定からVSCode全体に関係する設定を外すことで、設定の書き込みエラーを減らすことができます。
User settingsへ設定を集約する
User settings側に置くべき設定をUser settingsへ集約することで、
WorkspaceではA RemoteではB WindowsではC
という設定の矛盾を減らせます。
拡張機能の自動的な入れ替えを抑える
拡張機能の自動更新・自動削除がRemote再接続時に走ると、extension directoryの内容が変更されます。
そのため、
拡張機能がディスク上で変更されています
という通知につながる可能性があります。
自動更新の影響を抑え、古い拡張機能の残骸を整理することで、この状態を起こりにくくしました。
LocalとRemoteのExtension Hostを区別する
Remote-WSLでは、
Windows側で動いているVSCode
と、
WSL側で動いているVSCode Server
があります。
さらに拡張機能によって、Local Extension Hostで動くものとRemote Extension Hostで動くものがあります。
今回のCodexのように、
設定自体は存在しているのに、実際に動いているRemote Extension Hostには反映されていない
ということもありました。
そのため設定ファイルを見るだけではなく、「実際にどのExtension Hostで拡張機能が動いているのか」まで確認する必要がありました。
settings.jsonを修正しても残っていたPython interpreter
さらに後日の検証で、少し別の問題も見つかりました。
以前使用していたPython interpreterを削除した後も、VSCodeがそのパスを参照し続けていました。
例として、
/home/<username>/<old-environment>/bin/python
のような、すでに存在しないPython環境です。
調べてみると、この情報はsettings.jsonではなく、VSCode内部のstate DBに保存されていました。
Python拡張の状態として、
wsl_WORKSPACE_FOLDER_INTERPRETER_PATH_/home/<username>/work
のようなキーに古いinterpreter情報が残っていました。 つまり、settings.jsonを全部確認しても見つからない設定がVSCode内部に残っている場合があります。
最終的には、
- VSCodeを完全終了
- state DBをバックアップ
- 該当するPython interpreterのstateのみ削除
- SQLiteの
PRAGMA integrity_checkを実行 - VSCodeを再起動
- 古いinterpreterが再度参照されないことを確認
という処理を行いました。
ここで重要だったのが、Windows側のVSCode本体を完全終了することでした。
Remote Extension Hostだけを終了した状態では、Windows側VSCodeがメモリ上に持っていた古い情報が再度書き戻されることがありました。
ただし、state.vscdbはVSCode内部状態を保存しているSQLite DBなので、通常は直接触らない方がよいと思います。
「settings.jsonに何も残っていないのに古い設定が復活する」
ような場合に、こういう保存場所もあるという程度に覚えておくのがよいと思います。
今回の対応のデメリット
今回の対応にもデメリットがあります。
拡張機能の自動更新をOFFにする
extensions.autoCheckUpdates extensions.autoUpdate
をOFFにすると、拡張機能の新しいバージョンや修正版が出ても自動では反映されにくくなります。
セキュリティ修正や不具合修正への追従も遅くなるので、定期的に手動で更新を確認する必要があります。
自分の場合は、勝手に更新されてVSCodeが不安定になる方が困るので、
必要な拡張機能だけ定期的に手動更新する
という運用にしています。
Python EnvironmentsのautoActivationをOFFにする
python-envs.terminal.autoActivationType
をOFFにすると、ターミナルを作成した際のPython環境の自動有効化が止まります。
そのため必要に応じて、
source .venv/bin/activate
や、
micromamba activate <environment>
などを手動で実行する必要があります。
このあたりは利便性とのトレードオフですね。
その後の再検証
最初にこの記事を書いた時点では、「とりあえず症状が消えた」というところまでの確認でした。 その後もログを確認しながら修正を続け、Windows側のVSCodeを完全終了して再起動した状態でも改めて検証しました。
最終的にはRemote Extension Hostが、
--supportGlobalNavigator
付きで起動していることを確認できました。
また、以前発生していた、
PendingMigrationError
やWindows / WSL間のパス混在に関連したエラーも再発していません。
OpenAI / Codex拡張についても、
activation app-server起動 画面のmount
まで正常に完了しています。
Pythonについても、削除済みinterpreterの参照は再発せず、
/home/<username>/work/.venv/bin/python /usr/bin/python3 /home/<username>/work/micromamba/envs/<environment>
などの環境を正常に検出できています。
まだ残っている問題
最初の記事では、
openai.chatgpt: PendingMigrationError
も残存問題としていました。
しかし、その後Remote-WSL側のMachine settingsを修正し、Remote Extension Hostに、
--supportGlobalNavigator
が実際に付いていることを確認した後は、このエラーは再発していません。
一方でGitHub Copilotについては現在も、
No bundle location found for extension GitHub.copilot-chat chatParticipant must be declared in package.json: claude-code TypeError: e is not iterable
などのログが残っています。
ただし、これらのエラーが出た後も、
- GitHub token取得
- Copilot contributionのactivation
- context keyの設定
などには成功しています。
そのため現時点では、今回の「ウィンドウを読み込めませんでした」の直接原因とは別問題として考えています。 拡張機能側やVSCode側の更新によって今後解決する可能性があるため、現時点では無理に内部ファイルを変更することはしていません。
今回分かったこと
今回一番勉強になったのは、VSCode + Remote-WSLでは、settings.jsonを直せば終わりではないということです。 少なくとも今回の環境では、
Windows User settings WSL Remote User settings Remote Machine settings Workspace settings argv.json extension directory VSCode内部のstate DB
という複数の設定・状態保存先が関係していました。
特にRemote-WSLの場合、
Windows側のVSCode
↓
Remote-WSL
↓
WSL側のVSCode Server
↓
Extension Host
↓
各Extension
という構成になるため、
「その設定をどこに書いたか」だけでなく、「その設定を実際にどのExtension Hostへ反映させたいのか」まで考える必要があります。
今回のような症状が発生した場合は、Workspaceの、
.vscode/settings.json
だけを確認するのではなく、
Windows User settings Remote User settings Machine settings
が矛盾していないか確認してみるとよいと思います。
おわりに
当初の対策後、一旦は「ウィンドウを読み込めませんでした」が頻発することはなくなりました。
その後もCodex、Python Environments、GitHub Copilotなどのログを追って追加修正を行いましたが、Windows側VSCodeを完全終了・再起動した後も、現在は同じ症状が頻発する状態には戻っていません。
今回の件では、最初は、「Codexを入れたから壊れたのでは？」、「拡張機能を入れすぎた？」くらいに考えていました。 しかし実際には、単一の拡張機能だけが原因というより、
拡張機能の更新、設定スコープの混在、Remote Extension Hostへの設定反映、VSCode内部に残った古い状態
などが重なっていたようです。
特に今回の収穫は、
VSCode + Remote-WSLでは「何を設定するか」と同じくらい「どの設定ファイルに書くか」が重要
ということでした。
今後も様々な拡張機能を導入していくことになると思うので、不具合が出たら逐一ログを確認しないといけないですね。 長々と書きましたが誰かの役に立てば幸いです。
