Claude Codeが出すsudo launchctl limit maxfilesの案内を実行すると、Macのターミナルが全部起動しなくなる
Claude Code(内蔵Bun)がファイルディスクリプタ不足エラー時に出す`sudo launchctl limit maxfiles 2147483646`のヒント。実行するとmacOSのlogin処理が固まり、新規ターミナルが3分間ハングする。原因をGitHub Issue一次情報で追い、直し方と安全な設定値を整理した。
エンジニアのゆとです。
先に結論から書く。Claude Codeが時々出す「ファイルディスクリプタが足りないかもしれません」というヒントに従ってsudo launchctl limit maxfiles 2147483646を実行すると、次に開くターミナルが軒並み固まるようになる。Terminal.appでもGhosttyでも同じで、新しいウィンドウが真っ白のまま3分近く反応しない。しかも直そうとしてulimitを元に戻そうとしても、SIP(System Integrity Protection)に止められて下げられない。
自分はまだ実機で踏んでいないんだけど、2026年9月24日に報告されたIssueの内容がかなり具体的で、原因も再現条件も直し方もひと通り書いてあったので、先に記事にしておく。Claude Codeを常用してるMacユーザーなら誰でも踏む可能性のある案内文なので、実行する前に読んでおいた方がいい類のものだと思う。
何が起きるのか — 原因はClaude Codeが内蔵しているBunランタイム
Claude CodeはNode.jsではなくBunをランタイムに使っている。Bunにはファイルディスクリプタ(fd)の上限に引っかかったときに、こう案内するヒント機能が組み込まれている。
Number of file descriptors (ulimit -n) is too low.
Try `ulimit -n 2147483646` or `sudo launchctl limit maxfiles 2147483646`2147483646は32bit符号付き整数の最大値-1で、要するに「実質無制限」を意図した数字だ。Linuxならこの数字をulimit -nに渡してもだいたい何とかなる。ところがmacOSは事情が違う。
macOSのログイン処理(/usr/bin/login)は、新しいシェルを起動する前に「開いている可能性のあるファイルディスクリプタを全部閉じる」というループを回す。通常はこの上限がせいぜい256〜数千程度なので一瞬で終わる。だがlaunchctl limit maxfilesで上限を21億台まで引き上げてしまうと、このクローズループが21億回近く回ることになる。結果、Terminal.appやGhosttyで新しいウィンドウを開くたびに、ログインシェルが起動し終わるまで数分間CPUを100%使い切って固まる。
Issue報告者の実測値はこうだった。
| 状態 | launchctl limit maxfiles | kern.maxfiles | kern.maxfilesperproc | ターミナルの挙動 |
|---|---|---|---|---|
| コマンド実行後 | 2147483646 | 2147483646 | 2147483646 | 新規ウィンドウが約3分ハング |
| 再起動後 | 256 / unlimited | 122880 | 61440 | 即座に開く |
つまり症状が出るのは「そのコマンドを実行した後、再起動するまでの間」に限られる。逆に言えば、この状態を経験した人は必ず一度このコマンドを打っている。
なぜ自分で戻せないのか — SIPが介入する
上限を上げすぎたなら下げれば直りそうなものだけど、そう簡単にはいかない。System Integrity Protection(SIP)が有効なmacOSでは、launchctl limit maxfilesで一度引き上げた値を、同じセッション中にコマンドで下げる操作がブロックされる。試すとOperation not permittedのようなエラーが返ってきて、値はそのまま残り続ける。
Issue内で確認されている唯一の直し方は再起動だ。再起動するとlaunchdが起動時にデフォルト値(256/unlimited)で上限を再構築し直すので、コマンドを打つ前の状態に戻る。逆に言うと、再起動さえすれば必ず直るので、慌てて設定ファイルを漁ったりSIPを無効化したりする必要はない。
「ターミナルが固まった状態でどうやって再起動するのか」問題
ここで一つ引っかかるのが、「新規ターミナルが軒並みハングするなら、sudo rebootも打てないのでは」という疑問だ。これは大丈夫。固まるのはあくまで/usr/bin/loginを経由して新しいログインシェルを起動する経路であって、Finderやアップルメニューの「再起動」はこの経路を通らない。すでに開いていてまだ生きているターミナルウィンドウがあれば、そこからsudo shutdown -r nowを打ってもいい。新規ウィンドウを一切開かずに再起動できる手段さえ確保しておけば、パニックになる必要はない。
この案内自体がmacOS向けとしておかしい
そもそもの話として、Bunが出しているsudo launchctl limit maxfiles 2147483646という案内は、Linuxのfdエラー対処をmacOSにもそのまま流用したものだと考えられる。macOSのハード上限は実測でも1万〜10万台のオーダーで頭打ちになる設計になっていて、21億という値を要求すること自体に実用上の意味がない。
このIssueの報告者は、Bun側の該当箇所としてoven-sh/bun#37337（根本原因の報告）とoven-sh/bun#37339（上限値を現実的な範囲に収めるPR、2026年9月24日時点でまだオープン）を挙げている。つまりBun本体側の修正はまだ取り込まれておらず、Claude CodeがバンドルしているBunにもこのヒント文言がそのまま残っている状態だ。この記事を書いている時点でこのIssueはコメント0件・オープンのままなので、直るまではユーザー側が「その案内は実行しない」と覚えておくしかない。
すでに実行してしまった場合の手順
- 新しいターミナルウィンドウは開かない(開いても3分ほど待てば起動はする)
- すでに開いている生きたターミナルがあれば、そこから
sudo shutdown -r nowまたはsudo reboot - 生きたターミナルが一つもない場合は、Appleメニュー(画面左上の)→「再起動」を選ぶ
- 再起動後、以下のコマンドで元に戻ったか確認する
launchctl limit maxfiles
# → 256 unlimited のように出れば正常
sysctl kern.maxfiles kern.maxfilesperproc
# → kern.maxfiles: 122880 / kern.maxfilesperproc: 61440 程度なら正常fdエラー自体への対処 — 上限を21億にしない安全な範囲
Bunのヒントが出た本来の原因(fd不足)自体は無視しない方がいい。ただし上げる数値は現実的な範囲に収める。
# 一時的に上げる場合(再起動でリセットされる)
sudo launchctl limit maxfiles 65536 524288恒久的に上げておきたい場合は、コマンド一発ではなくLaunchDaemonの設定ファイルを使うのがmacOSの正攻法になる。
sudo tee /Library/LaunchDaemons/limit.maxfiles.plist > /dev/null <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>limit.maxfiles</string>
<key>ProgramArguments</key>
<array>
<string>launchctl</string>
<string>limit</string>
<string>maxfiles</string>
<string>65536</string>
<string>524288</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>
EOF
sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
sudo chmod 644 /Library/LaunchDaemons/limit.maxfiles.plist設定を反映するには再起動が必要になる。65536という値はfd不足エラーで詰まっていたケースならほぼ足りるはずで、少なくとも21億のような非現実的な値にする理由はどこにもない。
根本原因のfd不足そのものを疑う場合
Claude Codeまわりでfdが枯渇する経路は、今回のBunヒント以外にもいくつか報告されている。長時間セッションでファイルを開きっぱなしにするプロセスが残っていないか、lsofで自分の環境を先に確認しておくと、そもそも上限を上げる必要があったのかどうかの切り分けができる。
# 自分のユーザーが開いているfd数の合計を確認
lsof -u $(whoami) | wc -l
# claudeプロセス単体で開いているfdを確認
lsof -c claude 2>/dev/null | wc -l数千〜1万程度で収まっているなら、デフォルトの上限(256)が単純に低すぎるだけの話で、65536程度への引き上げで十分足りる。一方で数の増え方が時間とともに際限なく伸び続けているなら、それはfd上限の問題ではなく、どこかでfdを閉じ忘れているリーク側の問題という切り分けになる。
FAQ
再起動せずに直す方法はない?
Issue内で確認されている範囲では、SIPが有効な状態だとlaunchctl limit maxfilesで一度引き上げた値をコマンドで下げる操作自体がブロックされる。再起動以外の確実な手段は報告されていない。SIPを無効化すれば理屈上は可能かもしれないが、リスクに見合わないのでおすすめしない。
Terminal.app以外でも起きる?
起きる。報告ではGhostty 1.3.1とTerminal.appの両方で同じ挙動が確認されている。/usr/bin/loginを経由してログインシェルを起動する仕組み自体の問題なので、特定のターミナルアプリに限った話ではない。
VS CodeやCursorの統合ターミナルは影響を受ける?
その可能性が高い。統合ターミナルも内部的には同じログインシェル起動の仕組みを使っていることが多いので、新しいターミナルパネルを開くたびに同様のハングが起きうる。心当たりがあればlaunchctl limit maxfilesの現在値を先に確認しておくといい。
このヒントは今のClaude Codeでも出る?
Issue報告時点(Claude Code 2.1.281)ではヒント文言がバイナリ内に残っていることが確認されている。上流のBun側修正(PR #37339)がまだマージされていないため、この記事を書いている時点では出続けている可能性が高い。バージョンアップ後はCHANGELOGを確認しておくと安心できる。
Bunが出すエラーメッセージの案内を素直に実行しただけで、macOS標準のターミナルアプリが軒並み使えなくなるというのは、原因を知らないと相当焦る類の症状だと思う。幸い直し方自体はシンプルで、再起動さえすれば元通りになる。ただ「なぜ直るのか」を知らないまま再起動だけ試すと、次にfdエラーが出たときにまた同じ案内に従ってしまいかねないので、上げる数値は21億ではなく65536程度に留めておくのが無難だ。
関連記事
- Claude CodeがMacで理由もなく強制終了する「Malicious Script Blocked」問題を追った
- Claude Codeのサンドボックス、bwrapの一時ディレクトリが消えずに/tmpに溜まり続ける不具合を追った
- Claude CodeのEnterWorktreeでBashが全滅——bwrap「Read-only file system」の正体と回避策
