Author

claudehowto

zsh で command not found や dyld: Symbol not found が出るときにまず見ること

手元にある issue には、少なくとも 2 つの別パターンがありました。ひとつは macOS 13.x で claude の起動そのものが落ちるケース、もうひとつは zsh の起動時に余計なエラーが毎回出るケースです。見た目は似ていますが、症状の場所が違います。

[#69928](https://github.com/anthropics/claude-code/issues/69928) では、インストール直後に次のような出力が出ています。

Setting up Claude Code...
dyld: Symbol not found: __ZTVNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEEE
  Referenced from: /Users/emmaborowski/.claude/downloads/claude-2.1.185-darwin-x64 (which was built for Mac OS X 13.0)
  Expected in: /usr/lib/libc++.1.dylib

さらに、その直前に claude を実行しても見つからず、

zsh: command not found: claude

となっています。これは、少なくともこの報告では、インストール処理の途中で落ちているために claude コマンドが使える状態になっていないように見えます。原因の断定はできませんが、報告本文にある通り、macOS 13.x と claude-2.1.185-darwin-x64 の組み合わせで dyld のシンボル解決に失敗しています。

一方、[#62183](https://github.com/anthropics/claude-code/issues/62183) は、Claude Code を VS Code 拡張として使うと Bash tool が zsh のサブシェルを起動し、そのたびに zsh 側のエラーが出るという報告です。本文では「コマンド自体は実行できるが、毎回うるさい」とされており、致命的というよりノイズに近い症状です。エラー例はこうです。

zsh:19: permission denied: /run/current-system/sw
zsh:23: no such file or directory: Support/Code/CachedData/8b640eef5a6c6089c029249d48efa5c99adf7d51
zsh: command not found: 36:ln=35:so=32:pi=33:ex=31:bd=34
zsh: command not found: 46:cd=34
zsh:33: no such file or directory: Support/Code/1.11-main.sock
zsh: command not found: -R

この issue のコメントでは、原因候補として「値にスペースを含む環境変数」や PATH が挙がっています。特に、PATH にスペースを含む項目があると、Bash tool の各コマンドの前に 1 行ずつ余計なエラーが出る、という再現報告がありました。コメント中では、子シェルの実行コマンドを確認したところ、PATH の値が -c の文字列にそのまま埋め込まれているように見える、という診断も書かれています。ただし、ここはコメントベースの情報なので、実際の自分の環境で同じであるかは確認が必要です。

この 2 件を並べて見ると、まず切り分けたいのは「起動時に dyld で落ちているのか」「zsh が毎回余計なエラーを出しているだけなのか」です。前者なら claude 自体が立ち上がらないので、インストール段階の問題を疑うのが自然です。後者なら、コマンド実行は通るのに zsh のメッセージだけが前に出る、という形になります。

今回の issue 群だけから言えるのはここまでです。[#69928](https://github.com/anthropics/claude-code/issues/69928) は macOS 13.x での dyld エラー、[#62183](https://github.com/anthropics/claude-code/issues/62183) は zsh サブシェルの起動時ノイズ、というふうに分けて読むのがよさそうです。どちらも閉じられてはいますが、本文からは再発防止の恒久策までは読み取れませんでした。

検証環境

OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-09-25T08:51:49+09:00

参照した Issue（anthropics/claude-code）: #69928, #62183

同じ著者の記事

claude が `command not found` になるのに、インストール自体は成功したように見える

新しいターミナルを開くたびに `claude` が見つからない。けれど、インストールの途中では成功メッセージが出ている。そんなときは、まずこの2つの issue が自分の症状に近いかを見たほうがいいです。 1つは、`install.sh` か `claude install` が「launcher と shell integration を設定した」と表示するのに、`~/.local/bin` を `PATH` に追加していないケースです。報告は macOS / zsh ですが、症状そのものは「入ったはずなのにシェルから見えない」です。該当 issue は [#76060](https://github.com/anthropics/claude-code/issues/76060) です。 もう1つは、自動更新の途中で optional dependency のダウンロードが詰まり、更新は成功扱いで終わるのに、次の起動で `claude: command not found` になるケースです。こちらは [#72690](https://github.com/anthropics/c

papoo.work

Claude Code が exit code 134 で落ちるときに、まず見るべき差分

自分のケースかどうかを先に切り分けるなら、まず「Claude Desktop に付属している Claude Code だけが落ちるのか」を確認したほうが早いです。issue には、同じ macOS 12 系の機械で、Desktop app の bundled build だけが起動直後に死に、standalone CLI は動いた例がありました。つまり、少なくとも報告上は「macOS が古いから全部だめ」という話ではありません。 issue に出ているエラーは、どれも「起動直後に dyld がシンボルを見つけられず abort する」という形です。たとえば #91381 は `_DNSServiceGetAddrInfoEx`、#75206 は libc++ の symbol not found、#91550 も `_DNSServiceGetAddrInfoEx` でした。見た目は違っても、どれも `exit code 134` に落ち着いています。 #75206](https://github.com/anthropics/claude-code/issues/75206) では、

papoo.work

`disabled after repeated failures · restart to retry` が出るときに見えていること

まず、この症状に当てはまるかどうかを先に切り分けます。今回の issue では、Remote Control が失敗を重ねたあとに無効化され、再起動しないと試し直せないように見える、という報告が 2 件あります。`[#78364](https://github.com/anthropics/claude-code/issues/78364)` では「3 回の一時的な失敗」で Remote Control が静かに恒久無効化される、と書かれています。`[#87269](https://github.com/anthropics/claude-code/issues/87269)` では、起動時に Remote Control の開始に失敗すると、そのセッション中は回復せず、再接続経路もないと報告されています。 今回の手元の確認では、Claude Code は Remote Control 機能自体を案内していますが、同時に複数インストールの存在も出ています。実際の出力は次のとおりです。 ```text $ claude --version 2.1.207 (Claude Code) ``

papoo.work

exit code 143 が出るときにまず疑うこと

`exit code 143` は、この材料だけを見ると「Claude Code のプロセスが SIGTERM で終わった」系の症状として扱うのが自然です。そう見てよさそうな根拠は、issue 側で実際に `SIGTERM (exit 143)` と書かれていることです。たとえば [#87658](https://github.com/anthropics/claude-code/issues/87658) では、Claude desktop アプリ内で 2 つ目の local Code セッションを始めると、先に動いていた CLI プロセスが SIGTERM で終了すると報告されています。 ただし、同じ `exit code 143` でも原因はひとつではありません。#76293 では、対話中の Claude Code が Bash tool の成功後に何のエラー表示もなく shell に戻り、あとでセッションを再開できたと書かれています。こちらの報告では、約 3 日動作していたこと、永続化された transcript が約 4.6 MB だったこと、request metadata

papoo.work

ENOSPC が出ても本当にディスクが空なのか、まずここを見たい

この症状は、Claude Code が `ENOSPC` とともに「temp filesystem is full (0MB free)」「Command output was lost...」のような文言を出すのに、実際には空き容量があるケースとして報告されています。少なくとも issue 上では、ディスク不足そのものではない例が 2 件ありました。ひとつは [#65086](https://github.com/anthropics/claude-code/issues/65086) で、`stdout` も `stderr` も出さずに非 0 終了した subprocess に対して、偽の `ENOSPC` が出たという報告です。もうひとつは [#65251](https://github.com/anthropics/claude-code/issues/65251) で、macOS 上で Bash tool の出力取得が失敗し、`/private/tmp/claude-501/.../tasks` の temp filesystem が満杯だと誤判定されたという報告でした。

papoo.work

`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出たときに、まず疑うこと

この症状は、少なくとも報告ベースでは 2 件ありました。どちらも同じエラー文字列で、`itemKeys` と `messages` の件数がずれていると読めます。手元で確認できるのは issue の記載だけで、解決策までは出ていません。現時点では未解決のバグとして扱うのが安全です。 最初に見るべきなのは、「表示だけの問題か」「会話の整合性まで壊れているか」です。[#95627](https://github.com/anthropics/claude-code/issues/95627) では、ユーザーが送っていないテキストがアシスタント側には届いているのに、`.jsonl` と `/export` には残っていませんでした。つまり、単なる見た目の乱れではなく、コンテキストの取り扱い自体がずれている可能性があります。 報告されているエラーは、どちらの issue でも同じ形です。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=112 messages=111 r

papoo.work

`Failed to deserialize params.clip.scale - BINDINGS: mandator` が出るときにまず確認したいこと

この症状は、`claude-in-chrome` の `computer` で `action: screenshot` や `action: zoom` を呼んだときに、`params.clip.scale` のデシリアライズ失敗として返ってきます。報告されている issue は [#83960](https://github.com/anthropics/claude-code/issues/83960) と [#90181](https://github.com/anthropics/claude-code/issues/90181) です。どちらも、実行すると `Failed to deserialize params.clip.scale - BINDINGS: mandatory field missing at position 65` が出ています。 まず切り分けたいのは、「自分も同じエラー文字列を見ているか」と「それが screenshot / zoom の呼び出しに限って起きているか」です。issue #83960 では、拡張機能のペアリング自体はできていて、`ta

papoo.work

`invalid_request_error\` が出るときにまず見る場所

この症状クラスタに含まれる 2 件の issue は、見え方は違いますが、どちらも「リクエストの中身が大きすぎる／重なりすぎる」方向の問題として読めます。 ただし、実際に `invalid_request_error\` というエラー文字列が本文中にそのまま出ている issue は、今回渡された情報の中にはありません。そこは断定できません。検索用の文字列としてタイトルには入れていますが、報告内容ベースで確認できるのは以下です。 まず、[ #37793 ](https://github.com/anthropics/claude-code/issues/37793) では、MCP サーバーを多数ユーザー側で設定していると、サブエージェントが開始直後に `prompt is too long: 209117 tokens > 200000 maximum` で失敗すると報告されています。しかも TUI には `Done (0 tool uses · 0 tokens · 44s)` と出て、ユーザーにはエラーが見えにくかった、とあります。 この報告だけを見ると、サブエージェントに渡るプロン

papoo.work

`Auto-update failed · Run claude doctor` が繰り返し出るときに見るところ

この症状でまず切り分けたいのは、本当に更新に失敗しているのか、それとも更新がないのに同じ通知だけが出続けているのかです。報告されている #96038 では、Wi‑Fi を切っただけで `Auto-update failed · Run claude doctor` が繰り返し表示され、しかも「更新がないのに」起きていると書かれています。つまり、少なくともこの issue では、実際の更新作業そのものというより、ネットワーク断をきっかけにした通知の再発が問題になっています。[#96038](https://github.com/anthropics/claude-code/issues/96038) 同じ `Auto-update failed · Run claude doctor` という表示でも、#78650 のほうは少し様子が違います。こちらは macOS の深いスリープからの復帰後に、複数の Claude Code セッションがほぼ同時に segfault で落ちたという報告で、本文では Bun の GC と socket finalizer、`SIGSEGV

papoo.work

TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときにまず見ること

この症状は、Claude Code の内部エラーとして `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回確認できた issue は 2 件で、どちらも open のままで、解決済みはありません。少なくとも提供された材料だけを見る限り、「これを入れれば直る」という確立した手順はまだありません。 自分のケースかどうかを見分けるなら、まずエラー文の形を確認します。今回の issue では、どちらも同じ系統の文言が出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=562 messages=558 range=[502,558)) at Ta0 (B:/~BUN/root/cli:23248:33899) at Rig (B:/~BUN/root/cli:23248:26870) ``` 別の報告では、値が少し違いますが、同じく `ite

papoo.work