メインコンテンツへスキップ

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

このページでは、Windows Subsystem for Linux (WSL) でDevin Desktopを利用する際に発生する既知の問題と、推奨される対処法を説明します。

動作の低下または切断 (9Pファイルシステムの飽和)

WSL で Devin Desktop を利用している場合 (Remote - WSL 経由) 、エディタの動作が遅くなったり、応答しなくなったり、WSL バックエンドとの接続が繰り返し切断されたりすることがあります。これは多くの場合、拡張機能が WSL ファイルシステム上で過剰にファイル監視やインデックス作成を行い、Windows と WSL の Linux 環境をつなぐファイルシステムブリッジである Plan 9 (9P) プロトコル を飽和させることが原因です。 この問題は、大規模なリポジトリや、複数の言語サーバーが同時に実行されている環境で特に発生しやすくなります。

症状

  • WSL に接続していると、Devin Desktop の動作が明らかに遅くなったり、重くなったりする
  • エディタが WSL バックエンドから頻繁に切断され、再接続を繰り返す
  • 切断は、アクティブな開発中 (例: Cascade の使用中) エディタがアイドル状態のときの両方で発生する
  • Devin Desktop がクラッシュしたり応答しなくなったりして、IDE と WSL の両方を再起動する必要がある (wsl --shutdown)
  • 32 GB 以上の RAM を搭載したシステムでも、WSL のメモリ使用量が時間の経過とともに増加する
  • WSL の診断ログに P9 Reply_Rlerror イベント (ファイル未検出エラー) が大量に記録される
  • WSL の外で Devin Desktop を使用している場合 (例: ローカルの Windows フォルダを開いている場合) 、パフォーマンスは正常である
  • 一般的な回避策 (WSL の再起動、Devin Desktop の再インストール、.wslconfig のメモリ増加) だけでは、この問題は解消しない

根本原因

Windows と WSL の Linux ファイルシステム間の通信には Plan 9 (9P) プロトコルが使われており、ネイティブのファイルシステムアクセスと比べるとスループットが制限されます。 WSL 環境に拡張機能をインストールすると、その一部がワークスペース全体に対して積極的にファイル監視やインデックス作成を行います。大規模なリポジトリ (例: 250,000 超のファイル、5 GB 超) では、その結果 9P ブリッジ経由で膨大な量のファイルシステム操作が発生し、次のような問題を引き起こすことがあります。
  • プロトコルの処理能力を飽和させる
  • ファイルが見つからないエラー (Reply_Rlerror) を何千件も発生させる
  • Devin Desktop と WSL バックエンド間の接続が切断される原因になる
  • 時間の経過とともに WSL 内のメモリ負荷の増大につながる
複数の言語サーバーも同時に動作している場合 (例: Sorbet、Ruby LSP、TypeScript など) 、追加のファイル監視負荷が発生するため、この問題はさらに悪化します。拡張機能と言語サーバーによるファイルシステムの負荷が重なると、32 GB 以上の RAM を搭載したシステムでも 9P ブリッジが処理しきれなくなることがあります。 既知の例として Vue (Volar) 拡張機能があり、ワークスペースに Vue ファイルが含まれていない場合でも、WSL 環境で過剰なファイルのインデックス作成を引き起こすことが確認されています。この問題は VS Code 関連のエコシステムでも記録されています。 microsoft/vscode-remote-release#11091 これは特に、現在のプロジェクトでは不要な多数の拡張機能を VS Code や別のエディターから引き継いでいる場合に起こりやすくなります。

解決策

WSL で発生する切断やパフォーマンスの問題の多くは、WSL 自体を更新するだけで解消します。新しい WSL リリースには、9P ファイルシステムの安定性や接続信頼性の改善が含まれています。 Windows ホストで PowerShell (またはコマンド プロンプト) を開き、次を実行します。
wsl --update
その後、WSL を再起動してください。
wsl --shutdown
Devin Desktop を再度開き、WSL に再接続してください。WSL のバージョンは、次のコマンドで確認できます。
wsl --version
WSL 2.7.3.0 以降には、ほかの設定変更を行わなくても、ユーザーに継続的に発生していた切断の問題を解消する修正が含まれています。

2. WSL 内の Devin Desktop サーバーのクリーン再インストール

WSL 内の Devin Desktop サーバーのディレクトリを削除し、次回接続時に Devin Desktop に再インストールさせます:
rm -rf ~/.windsurf-server
その後、Devin Desktop を WSL に再接続してください。サーバーは自動的に再インストールされます。

3. インストールする拡張機能を最小限にする (最も効果が高い)

作業中のリポジトリで本当に必要な拡張機能だけをインストールしてください。
  • WSL に接続した状態で、Devin Desktop の拡張機能パネルを開きます
  • WSL 環境にインストールされている拡張機能を確認します (ローカル環境だけではありません)
  • 不要な拡張機能は無効化またはアンインストールします。特に、負荷の高いファイル監視やインデックス作成を行うものに注意してください
WSL で問題が確認されている拡張機能:
  • Vue (Volar) — Vue 以外のプロジェクトでも、9P ブリッジ経由で過剰なファイルのインデックス作成を引き起こすことが確認されています。この拡張機能をアンインストールしただけで、複数のユーザーで切断が解消されています。
  • その他のフレームワーク固有の言語拡張機能 (Angular、Svelte など) も、インストールされていて現在のワークスペースで不要な場合は、同様の挙動を示すことがあります。
ローカル (非 WSL) 環境で問題なく動作する拡張機能が、WSL でも同じように動作するとは 考えないで ください。ボトルネックは 9P ファイルシステムブリッジです。ローカルでは無害な拡張機能でも、すべてのファイル操作がプロトコル境界をまたぐ WSL では、不安定化の原因になることがあります。 拡張機能によるファイルシステム処理を減らせば、9P ブリッジの負荷も直接軽減できます。

4. WSL のリソース制限を最適化する

Windows ホストで、システムに適したリソース制限を設定するために、%USERPROFILE%\.wslconfig ファイルを作成または編集します (例: C:\Users\<YourUser>\.wslconfig) 。
[wsl2]
memory=16GB
swap=4GB
processors=4
autoMemoryReclaim=gradual
注: autoMemoryReclaim 設定は WSL 2.7.3.0 以降で削除されました。WSL 2.7.3.0 以降を実行している場合は、この行を省略してください。wsl --version で WSL のバージョンを確認できます。
値は、システムで使用可能なリソースに応じて調整してください。 ファイルを保存したら、WSL を再起動してください:
wsl --shutdown
その後、Devin Desktopを開き直し、WSLに再接続します。

原因の特定

WSL の診断ログで 9P エラーを確認する

原因が 9P の飽和であることを確認するには、WSL の診断ログを収集します:
wsl --debug-shell
または、フル診断バンドルを収集します:
Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1
.\wsldiag.ps1
9P/ファイルシステムのログで、Reply_Rlerror イベントが大量に発生していないか確認してください。通常、数千件 (またはそれ以上) 発生している場合は、WSL 内の拡張機能またはプロセスが過剰なファイルシステム リクエストを生成しており、9P ブリッジがそれを処理しきれていないことを示します。

どの対処法を使うべきか

  • まずは WSL を更新してください。wsl --update を実行するだけで解決する問題が多くあります。WSL 2.7.3.0+ には安定性を大きく改善する変更が含まれています。 (最も簡単な対処法です。)
  • WSL に現在は不要な拡張機能が多数インストールされている場合や、別のエディタから拡張機能を移行した場合は、拡張機能を最小限にすることを検討してください。 (最も効果の大きい変更です。)
  • Devin Desktop のサーバー状態が破損している、または古い状態のまま残っている可能性がある場合は、サーバーをクリーン再インストールしてください (たとえば、更新に失敗した後や、以前クラッシュした後など) 。
  • WSL がホストのリソースを過剰に消費している場合や、これまでリソース制限を設定していない場合は、.wslconfig を最適化してください。 (WSL 全体の安定性向上につながります。)
最良の結果を得るには、まず WSL を更新し、その後必要に応じて残りの対処法を適用してください。最新の WSL、クリーンなサーバー、最小限の拡張機能、適切に調整されたリソース制限を組み合わせることで、根本原因 (拡張機能の動作による 9P の飽和) と、そこに拍車をかける要因 (リソース枯渇) の両方に対処できます。

VPN またはゼロトラスト ソフトウェア使用時に WSL に接続できない

VPN またはゼロトラスト ソフトウェア (Twingate、Tailscale、Zscaler、Cloudflare WARP、GlobalProtect など) によって WSL 内からの外向きのネットワーク通信がブロックされると、Devin Desktop は Couldn't install vscode server on remote server, install script returned non-zero exit status というエラーを表示して WSL への接続に失敗します。

症状

  • Devin Desktop で、WSL への接続時に Error resolving authority / install script returned non-zero exit status が表示される
  • WSL 自体は動作しており (wsl -d Ubuntu -- echo hello は成功する) 、curl も WSL 内で実行できるがタイムアウトする
  • VPN またはゼロトラストソフトウェアをインストールまたは更新した後から、この問題が発生し始めた

根本原因

WSL 2 はデフォルトで、NAT ベースの仮想ネットワーク経由でトラフィックをルーティングします。VPN やゼロトラストソフトウェアでは、この仮想ネットワークからのトラフィックが転送されないことが多いため、Devin Desktop サーバーのダウンロードはエラーが表示されないまま失敗します。

解決策

1. ミラーネットワーキングを有効にする

WSL の設定ファイルを編集し、ミラーネットワーキングを有効にします (通常は C:\Users\<YourUser>\.wslconfig) 。 以下を追加します:
[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true
その後、WSL を再起動し、滞留したインストール状態をクリーンアップします。
wsl --shutdown
wsl -d Ubuntu -- bash -c "rm -f ~/.windsurf-server/.installation_lock"
Devin Desktop を再度開き、WSL に再接続します。サーバーは自動的にインストールされます。
注: WSL 2.0.0 以降が必要です。確認するには wsl --version を実行し、必要に応じて wsl --update を実行してアップグレードしてください。

2. 代替手段: VPN を一時的に切断する

.wslconfig を変更できない場合は、VPN/ZTNA を切断し、Devin Desktop でサーバーをインストールしてから、再接続してください。今後 Devin Desktop を更新する際には、WSL からのネットワークアクセスが再び必要になります。