4.19.0 — Read a collection and drive its chat without leaving it

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

npx mulmoterminal@latest

Nothing here has to be turned on. Two things changed shape on screen, two things were wrong and no longer are — and one of those was quietly writing files into your projects, so it is worth knowing you have the fix.

The collection pane: a chat no longer closes what you were reading

Starting a chat from a collection card or template used to move the session into a grid cell and navigate away — the collection you were reading closed underneath you.

Now the chat is still an ordinary grid cell, but while the collection is open you drive that same terminal from a pane under it. Nothing is copied or handed over: the cell is teleported into the pane, which is the same mechanism that moves an enlarged cell into the zoom view. One socket, one xterm, one scrollback — only the place it is drawn changes.

• Several chats live in tabs, carrying the same attention colours and one-line summaries the cockpit roster uses. The Collections button shows how many are open.
• Dock it below or beside the collection. Each position remembers its own size, and you can resize by dragging or from the keyboard.
• It survives a reload. Which chat belongs to which collection is remembered in the browser.
• “Move to the grid” is gone. There is nothing to move: open the grid and the same session is there, in its cell.

A chat started anywhere else — a Settings skill button, say — still goes to the grid as before.

→ Reference: Collections and the GUI panel.

A cell opened from a collection now says which one

A chat opened from a collection runs in the workspace, so every one of them drew the same project favicon. With several in the grid, nothing told you which cell was opened for which collection.

The cell header now carries the collection’s own icon, just after the status dot — in the tiled grid, in the enlarged view, and in the cockpit roster and filmstrip.

Look just left of the cell’s title: where every collection chat used to show the same project favicon, each now carries the glyph and accent colour of the collection it came from — the same icon you see for that collection in the Collections launcher.

There is nothing to configure, and it is not a browser-side guess: the collection is resolved once when the session starts and filed beside it on the server, so it is still right after a reload, in another tab, and on your phone. The project favicon stays where it was — “which directory” and “which collection” are different questions.

→ Reference: the cell header.

Fix: the button that repairs a stuck cell was killing it

If you ever pressed the repair on a frozen cell and got a cell that was more dead than before, this was why — and it is worth checking you have the fix.

Disposing the canvas renderer threw (Cannot read properties of undefined (reading 'onShowLinkUnderline') in the console — not noise, as it looked), and the repair path did not catch it. The line that reconnects the socket never ran, so you were left with a brand-new terminal attached to nothing.

How to tell you have it: open the browser console, then repair a cell. On 4.19.0 the onShowLinkUnderline error does not appear and the cell comes back with a working prompt. Nothing to turn on.

Fix: MulmoTerminal was writing its own state into your project

This one leaves files behind, so it is the one to check.

npx mulmoterminal uses the directory you ran it from as the workspace. Until now that meant MulmoTerminal wrote its own bookkeeping there:

<your project>/config/scheduler/state.json
<your project>/data/scheduler/logs/
<your project>/data/notifier/

Deleting them did nothing — the hourly task wrote them again within the hour.

They now live under ~/.mulmoterminal/workspaces/<workspace-key>/, one directory per workspace. The managed workspace (~/mulmoclaude, or MULMOCLAUDE_WORKSPACE_PATH) is deliberately unchanged, because MulmoClaude reads the same files there.

How to tell you have it: run npx mulmoterminal@latest in a directory that has never had it, wait a moment, and look. On 4.19.0 nothing appears.

Cleaning up what an older version left:

# in the project directory an older version ran in
rm -f  config/scheduler/state.json
rm -rf data/scheduler data/notifier

Do not delete config/scheduler/tasks.json — that one is yours, it is still read from the workspace, and deleting it deletes your scheduled tasks. Remove the now-empty config/scheduler/ and data/ directories only if nothing else of yours is in them.

New setting: switch off the built-in hourly tasks

Two built-in tasks run every hour: the collection/feed refresh and the Google Calendar sync. With no feeds registered and no Google account connected they do nothing, but they ran anyway and there was no way to say otherwise.

In ~/.mulmoterminal/config.json:

{
  "feedRefreshEnabled": false,
  "calendarSyncEnabled": false
}

Or untick them in Settings → Sessions, under Built-in scheduled tasks:

• Both are on by default, and only an explicit false turns one off. An absent key — every config written before 4.19.0 — leaves them running, so upgrading changes nothing.
• It takes effect at the next server start. The scheduler registers its tasks once, at boot.
• Your own scheduled tasks are not affected. An enabled entry in config/scheduler/tasks.json still registers and still runs, with all the built-ins off.
• Neither task costs tokens. The periodic dev-work log does (it spawns an agent session), and that has always had its own switch, worklogEnabled.

→ Reference: Configuration.

Everything else

• Dependency updates: Markdown parsing, schema validation, @types/node, code analysis and the TypeScript lint packages.
• The Codex auto-review CI workflow is now run on demand rather than on every pull request.

---

Full detail for every change in this release: ChangeLog.