Zed起動時にClaude Code連携が失敗する課題の解決策
はじめに
-
前回、Windows + Zedで軽量にClaude Codeを使う環境を作ってみたという記事で、ZedのAgent Client Protocol(ACP)を使ってClaude Codeを統合する手順を紹介しました。その後しばらく使っていたのですが、時間が経ってから再度Zedを開いたり、Zed自体を再起動したりすると、Claude Agentのスレッドがうまく起動しなくなる現象に何度か遭遇しました。「Failed to Launch」というエラーパネルが出て、Agentが立ち上がらないのです。
-
しかも厄介なことに、毎回同じエラーが出るわけではなく、試すたびに違うメッセージが出てきました。今回はこの原因を一つずつ潰していった記録と、最終的にたどり着いた安定する構成をまとめます。
前提
- OS: Windows (WSLは未使用)
- エディタ: Zed (https://zed.dev/)
- 前回の記事の手順で、Zed上にClaude Agent(ACP)を導入済み
症状
- ある日Zedを開くと、Agentパネルに以下のようなエラーが表示され、スレッドが起動しなくなりました。
Failed to Launch
Internal error: {
"details": "spawn EFTYPE"
}
- 設定(
~\AppData\Roaming\Zed\settings.json)を確認すると、初期導入時にZedが自動生成した内容は以下のようになっていました。
json
{
"agent_servers": {
"claude-acp": {
"default_config_options": {
"model": "claude-fable-5[1m]"
},
"type": "registry"
}
},
"icon_theme": {
"mode": "dark",
"light": "Zed (Default)",
"dark": "Zed (Default)"
},
"ui_font_size": 16,
"buffer_font_size": 15,
"theme": {
"mode": "dark",
"light": "One Light",
"dark": "One Dark"
}
}
"type": "registry"というのがポイントで、これはZedが起動のたびに、Zed自身が同梱しているNode.js/npmを使ってclaude-acpのアダプターパッケージを自動インストールしにいく方式です。つまり毎回ミニマムなnpm installが裏で走っている、ということになります。- Zedを再起動してもう一度試すと、今度は違うエラーに変わりました。
Failed to Launch
Server exited with status code: 1
npm error Invalid Version:
npm error A complete log of this run can be found in: C:\Users\niikawa\AppData\Local\Zed\node\node-v24.11.0-win64\cache\_logs
- ここで「Zedが自前で持っているnpmキャッシュが壊れているのでは」と当たりをつけ、キャッシュごと削除してみました。
PS C:\WINDOWS\system32> Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Zed\node"
- Zedを再起動すると、Zedは同梱Node.jsを再ダウンロードしてくれるのですが、それでもまた別のエラーで失敗しました。
Failed to Launch
Server exited with status code: 1
npm error code ECOMPROMISED
npm error Lock compromised
npm error A complete log of this run can be found in: C:\Users\niikawa\AppData\Local\Zed\node\node-v24.11.0-win-x64\cache\_logs\2026-07-26T06_12_42_879Z-debug-0.log
原因調査
- 3つとも別のエラーに見えますが、根っこは同じでした。原因は
"type": "registry"という仕組みそのものにあります。Zedはこの方式だと、起動のたびにnpm exec @agentclientprotocol/claude-agent-acpを実行し、依存パッケージ(@agentclientprotocol/sdk、@anthropic-ai/claude-agent-sdk、express、honoなど)を100個近くダウンロード・展開し直しています。この「毎回フルインストールし直す」構成自体が不安定さの温床になっていました。 - 決定的だったのは3つ目のエラーのログです。添付されたデバッグログ(
...debug-0.log)を確認すると、以下のスタックトレースが出ていました。
862 verbose stack Error: Lock compromised
862 verbose stack at AbortSignal.<anonymous> (C:\Users\niikawa\AppData\Local\Zed\node\node-v24.11.0-win-x64\node_modules\npm\node_modules\libnpmexec\lib\with-lock.js:52:30)
862 verbose stack at [nodejs.internal.kHybridDispatch] (node:internal/event_target:845:20)
862 verbose stack at AbortSignal.dispatchEvent (node:internal/event_target:778:26)
862 verbose stack at runAbort (node:internal/abort_controller:488:10)
862 verbose stack at abortSignal (node:internal/abort_controller:459:3)
862 verbose stack at AbortController.abort (node:internal/abort_controller:507:5)
862 verbose stack at Timeout.touchLock (C:\Users\niikawa\AppData\Local\Zed\node\node-v24.11.0-win-x64\node_modules\npm\node_modules\libnpmexec\lib\with-lock.js:161:18)
863 error code ECOMPROMISED
864 error Lock compromised
- npmの
libnpmexecは、npm exec実行中にロックファイルへ定期的に「触れる(touch)」ことで処理が生きていることを示す仕組みを持っています。そのタッチ処理が何らかの理由(ディスクI/Oの遅延や、常駐しているセキュリティソフトによるファイル書き込みへの割り込みなど)で間に合わないと、npmは「ロックが乗っ取られた(compromised)」と判断してインストールを強制中断します。 - 会社PCのような、EDR/ウイルス対策ソフトが常駐している環境では、大量のパッケージを一気に展開する処理がまさにこの割り込みの標的になりやすく、
spawn EFTYPEやnpm error Invalid Versionも、突き詰めればこの「毎回npm installし直す」構成の不安定さが別の形で表面化したものだったと考えられます。
対処: 事前インストール済みバイナリを直接呼ぶ構成に変更する
- 根本対策として、
"type": "registry"(毎回自動インストール)をやめ、"type": "custom"で事前に一度だけグローバルインストールしたバイナリを直接呼び出す構成に切り替えることにしました。これならZed起動時にnpmのロック機構自体が走らなくなります。
手順1: システムにNode.jsをインストールする
- このPCにはシステム全体で使えるNode.js/npmが入っていなかった(Zedが内部専用に同梱しているだけだった)ので、まずNode.js(LTS版)をインストールします。
powershell
winget install OpenJS.NodeJS.LTS
- これを実行すると、以下のようにmsstore側のソース検索でエラーになりました。
PS C:\WINDOWS\system32> winget install OpenJS.NodeJS.LTS
ソースの検索中に失敗しました: msstore
コマンドの実行中に予期しないエラーが発生しました:
0x8a15005e : サーバー証明書が、予期された値のいずれにも一致しませんでした。
作業ソースの中以下のパッケージが見つかりました。
続行するには、'--source' オプションを使用していずれかのパッケージを指定してください。
名前 ID ソース
--------------------------------------
Node.js (LTS) OpenJS.NodeJS.LTS winget
- 前回の記事でZedをインストールしたときと全く同じ現象です。
--source wingetを明示すれば回避できます。
powershell
winget install --source winget OpenJS.NodeJS.LTS
PS C:\WINDOWS\system32> winget install --source winget OpenJS.NodeJS.LTS
見つかりました Node.js (LTS) [OpenJS.NodeJS.LTS] バージョン 24.18.0
このアプリケーションは所有者からライセンス供与されます。
Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。
ダウンロード中 https://nodejs.org/dist/v24.18.0/node-v24.18.0-x64.msi
██████████████████████████████ 31.3 MB / 31.3 MB
インストーラーハッシュが正常に検証されました
パッケージのインストールを開始しています...
インストールが完了しました
- インストール直後の同じPowerShellウィンドウでは
nodeコマンドが認識されませんでした。PATHの変更はプロセス起動時に読み込まれるため、新しいPowerShellを開き直す必要があります。
PS C:\WINDOWS\system32> node -v
v24.18.0
PS C:\WINDOWS\system32> npm -v
11.16.0
- 無事に認識されました。
手順2: ACPアダプターをグローバルインストールする
- Zedに毎回インストールさせるのではなく、こちらで一度だけ
npm install -gしておきます。
powershell
npm install -g @agentclientprotocol/claude-agent-acp
PS C:\WINDOWS\system32> npm install -g @agentclientprotocol/claude-agent-acp
added 104 packages in 1m
32 packages are looking for funding
run `npm fund` for details
npm notice
npm notice New major version of npm available! 11.16.0 -> 12.0.1
npm notice Changelog: https://github.com/npm/cli/releases/tag/v12.0.1
npm notice To update run: npm install -g npm@12.0.1
npm notice
- インストールされた実行ファイル名を確認します。
powershell
where.exe claude-agent-acp
PS C:\WINDOWS\system32> where.exe claude-agent-acp
C:\Users\niikawa\AppData\Roaming\npm\claude-agent-acp
C:\Users\niikawa\AppData\Roaming\npm\claude-agent-acp.cmd
claude-agent-acpというコマンド名でPATHに登録されていることが確認できました。
手順3: settings.jsonを書き換える
"type": "registry"を"custom"に変更し、"command"に手順2で確認したコマンド名を指定します。ついでに、なぜか"claude-fable-5[1m]"という妙な値が入っていたモデル指定も、正しいモデルID"claude-sonnet-5"に直しました。
json
{
"agent_servers": {
"claude-acp": {
"type": "custom",
"command": "claude-agent-acp",
"args": [],
"default_config_options": {
"model": "claude-sonnet-5"
}
}
},
"icon_theme": {
"mode": "dark",
"light": "Zed (Default)",
"dark": "Zed (Default)"
},
"ui_font_size": 16,
"buffer_font_size": 15,
"theme": {
"mode": "dark",
"light": "One Light",
"dark": "One Dark"
}
}
- 保存してZedを再起動したところ、Agentパネルが問題なく起動するようになりました。
まとめ
- Zedの
"type": "registry"によるClaude Agent(ACP)連携は、起動のたびにnpmで依存パッケージをフルインストールし直す仕組みのため、環境(特に常駐セキュリティソフトが動く会社PCなど)によってはロック競合や実行時エラーで不安定になりやすい spawn EFTYPE、npm error Invalid Version、npm error code ECOMPROMISEDはいずれも表面上は別のエラーだが、根っこは同じ「毎回npm installし直す」構成の不安定さに起因していた- Node.jsをシステムにインストールし、ACPアダプター(
@agentclientprotocol/claude-agent-acp)をnpm install -gで一度だけ固定インストールしたうえで、Zedのagent_servers設定を"type": "custom"に切り替えて直接そのバイナリを呼ぶ構成にすることで、再発しなくなった - WindowsネイティブのままWSLを使わずに解決できたので、前回の「軽量構成」の方針も崩れずに済んだ