4.8.1 — ターミナルを開けなくなるサーバーを直す

2026-08-10 にリリースされた 4.8.1 のスナップショットです。 アプリが進むにつれて内容は古くなりますが、それは想定どおりです。常に最新の情報は、各セクションからリンクしている本編ガイドを見てください。

npx mulmoterminal@latest

このリリースで設定することは何もありません。 主役は、サーバーを数日動かしたあとにだけ現れるバグで、恩恵を受ける方法は「このバージョンで起動し直す」ことだけです。残りは 4.8.0 で始まったフォルダ単位の collection 対応の続きです。

サーバーが新しいターミナルを開けなくなっていた方へ

読むべきはここです。

症状。 連続稼働が数日を超えると、新しいセッションが一切起動しなくなります。セルにはこう出ます。

[forkpty: Device not configured]

アプリ側では何をしても直りません。セッションを閉じても空きは増えず、すでに動いているセッションはそのまま使えます。だから「リソースの問題」ではなく「表示の不具合」に見えます。サーバーを再起動すると完全に解消し、そしてまた数日後に戻ってきます。

何が起きていたか。 MulmoTerminal が開くターミナルは 1 つ 1 つが擬似端末（pseudo-terminal）で、 macOS はマシン全体で使える本数を固定しています（既定で 511 本）。擬似端末を起こすために使っている node-pty が、macOS で 1 ターミナルにつき 2 つを返し損ねていました — 開いたまま閉じないファイルディスクリプタが 1 つ、そして確保したまま捨てられる擬似端末が丸ごと 1 本です。セッションを起こすたびに 1 本ずつ取るので、数は増える一方でした。

速度を決めていたのはレート制限ゲージです。ブラウザが見ている間、10 分ごとに隠れた Claude セッションを起こすので、グリッドを開いたまま放置したマシンは誰も操作していなくても着実に増えていきました。ある報告では 5 日で 511 本中 498 本に到達しています。

修正。 MulmoTerminal は node-pty 1.2.0-beta.15 を使うようになり、両方とも閉じられます。これは推測ではなく実サーバーで計測しました。旧バージョンではターミナルを 6 本開いて閉じると擬似端末が 6 本握られたまま残り、新バージョンでは 0 本でした。

sysctl kern.tty.ptmx_max で上限を上げるのは修正ではありません。発生する日を先送りするだけです。

修正が入っているかの確認方法

やらなくても構いませんが、影響を受けていた方には見ていて気持ちのいい確認です。

MulmoTerminal を動かした状態で、サーバープロセスが握っている擬似端末を数えます。

pgrep -f "mulmoterminal|server/index" | head
lsof -p <その pid> | grep -c /dev/ptmx

一度実行し、しばらくアプリを使って（セルをいくつか開いて閉じて）もう一度実行します。実際に開いているターミナルの本数に追従し、閉じれば減るはずです。このリリース以前は増える一方でした。

lsof を使いたくない場合の正直な答えは、「数日後に何も起きないことで気づく」です。

再起動が必要で、npx は代わりにやってくれません。 動いているサーバーはディスク上が何であろうと古いライブラリをメモリに載せたままです。止めて、起動し直してください。

プロジェクトフォルダの collection がスケジュール更新されるようになりました

4.8.0 は Collections ペインを出したうえで、「まだプロジェクトフォルダにデータを移さないでほしい」とお願いしていました。4 つ挙げた理由のうち 2 つが解消しました。

スケジュール更新がプロジェクト単位で動きます。 4.8.0 では、エージェントを起こして更新する collection をプロジェクトフォルダでスケジュールすることがそもそもできませんでした。ワーカーがワークスペース側で起動してしまい、プロジェクトのレコードをワークスペースの同名 collection に書き込んでしまうためです。共有ライブラリがルートをワーカーの作業ディレクトリまで運ぶようになったので、プロジェクトに設定した更新はそのプロジェクトに着地します。

カレンダー同期は意図的にワークスペース専用のままです。Google の認可はフォルダではなくユーザーに紐づくので、プロジェクト単位の同期には「どのアカウントか」という問いにフォルダ単位で答える仕組みが必要で、それはまだありません。

カードは作られたプロジェクトに固定されます。 これまでは、プロジェクト A を見ながら作ったカードが、アプリを別の場所に移した途端にプロジェクト B のレコードを表示していました。同じ slug、同じタイトル、違う行、しかも画面上にその手がかりが何もない状態です。カードは自分のプロジェクト束縛を持つようになりました。

collection とは何か、エージェントがどう書くかは、本編ガイドの機能の概要を参照してください。

まだ準備できていないこと

4.8.0 で挙げた 4 つのうち 2 つは残っているので、お願いは変わりません。collection は当面ワークスペースに置いてください。

スマホからはまだプロジェクトの collection に届きません。 ホスト側はどのプロジェクトが存在するかを返せるようになり（listCollectionProjects）、プロジェクトを取るコマンドはすべて解決できますが、スマホ側にピッカーが無いのでワークスペースしか見えません。
ペインはまだ実ブラウザでの確認を通していません（全画面オーバーレイは通っています）。

すでにワークスペースにある collection には、いずれも影響しません。

その他の変更

collection を clone できなくしたとき、エージェントに伝わるようになりました。 可搬性チェックは 4.7.6 からルートとボタンを持っていましたが、どちらも人が押そうと思いつく必要がありました。 putSchema が成功したとき、その判定をスキーマを書いたエージェント自身に返します — 保存方式を選び、いままさにファイルを開いているのはそのエージェントです。問題が無ければ何も言いません。
フィードの無視されたレコードは blocker ではなく warning になりました。 実際のワークスペースでチェックを回すと、管理ワークスペースが意図的に feeds/ を無視しているせいで 3 つのフィード collection が「clone 不可」と報告されました。フィードのレコードは clone 側が取り直せるキャッシュなので、失うのはデータではなく更新の手間だけです。通常の collection は blocker のままです — そちらはレコードそのものがデータだからです。
保存したディレクトリがすぐ監視されるようになりました。 作業ディレクトリを追加してから collection が監視されるまで 60 秒の突き合わせを待つ必要があり、それが「保留」ではなく「壊れている」ように見えていました。
ヘッダーのチップがディレクトリの文字色に追従します。 彩度の高い headerColor を設定すると、 model/context バッジと usage チップだけがテーマの薄い文字色のままで読めなくなることがありました。隣の path とタイトルは正しく追従していました。
ツールバーの Collections の入口が、ペインと同じアイコンになりました。 collection を開ける 2 か所が同じものに見えるようになります。
@mulmoclaude/core が 3.2.0 になりました。 MulmoTerminal と MulmoClaude が共有しているライブラリです。

入っているかの確認

MulmoTerminal を再起動します（npx mulmoterminal@latest）。
ツールバーの歯車から Settings を開きます。バージョンはダイアログ最上部、Settings 見出しのすぐ下です。4.8.1 と表示されていれば入っています。

4.8.0 のままなら古いプロセスがまだ動いています。止めて起動し直してください。npx は動作中のサーバーのバージョンを差し替えてはくれません。今回はそれが普段以上に重要です — 擬似端末の修正は起動時に一度だけ読み込まれるネイティブライブラリの中にあります。

再起動そのものがうまくいかない場合ははじめかたを見てください。