このエラーが出ているなら、少なくとも Claude Code 側では「送ろうとしたリクエストが大きすぎる」と判定されています。報告されている2件はいずれも同じ文字列で、#73908 は closed、#77419 は open です。現時点では、issue だけを見る限り「何がどのくらい大きかったのか」を外から確定できません。
実際の報告では、どちらもスタックの先頭に generate が出ています。引用するとこうです。
Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}
at generate (/$bunfs/root/src/entrypoints/cli.js:12:71094)
別の報告でも同じエラーで、位置だけが異なります。
Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}
at generate (/$bunfs/root/src/entrypoints/cli.js:40:48321)
at makeRequest (/$bunfs/root/src/entry...
ここから読み取れるのは、ユーザーの入力そのものだけでなく、会話履歴や付随情報を含めた送信内容が大きくなっている可能性がある、という点までです。ただし、どの要素が上限を超えたのかは、公開された issue 文面だけでは分かりません。
#73908 の報告では、セキュリティ機能を持つ基本的なアプリを作っていたところ、すべてのメッセージがフラグされるようになったと書かれています。そこで示されている不満は「モデルが拒否しているように見える」という点ですが、実際に出ているエラーは拒否理由の説明ではなく、413 の request too large です。したがって、この issue だけを根拠に「内容が危険だから止められた」とは言えません。
#77419 は、persistent memory に対してユーザーの指示を誤って書き込んだという別種の問題を訴えています。ここでも同じ 413 が報告されていますが、本文の主題はメモリ書き込みの誤りです。つまり、同じエラー文字列が出ていても、利用者が感じている症状は必ずしも同じではありません。
いま自分のケースかを見分けるなら、まずエラー文字列が完全に一致するかを確認します。少なくとも今回のクラスタでは、Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}} が共通です。さらに、generate を含む CLI のスタックが出ていれば、Claude Code 側の送信処理で失敗している可能性が高いです。逆に、別のエラーコードや別文言なら、このクラスタとは分けて考えたほうがよさそうです。
解決策については、今回渡された issue では確立した手順を確認できません。#73908 は close されていますが、提示されているコメントは「しばらく動きがないので閉じる。まだ有効なら新しい issue を開いてほしい」という内容だけで、回避方法は書かれていません。したがって、少なくともこの材料だけでは「これをやれば直る」とは書けません。
現時点で言える実務的な見方は、まず issue 番号付きで同じエラーが再現するかを確認し、再現するなら送信内容のどこかが大きくなっていないかを疑う、というところまでです。そこから先の切り分けは、実際の入力量や会話の積み上がりを見ないと進められません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-08-27T08:50:39+09:00