この症状に当てはまるかどうかは、かなりはっきりしています。Claude Cowork で mcp__workspace__bash を使ったときに、次のような文言が交互に出るケースです。
Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds).Workspace still starting. The isolated Linux environment is booting in the background (usually 10–30 seconds). Try again shortly.報告された issue では、これが既存セッションでも新規セッションでも続いていました。#76374 と、続報の #92008 がその例です。どちらも、隔離された Linux 環境が起動しないままタイムアウトする、という同じ症状です。
手元で確認できた出力は環境情報だけでした。症状そのものの再現ログは取れていないので、ここでは issue に出ている事実に絞って書きます。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-10T08:51:25+09:00
今回の issue 群で一貫しているのは、ファイル操作系のツールは動いているのに、mcp__workspace__bash だけが失敗している点です。つまり「Claude 全体が死んでいる」というより、隔離 Linux VM の起動部分に問題があるように見えます。特にコメントには、sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared というエラーが出ていたとあります。これは VM の接続層というより、起動時の共有マウント周辺で止まっている可能性を示す材料として挙がっています。ただし、これは issue コメントの記述であって、こちらで再確認できたわけではありません。
もうひとつ重要なのは、影響が単一端末に限られていないことです。Windows と Cowork desktop app の組み合わせでも、再起動後も続いたという報告がありましたし、別マシンでも同じだったというコメントもあります。なので、少なくともこの症状については「自分の PC 設定が壊れているだけ」とは言い切れません。
現時点で言えるのはここまでです。公開された報告の範囲では、根本解決に至った手順は確認できませんでした。mcp__workspace__bash のみ失敗し、ファイルツールは生きているなら、この issue 群と同じ状態にかなり近いと思われます。逆に、Workspace の起動に失敗していて別のツールまで広く落ちているなら、別障害の可能性もあります。
参照した issue は #76374、#92008 です。公開情報の範囲では、どちらも少なくとも記事執筆時点で「このエラーに対して確立した直し方」は見えていませんでした。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-10T08:51:25+09:00