4.8.4 — 通知の本文と、端末の日本語

4.8.4（2026-08-15 リリース）時点のスナップショットです。 アプリが進めば内容は古くなります。それは想定どおりで、常に最新なのは各節からリンクしている本編のガイドです。

npx mulmoterminal@latest

設定は何も要りません。 直したものだけの版です。この手引きは「何が壊れていたか」と「自分の手元で直ったことをどう確かめるか」を書きます。

スマホの通知に、自分が書いたプロンプトが出ていた

これまで。 通知を開くと、本文が直前に自分が入力したプロンプトそのものになっていることがありました。完了（✅）でも入力待ち（❓）でも起こります。自分が書いた文章を読み返しても、そのターンが何をしたのかは分かりません。

なぜ起きていたか。 本文はエージェントの返答から作りますが、それをトランスクリプトのファイルから読み直していました。読めなかったときの最後の逃げ道が「直前のプロンプト」だったのです。読めない場面は実際にあります — ESC で止めたターン、ツールを呼んだだけで終わったターン。

とくに /clear を使った人は毎回そうなっていました。 /clear の後、Claude は別のファイルに書き始めるので、こちらが持っているファイルは終わった会話のまま凍結されます。凍結された印はその後も消えないので、そのセッションの以降すべての完了通知が逃げ道に落ちていました。

これから。 返答は、ターンの終了を告げるフック自身が持っている値から取ります。ファイルを読み直さないので、書き込みとの競合も、/clear の凍結も関係ありません。そして 逃げ道からプロンプトを外しました — どの経路でも、自分の書いた文章が本文になることはもうありません。

本文の決まり方は次のとおりです。

通知	本文
完了（✅）	そのターンの返答。取れないときはセッションのタイトル、それも無ければ「タスクが完了しました」
入力待ち（❓）	エージェントが聞いていること。無ければ「入力待ちです」

効いたかどうかの確かめ方。 スマホの通知を on にした状態（通知の設定）でセルを 1 ターン回し、届いた通知の本文を見てください。返答の書き出しになっていれば効いています。 /clear を使ったセッションでも同じです。中断したターンでは「タスクが完了しました」になりますが、これは正しい動作です — そのターンには報告する返答がありません。

端末の日本語が `_` の連続になっていた

これまで。 エージェントの出力の日本語が、__________ のようにアンダースコアの並びになることがありました。罫線（─│）と · だけは正しく見えるので、フォントの問題に見えていました。

なぜ起きていたか。 フォントでもレンダラでもなく、tmux がその文字を書き出す瞬間の置換 でした。tmux はクライアントのロケール（LC_ALL / LC_CTYPE / LANG）に UTF-8 の名前が見つからないと、代替の無い文字をセル 1 つにつき _ 1 個へ置き換えます。全角は幅 2 なので 1 文字が __ になります。GUI から起動したプロセスはロケール変数を一つも持たないことがあり（このマシンでも launchctl getenv LANG は空でした）、そこに当たっていました。

これから。 tmux クライアントを UTF-8 に固定しました。出力の読み手はこちらの xterm.js で、これは常に UTF-8 なので、これは端末の推測ではなく事実です。加えて macOS でロケール名が一つも無いときだけ LANG=en_US.UTF-8 を補います。すでに LANG=ja_JP.UTF-8 などが設定されている環境は変えません。

効いたかどうかの確かめ方。 _ の置換は tmux クライアント側なので、既存のセッションでも次に開いたときから直ります。エージェントに日本語を出させてください。まだ _ になるなら、それは別の原因です — うまくいかないときを見てください。

ロケール名を補うほうはセッションを作るときにだけ効くので、すでに動いているプロセスには届きません。そちらが要るとき（ncurses の TUI や Python の出力が ASCII 扱いになるとき）は、新しいセッションで開き直してください。

共有アプリ: publish が案内する URL が開けなかった

アプリを公開すると、publish は訪問者に渡すアドレスを返します。それが /{名前} になっていましたが、公開ページがあるのは /a/{名前} です。著者はその文字列をそのまま人に渡すので、これは読みにくいメッセージではなく開かない URL でした。

名簿の人・参加者のページのアドレスも、/m/{名前} というプレースホルダのまま印字されていたのを、分かっている名前で埋めるようにしました。参加者のページに至っては、これまでアドレスを一切言っていませんでした。

確かめ方は、次に公開したときに返るアドレスを実際に開くことです。

共有アプリの公開ビュー: Windows でリンクの拒否が効いていなかった

公開ビューが読むファイルは、シンボリックリンクをたどらないように開いています。その防御が O_NOFOLLOW という一つのフラグに乗っていたのですが、Windows にこのフラグは存在しません。存在しない値は 0 として扱われるため、防御はエラーも警告も出さずに素の読み込みへ劣化していました。

Windows で共有アプリの公開ビューを使っていた場合のみ影響します。設定の変更はありません。

直ったものの一覧

直したもの	issue
通知の本文が自分のプロンプトになる	#1696
端末の日本語が `_` の連続になる	#1634
共有アプリの公開 URL が開けない	#1697
公開ビューのリンク拒否が Windows で効かない	#1709

前の版でできるようになったことは 4.8.3 の手引きにあります。