Question 1

read_multiple_files が複数の大きな画像を返すときに発生する「MCP error -32000: Connection closed」は、どのように修正すればよいですか？

Accepted Answer

**Remote Desktop Commander を 0.2.51 以降にアップグレードしてください**。バージョン 0.2.51 では、サイズが大きすぎる `read_multiple_files` のレスポンスが MCP stdio バッファを超過しないようにガードされ、ローカルの Desktop Commander 子プロセスが終了した場合に実行中の呼び出しを直ちに失敗させます。

根本原因: `@modelcontextprotocol/sdk` 1.30.0 では、`StdioClientTransport` がデフォルトで **10 MiB の読み取りバッファ**を使用しており、単一のメッセージがそれを超過するとトランスポートを閉じます。Base64 エンコードされた画像が複数あると、この制限を簡単に超えてしまいます。たとえば、約 8.8 MB のソース画像が、JSON のオーバーヘッドを含める前の段階で約 11.8 MB の Base64 になりました。

0.2.47 での回避策:
1. PNG/JPEG ファイルを個別に、またはより小さなバッチで読み取ってください。
2. 結合した Base64 ペイロードを 10 MiB 未満に抑えてください。Base64 と JSON のオーバーヘッドを考慮し、ソース画像は控えめに **1 リクエストあたり約 7 MB 以下**に抑えてください。
3. クライアントが `Not connected` を報告した場合は、Remote Desktop Commander を再起動してください。
4. `read_multiple_files` 呼び出しあたりのファイル数を減らして再試行してください。

Question 2

WebSocket socket 1006 の後に "IncreaseConnectionPool" で Desktop Commander リモートがオフラインになる問題の修正方法

Accepted Answer

リモートエージェントを Desktop Commander `0.2.51` 以降にアップグレードしてください。再接続／コネクションプールの問題はそのリリースで修正され、動作が確認されています。既存のリモートエージェントをすべて停止し、重複している `index.js remote`/Node プロセスを削除してから、以下のコマンドで再起動してください：

```bash
npx @wonderwhy-er/desktop-commander@latest remote
```

修正済みリリースを明示的にテストするには、以下を使用してください：

```bash
npx @wonderwhy-er/desktop-commander@0.2.51 remote
```

バージョン `0.2.47` では、エージェントを再起動しても接続は一時的にしか回復しません。アップグレード後もエラーが解消しない場合、特に Cloudflare の `525` SSL エラーと併発している場合は、ネットワーク/SSL 経路と Desktop Commander サービスのステータスを確認してください。これは別のサービス容量または接続性の問題を示している可能性があります。

Question 3

Desktop Commander MCP サーバーが initialize 時にブラウザのウェルカムページを開くのを停止するにはどうすればよいですか？

Accepted Answer

ウェルカムページは Desktop Commander の初回実行時のオンボーディングで、一度だけ開きます。これを表示せずに実行するには、次を実行してください：

```bash
npx @wonderwhy-er/desktop-commander@latest setup --no-onboarding
```

Desktop Commander の起動時に `--no-onboarding` を渡すか、設定で `onboarding_injection: false` を設定することもできます。これにより、ヘッドレス、IDE、CI 環境において、MCP の `initialize` ハンドシェイク中にブラウザウィンドウや `utm_source` アナリティクスリクエストがトリガーされるのを防ぎます。

Question 4

desktop-commander 0.2.52 で `npm audit --omit=dev` によって報告された深刻度の高い脆弱性は、どのように修正すればよいですか？

Accepted Answer

これらの脆弱性は、マージされた本番依存関係の更新によって修正されており、`npm audit --omit=dev` の検出数が38件から0件に減少します。公開され次第、この修正を含むリリースにアップグレードしてください：

```bash
npm install -g @wonderwhy-er/desktop-commander@latest
```

MCPクライアント設定経由で起動している場合は、次を使用してください：

```json
["-y", "@wonderwhy-er/desktop-commander@latest"]
```

その後、MCPサーバーを再起動し、次のコマンドで確認してください：

```bash
node --version
npm audit --omit=dev
```

Node.js **22.12以降** が必要です。アップグレードするまでは、無制限のシステムアクセスを許可することを避けるため、ChatGPT/MCP設定から desktop-commander を無効化または削除してください。

Question 5

Windows 上で Desktop Commander の read_file を実行した後に、os.replace() や fs.rename() が 'PermissionError: WinError 5' (ERROR_ACCESS_DENIED) で失敗するのはなぜですか？

Accepted Answer

原因: Desktop Commander の `read_file` は、行数の上限で読み取りが早期に打ち切られるたびにファイルハンドルをリークします。`readFromStartWithReadline` は readline ループから抜け出して `rl.close()` を呼び出しますが、`readline.Interface.close()` は基盤となる `fs.createReadStream` を閉じないため、Node プロセスはサーバーが終了するまでファイルを開いたまま保持します。その結果、Windows は他のプロセスからのアトミックな名前変更による置き換え(`os.replace()`、`fs.rename()`、`File.Move(...,true)`、MOVEFILE_REPLACE_EXISTING を指定した `MoveFileEx`)を WinError 5 / EPERM で拒否します。

発生条件(0.2.46–0.2.52 で確認済み、0.3.0 で再発): リークは、EOF まで読み切るのではなく `break` に到達した場合にのみ発生します。例: 5行のファイルを `length=5` で読み取った場合(または1200行のファイルにデフォルトの1000行制限が適用された場合)はハンドルがリークしますが、同じファイルを `length=6` で読み取った場合はリークしません。ロックの保持者は Windows Restart Manager で確認できます(Desktop Commander の node.exe を探してください)。

回避策:
1. 既存のロックを解放する: Desktop Commander / Claude Desktop を完全に再起動します(正常なシャットダウンによりリークしたハンドルがすべて解放され、その後ファイルは通常どおり移動/置き換えできます)。
2. 新たなリークの発生を避ける: `read_file` を呼び出す際は、ファイルの総行数より大きい `length` を渡して、ストリームが EOF まで読み切り、正常にクローズされるようにしてください。デフォルトの1000行制限で大きなファイルを部分的に読み取ることは避けてください。
3. コード修正(コントリビューター向け): 4か所すべての readline 呼び出し箇所で入力 ReadStream を捕捉し、`finally` ブロック内で `stream.destroy()` を呼び出し、return する前にストリームの `close` イベントを待機してください。また、入力ストリームと readline インターフェースの両方で error/abort イベントも処理してください。

DesktopCommanderMCP

概要

README プレビュー

FAQ (5)

同类型项目

vscode

FreeDomain

stable-diffusion-webui

paperclip