4.7.6 — Groundwork for collections outside the workspace

A snapshot of 4.7.6 as released on 2026-08-09. It will go out of date as the app moves on; that is fine and expected. For the reference that is kept current, follow the links to the living guide in each section.

npx mulmoterminal@latest

Nothing to configure, and nothing new to look at. This release changes no screen, adds no setting and removes none. Every collection you have keeps behaving exactly as it did in 4.7.5. What changed is underneath: the machinery that decides which directory a collection lives in.

Upgrade because a release you skip is a release you have to skip past later — not because there is something here to turn on.

What actually changed

Collections have always lived in one place: the shared workspace MulmoTerminal binds when it starts. Every part of the app that touched a collection — the routes, the view tokens, the thumbnail cache — could assume that, because there was only ever one answer.

The intent is for a collection to be able to live in any project directory you already work in, the way a .mulmoterminal.json does. That is not shipped. What shipped is the part that has to come first:

the collection engine is no longer handed a workspace to fall back on, so every call has to say which directory it means;
a request may now name a project, and the collection routes will serve that project’s directory instead of the workspace;
the things that were filed by collection name alone — view tokens, the thumbnail cache, the per-view query budget — are now filed by directory and name, because two projects both having a tasks collection is the ordinary case, not the strange one.

None of that is reachable from the app yet: the part of the UI that would let you pick a project has not been built, so nothing in the browser asks for anything other than the workspace. It is reachable only by calling the API directly.

The reason for doing it in this order is worth one sentence, because it is the whole point. With one directory, code that forgets to say which directory it means is still right, by accident. With one directory per project, that same code is not right — it quietly reads or writes another project’s data, and nothing anywhere reports an error. So the fallback was removed first and turned into a hard failure, which immediately found two places that had been getting the directory by luck.

For what collections are today, see the Features overview in the living guide.

Also in this release

@mulmoclaude/core moved to 3.0.1, and the bundled plugins were rebuilt against it. This is the shared library MulmoTerminal and MulmoClaude both run on; the collection work above is what needed the new version. If you use the GUI panel — the diagrams, forms, documents, MulmoCast slides and accounting views an agent can draw — it is worth knowing that this release also removes a way in which two copies of that library could have ended up loaded at once. You would have seen it as a panel that renders nothing at all.

How to tell you have it

There is no behaviour to check, so check the version:

Restart MulmoTerminal (npx mulmoterminal@latest).
Open Settings from the gear in the toolbar. The version sits directly under the Settings heading, at the top of the dialog — before you pick anything in the sidebar. It should read 4.7.6.

If it still says 4.7.5, the old process is still running — stop it and start it again. npx will not swap the version out from under a running server.

Everything else worth doing after an upgrade is unchanged: see Getting started if the restart itself is the part that goes wrong.