ハーネスエンジニアなら知っておきたい Cowork でぶっ壊れる Claude Code Plugin の罠 が、Claude Code Plugin を書く実務者の間で話題になっている。CLI で動く plugin を Cowork でそのまま実行すると、SessionStart hook が無音で失敗する、skill frontmatter hook が発火しない、${CLAUDE_PLUGIN_ROOT} が VM に存在しないパスに展開される——probe ベースの調査で明らかになった 7 つの構造的な差分をまとめた記事だ。
記事が際立つのは、これらを「単発のバグ」ではなく「Cowork のアーキテクチャから導かれる構造的な性質」と整理した点にある。
ホスト/VM の二段構成という設計原理
Cowork は Claude Desktop（ホスト OS）とローカル Linux VM の二段構成で動く。plugin-level hook はホスト OS 側で実行され、skill body の bash subprocess は VM 内で動く。この分断は、/tmp に書いたファイルが片側から見えない、という形で開発者の目の前に現れる。
CLI では自然に成立していた「hook → bash の一貫したファイルシステム参照」が、Cowork では構造的に機能しない。これはパッチを待てばいい類の問題ではなく、設計として前提に置くべきアーキテクチャの差分だ。
構造を知ると、何が変わるか
この分断を事前に知らなければ、CLI 向けに書いた plugin を Cowork に移植するたびに後付けの修正が積み重なっていく。一方、構造を先に把握した開発者は、始めから「実行環境に依存しない設計」を選択できる。
hostname によるホスト/VM 判別、環境依存パスの排除、hook と bash subprocess の分離設計——こうした判断を最初から組み込んだ plugin は、CLI でも Cowork でも一貫して動く。著者が公開している probe と再現コードは、この設計判断を実証的に支える素材でもある。
落とし穴の先に見えるもの
Cowork の登場は、Claude Code が単一 CLI ツールから複数の実行環境を持つプラットフォームへと広がりつつあることを意味する。環境が増えるほど、環境非依存の設計という発想の価値は高まる。
「壊れる理由を理解する」ことは、単なる問題回避にとどまらない。それは、プラットフォームの進化に先回りして適応するための設計基準を固める出発点になる。
関連記事
- AIの急速な普及に対して労働者の経済的安定は政策支援で維持できるのか？
- Reachy Mini goes fully local
- AR/AIメガネはスマートフォンに置き換わる次世代インターフェースになるのか？
参考文献
コメント