4.26.0 — The launcher no longer waits forever on “already running”

A snapshot as of 4.26.0 (released 2026-09-17). It will go stale as the app moves on — that is expected, and the living reference is the guide each section links to.

Nothing to configure. This release is a bug fix for a start-up failure, plus one change you would notice at the keyboard and a few smaller things. Upgrade and you have it:

npx mulmoterminal@latest

What was broken

Starting MulmoTerminal from a script or a wrapper — the kind of thing that launches it at login, with its output redirected to a log file and no console window — could print this and then never do anything else:

MulmoTerminal is already running (http://localhost:34567).
  Running more than one is NOT a supported setup: they share ~/.mulmoterminal,
  so they can overwrite each other's session state.
  To stop the running one instead:  npx mulmoterminal@latest stop

The port was never bound, nothing further was logged, and the process sat there — observed for over ten minutes on the machine that reported it (#2090, Windows 11). It happened on separate days, and on both of them no MulmoTerminal was actually running.

Two independent faults had to line up:

1. A dead server can look alive forever. Every running server writes ~/.mulmoterminal/instances/<pid>.json so the next launch can say “one is already running”. When a server is killed outright, that file survives — and the check for whether its process is still there only asked “does anything hold that process id?”. Windows hands a process id out again once its owner exits, so after the id was reused (by svchost.exe one time and csrss.exe the next) the dead server looked permanently alive.

2. The question it then asked could not be answered. Being told a server is already running, the launcher asks whether to start a second one anyway. It only asked when a terminal was attached — but “a terminal is attached” is not the same as “a person is there”, and a wrapper that redirects stdout and stderr while leaving stdin alone gets a console nobody can ever type into. So it waited.

How to tell you have the fix 

npx mulmoterminal@latest --version

If you hit the old bug, the visible difference is that start-up finishes. There are two ways it can now get past that prompt:

  • The stale entry is gone. Before asking anything, the launcher asks the operating system who owns the port that entry claims. If nobody does, the entry cannot belong to a running server, and it is deleted. In the reported case there is no prompt at all any more — nor the warning at the next start, because the file is no longer there.

  • The question has a deadline. If a server really is running and nobody answers, the launcher says so and carries on, instead of waiting:

    No answer in 60s — starting the second instance anyway, as with no terminal to ask.

    That is the same thing it has always done when there is no terminal to ask at all: a script that asked for a server should get one.

You no longer need to delete the file by hand. If you worked around this by removing ~/.mulmoterminal/instances/<pid>.json, that is now the launcher’s job.

If you want no pause at all, redirect stdin in your wrapper as well (to NUL on Windows, /dev/null elsewhere). The launcher then knows there is nobody to ask, prints its warning, and continues immediately.

One change at the keyboard: Ctrl+C at that prompt

This is the part to know even if the bug above never touched you.

When MulmoTerminal asks Start another one anyway? [y/N] and you press Ctrl+C or Ctrl+D, it now declines and stops — which is what it did before this release, and what you would expect from pressing Ctrl+C. While the fix above was being written, those keys briefly meant “start it anyway”, which would have handed the second instance to someone trying to avoid one. It was caught in review, and there is now a test that fails if it ever comes back.

Answering y still starts a second instance; Enter still declines — and two at once is still not a supported setup, because they share ~/.mulmoterminal. See When it doesn’t work in the reference guide.

Also in this release

Nothing to configure for any of these.

  • The ShapeScript view header stacks in a narrow pane, instead of squeezing the title into a single glyph and pushing the buttons off the edge. Download USDZ / GLB / STL are now one Download menu, with a hint about what each format is for.
  • The README is now readable in Japanese and Chinese — README.ja.md and README.zh.md. They cover the part where you decide whether to use it — the demo, why you would want it, and install and run — and point at the English README for the reference sections.
  • https://mulmoterminal.com serves the documentation site, with its certificate issued.
  • Dependency updates, and a fix to the shared preview so it only accepts messages from the frame that is actually on screen.
This site uses Just the Docs, a documentation theme for Jekyll.