#nodejs

まず切り分けたいのは、これが「Claude Code の起動そのものに失敗している」のか、それとも「起動済みのセッションは生きているが、新しい spawn だけ落ちる」のかです。今回参照した issue には、似た見え方をする `spawn EBADF` が 2 件ありましたが、症状の出方は少し違います。 ただし、今回の見出しにある `EMFILE` そのものについては、渡された issue 文面には直接は出てきません。ここで実際に確認できるのは `EBADF` です。なので、少なくとも今回の一次情報だけでは「EMFILE の原因はこれだ」とは言えません。現時点では、spawn 周りの fd 関連障害として似た系統を疑うところまでです。 手元の検証環境では Node.js のバージョンが次でした。 ```text $ node --version v16.15.0 ``` 環境全体は次のとおりです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時

この症状は、Claude Code のフック実行時に `MODULE_NOT_FOUND` が出て、`session-state.cjs` を探しに行って失敗しているケースです。少なくとも issue [#54743](https://github.com/anthropics/claude-code/issues/54743) では、`PreToolUse:Bash`、`PreToolUse:Read`、`PostToolUse:Bash`、stop hook など複数の hook event で同じエラーが連発し、出力を埋め尽くすが、処理自体はブロックされないと報告されています。 手元で確認できた範囲では、`settings.json` のキー構造は次の状態でした。値は取れていませんが、少なくとも今回の検証環境では該当ファイルが見つかっていません。 ```text ~/.claude/settings.json: (存在しない) /mnt/vda5/git/papoo/newsbot_openai/.claude/settings.json: (存在しない) /mnt/vda5/g

同じようなLLM呼び出しを毎回APIに投げると、当然そのぶん課金される 著者は `llm-cacher` というNode.js向けライブラリを作り、LLMレスポンスのキャッシュを試した ふつうの「完全一致キャッシュ」だけでなく、意味が近いプロンプトをまとめる semantic caching も扱う storageは `memory` / `file` / `SQLite` / `Redis` / `DynamoDB` などを選べる streaming response もキャッシュできるようにしているのが地味にすごい OpenAIやAnthropicのSDKを直接使いながら、フレームワークに寄りかからず導入できるのが売り この記事の出発点はとてもシンプルです。 「AIに同じような質問を何度もしていたら、請求額が思ったより高くなった」 という話。 これ、かなりあるあるだと思います。 開発中って、つい同じプロンプトを何回も投げますよね。文言は少し違っても、やっていることはほぼ同じ。しかもLLMは1回ごとに課金される。つまり、テストを重ねるほどお金が溶けるわけです。 著者は

著者は npmで公開された922個のMCP server を一斉に起動し、`initialize` と `tools/list` を投げて挙動を調査した 359個は正常応答、残り 563個は15種類の失敗パターン に分かれた 最も多かった失敗は 起動時に外部APIへ接続しにいって、そのまま返答しない ケース 認証情報がないとツール一覧を出せない サーバーも多く、READMEだけでは実態が見えない Windows特有の落とし穴として、`npx.cmd` の扱いと UTF-8の文字化け が重要だった この記事は、MCP server を作る人にとってかなり実践的な「地雷マップ」になっている MCPは Model Context Protocol の略で、ざっくり言うと「AIアシスタントが外部ツールと会話するための共通規格」です。 たとえば、ファイル操作、Slack送信、Googleサービス連携、Stripe操作みたいな機能を、AIが安全に呼び出せるようにする仕組みだと思えばOKです。 この記事が面白いのは、そのMCP serverを