feat(update-check): re-check while the server runs — a server started with npx @latest is never told a newer version shipped

[ystknsh]

背景

更新チェック（#654, #677）は、ランチャ起動時（bin/mulmoterminal.js の checkForUpdate）とサーバ起動時（server/index.ts の refreshUpdateStatus）の各 1 回だけ走ります。稼働中に再チェックする処理はありません（src/composables/useUpdateStatus.ts のポーリングは起動時の結果が返るのを待つためのもので、ready が立つか最大 5 回で止まります。server/config/update-status.ts のコメントにも "Recomputed on each start" とあります）。

README が案内する起動方法 npx mulmoterminal@latest では、起動した時点で registry の latest が動きます。チェックはその瞬間にしか走らないので、比較は常に「動いている版 == latest」で、bin/update-check.js の npmUpdateNotice は null を返します。稼働中に新版が出れば「動いている版 < latest」になりますが、その時点で見に行く処理が無い。この 2 つを合わせると、この起動方法のユーザーには、ヘッダの Update badge も起動時のコンソール通知も出る機会がありません。

サーバは何日でも動き続ける設計（tmux で persistence まで持つ）なので、稼働中に新版が出ても再起動の機会は自然には来ません。実例として、あるユーザーの要望が入った版をリリースした際、作者が個別に「新版に入ったので確認してほしい」と伝えたことで初めて更新が行われました。こちらから伝えなければ更新しようと思わなかった可能性がある、とのことです。ユーザーが増えればこの人力通知は成り立ちません。

現状 badge が機能するのは、動いている版が起動後に固定される npm i -g と、git ls-remote で origin と比べる git checkout です。バージョン指定なしの npx mulmoterminal でキャッシュの古い版が動いた場合は出うると思いますが、これは npm 側の挙動で本リポジトリでは検証していません（推測）。

加えて、npx 経由の起動は install 種別が "npm" と判定されます（hasNodeModulesSegment が _npx/<hash>/node_modules/… に反応する）。そのため仮に通知が出ても案内コマンドは npm i -g mulmoterminal になります。npx で起動した人の更新手順は「止めて起動し直す」なので、この案内は的外れです。なお _npx セグメントから分かるのは npx のキャッシュから実行されていることまでで、@latest を付けて起動したかどうかはサーバ側からは分かりません。

観察環境: main faeae7de（4.10.1）。bin/update-check.js の npmUpdateNotice("4.10.1", "4.10.1") が null、classifyInstall("<home>/.npm/_npx/<hash>/node_modules/mulmoterminal", false) が "npm" を返すことを実行して確認しました。手元で npx mulmoterminal@latest（4.10.1）を起動した状態の GET /api/update-status は {"install":"npm","version":"4.10.1","latest":null,"notice":null} でした。

考えられるアプローチ

2 つは独立しています。

1. 稼働中に定期的に再チェックする — refreshUpdateStatus を起動時 1 回ではなく一定間隔で呼び直すのはどうでしょうか。server/index.ts には setInterval(...).unref() で回している処理が既にあり（scheduledSessions.sweep、refreshDecisionDigests）、同じ形に乗せられます。間隔は registry への負荷と即時性のトレードオフで、新版に数時間で気づければ十分だと思います。失敗時は現状と同じく best-effort（黙って前回の値を保つ）。NO_UPDATE_NOTIFIER / MULMOTERMINAL_NO_UPDATE_CHECK のオプトアウトはそのまま効かせます。UI 側（useUpdateStatus）は ready で止まる現在のポーリングをやめて間隔を空けて読み直す形にする必要があります（タブが見えているときだけにするか等は実装判断）。README の GET /api/update-status の行にある "Computed once at startup" も直します
2. npx 経由の起動を見分けて、案内を「再起動」にする — パスに _npx セグメントがあるときは install 種別を分け、通知文を npm i -g ではなく「MulmoTerminal を止めて起動し直す」にするのはどうでしょうか。起動コマンドそのものは保持していないので、文言は固定（例: npx mulmoterminal@latest）か一般的な表現にする判断が要ります。install 種別を増やすと common/updateStatus.ts の InstallKind と parseUpdateStatus、UI の parseUpdateNotice、それぞれの spec、README の API 表まで一式が対象になります。(1) と独立です

関連

• feat(ui): a way to stop the server from the browser #1820: ブラウザから止める導線。A と本 issue が揃うと、badge のポップオーバーに「再起動して更新」を置けて、npx ユーザーの更新が 1 ボタンになります。本 issue は A に依存しません
• feat: git 版と npm 版それぞれの更新をユーザに知らせる #654 / feat: 更新があるとき Web ヘッダにバッジを出す（コンソールだけでなく） #677: 更新チェックと badge の経緯

[isamu]

Working on this in mulmoterminal4.

• started — 2026-08-21 04:20 UTC

_{posted by MulmoTerminal}

[isamu]

案 1（稼働中の定期再チェック）を #1826 で実装し、c62a6a80 で main に入りました。案 2 は未着手なので、この issue は open のままです（PR は Refs で、Closes は使っていません）。

入ったもの

• サーバ: startUpdateStatusRefresh() が起動時 + 3 時間ごとにチェック（unref 済み、失敗時は従来どおり前回値を保持）。server/index.ts ではなく server/config/update-status.ts に置いています — 間隔は更新対象の隣にあるべきで、entry file の setInterval はテストから触れないためです
• UI: useUpdateStatus が ready で止まるのをやめ、既存の usePollWhileVisible で読み直し（focus / visibilitychange にも反応）。副産物としてサーバ再起動からも自力で復帰します
• README の "Computed once at startup" と Install & run の記述を修正

比較ロジック自体は壊れていなかったことを、実際の npm registry に対して確認済みです。_npx を模した pkgDir で、4.10.1（= 当時の latest）だと notice: null、4.9.0 だと Update available: 4.9.0 → 4.10.1 が出ます。足りなかったのは 2 回目に見に行くことだけでした。

残っている案 2（npx を install 種別として分け、案内を npm i -g mulmoterminal ではなく「止めて起動し直す」にする）

いま npx ユーザーには badge は出ますが、案内コマンドは依然として的外れです。なお、この issue が書かれた後に #1820 側で状況が変わっています:

• feat: ブラウザから MulmoTerminal を止められるようにする (#1820) #1825 でブラウザから止める導線が入りました（この issue が「A と揃えば badge のポップオーバーに『再起動して更新』を置ける」と書いていた相手方）
• feat: mulmoterminal stop — どのターミナルからでも止められるようにする (#1820) #1824 で mulmoterminal stop が入り、その過程で --force の案内が npx 対応になっています（a96515cc）。案 2 の文言はそこと揃えるのが自然だと思います

また案 1 の副作用として、git checkout では作業ツリーが dirty になると badge が消えるようになりました（3 時間ごとに再評価されるため）。提示している git pull は dirty tree では実行できないので正しい挙動と考えており、CodeRabbit も PR 上で同意しています。