4.17.0 — Your favourites on the toolbar

A snapshot as of 4.17.0 (released 2026-09-08). 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

One thing needs turning on (toolbar pins) and the rest is things that were wrong and no longer are. If you run MulmoClaude against the same workspace, the second section matters to you even though there is nothing to configure in it.

The one thing to turn on: a favourite, one press away

Pinning a collection put it in the row at the top of the Collections overlay — a row you cannot see until you open the overlay. So opening a pinned thing cost two presses, every time.

Now a few of those pins can sit in the toolbar itself, beside Grid and Collections:

How to set it up

1. Pin what you use — open Collections and press the star on the collections and feeds you open often. (Already pinned? Skip this.)
2. Open Settings (the gear at the right of the toolbar) → Toolbar pins, under Appearance.
3. Tick up to five. The list offers exactly what you have pinned.

The buttons appear immediately. Tick nothing and your toolbar is exactly as it was — this is opt-in, and an empty list draws nothing at all, not even a separator.

Or write it yourself

In ~/.mulmoterminal/config.json:

{ "toolbarPins": ["collection:works", "collection:todos", "feed:news"] }

Each entry is "<kind>:<slug>" — kind is collection or feed, slug is the one in the address (/collections/works). The array’s order is the order the buttons are drawn in.

Things worth knowing

• Five buttons is the cap. The toolbar already carries the view switch, the grid’s own controls, the status tally and two gauges; past a handful the pins stop being “one press away” and start pushing that row into a horizontal scroll.
• It promotes; it does not pin. An entry has to be pinned already — the button’s name and icon are read from the pin, so renaming the collection renames the button.
• Unpinning something you promoted costs you nothing. Its button goes and its entry stays in the file, so pinning it again brings the button back where it was. Nothing tidies those entries away, deliberately: deciding “this pin is gone” from a list that might be out of date is how a promotion you still wanted gets deleted silently.
• The pinned row at the top of the Collections overlay is unchanged and still lists all of them. This is a second, shorter list on top of it.

→ Reference: A favourite you open all day · The toolbar, group by group

If you also run MulmoClaude: your pin colours stop disappearing

Nothing to configure. This is a bug that was live in every version before this one, and you could only see it from MulmoClaude’s side.

What was wrong. MulmoTerminal and MulmoClaude share one file for pinned favourites (<workspace>/config/shortcuts.json). MulmoTerminal rebuilt every record it wrote from the four fields it knew about — and MulmoClaude stores a fifth, the accent colour it draws in its launcher. So pinning or unpinning anything in MulmoTerminal wiped the colours from every entry. It came back the next time you opened a collection index in MulmoClaude, so it read as flicker rather than as a bug.

How to tell you have the fix. In MulmoClaude, note a pinned collection that has a colour. Pin anything in MulmoTerminal. The colour is still there.

Two related fixes ride along:

• A pin created in MulmoTerminal now carries the colour too, instead of arriving colourless and waiting for MulmoClaude to fill it in.
• MulmoTerminal now keeps fields it does not understand when it writes that file, so the next field either app adds does not need a matching change here to survive. (MulmoClaude still rebuilds its own records, so the reverse direction is not covered yet — mulmoclaude#3055.)

→ Reference: What MulmoTerminal can do · Every config key

A deck outside a stories root opens in Canvas

Nothing to configure. Open in Canvas in the Files pane only appeared for decks under a registered stories root; clicking any other .json deck did nothing and showed no button. It now opens by its own absolute path.

The same change fixed two things you may have seen without knowing what they were: adding a directory preset and restarting could split one deck into two cards (the card’s identity was the wire spelling, which depends on what the server has registered), and decks under different workspaces could share one identity when neither had a path component.

→ Reference: What MulmoTerminal can do

Also in this release

• docs/facts.json — the machine-readable statement of what this package is, served at /facts.json and read by tools rather than people, said 4.4.0 while 4.16.1 was on npm. It is now pinned to package.json by a test, so it cannot drift again.

Upgrading

npx mulmoterminal@latest

Needs Node 22.12 or newer, as 4.16.1 did — node -v if you skipped that release.

Nothing in this version changes a file you wrote. Your ~/.mulmoterminal/config.json, your projects’ .mulmoterminal.json and your pinned favourites are read exactly as before; toolbarPins is a new key that starts empty.