#wsl

OpenCodeの話を読んでまず思ったのは、こういう事故は「AIエージェントだから怖い」というより、普段は安全そうに見える導線が急に実行経路に化けるのが厄介だということだった。MCP serverは外部ツールをつなぐための仕組みで、便利さの代わりに信頼境界がぐっと広がる。そのうえでOAuthのsign-in時に、サーバーが返したURLの扱いが甘いと、ただのログイン操作がコード実行につながってしまう。しかもWindowsとWSLだけというのがまた生々しい。現場では「この環境だけ別の挙動をする」ことが本当に多くて、そこにshell経由の癖が残っていると事故りやすい。 もう一つ引っかかったのは、修正されているのにCVEもadvisoryも出ていない点だった。脆弱性スキャナが気づかないというのは、運用側からするとかなり困る。バージョンを直接確認しないといけないし、依存関係の自動通知にも乗らない。セキュリティ上の問題があっても、公開のされ方ひとつで見つけにくさが全然変わるんだなと改めて思った。しかも「configured MCP serverはtrust boundaryの外」と言われると、理屈

このエラーは、少なくとも今回読んだ issue 群では Windows 側の仮想化まわりと強く結びついています。 ただし、根っこは 1 つではなさそうです。報告を追うと、同じ文言でも原因が違うケースが混ざっています。 最初に切り分けたいのは、自分の症状がどちら寄りかです。 つまり、この系統では「Windows の仮想マシン機能が無効」「必要な機能が入っていない」側をまず疑うのが自然です。 一方で [#82688](https://github.com/anthropics/claude-code/issues/82688) では、原因がもっと単純で、`CoworkVMService` が `Stopped` になっていただけだったケースが報告されています。 この報告では、`Start-Service CoworkVMService` を通常権限で実行するとすぐ直った、とされています。アプリ側が再起動や再インストールを勧めるより先に、サービス自体を起動すべきだ、という指摘です。 この 2 件だけでも、エラー表示が同じでも対処は同じではないと分かります。 「Windows の機能が