4.8.0 — Collections in the cell, and tasks that catch up

A snapshot of 4.8.0 as released on 2026-08-10. 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

Two things to know. Collections are no longer a workspace-only idea — 4.7.6 built the plumbing, and this release is the half you can see: a Collections pane in each cell, showing the collections of the folder that cell is open in. And a scheduled task no longer loses a run because your machine was off at the wrong minute.

Nothing here requires a config change. The scheduler fix applies to a setting you may already have on, and the section below tells you how to confirm it is finally working.

---

Please do not put a collection in a project folder yet

The per-folder collection feature is not finished. Keep your collections in the workspace — the directory MulmoTerminal binds when it starts — as you have been doing. The pane below is safe to open and look at; what is not ready is moving your data into a project folder.

What is still missing, so you can judge for yourself:

• Scheduled refresh does not run for a project folder’s collection. It was written and taken back out before release: for a collection that refreshes by dispatching an agent, the seed prompt carries a root-relative data path while the worker stands in the workspace — so a refresh scheduled for a project would have written into the workspace’s same-named collection. A silent cross-project write is worse than no refresh, so there is no refresh. The fix needs a change in the shared library first.
• The phone cannot reach a project’s collection. The groundwork is in, but there is no project picker on the phone, so it sees the workspace and only the workspace.
• Two projects’ cards cannot share one panel. A card finds its own session’s project, which covers the ordinary case; cards from two different projects side by side need a plugin release that is not out yet.
• The pane has not had a live browser check the way the full-screen overlay has.

None of this loses data you already have — the workspace path is unchanged and unaffected. It is a “do not build on it yet” notice, not a warning about your existing collections. When the remaining pieces land, a release page will say so.

---

The Collections pane

Open a cell’s right pane and pick Collections, beside Canvas / Tools / Files. It lists the collections of that cell’s directory — there is no project picker to set, because a cell already names a directory.

In practice that directory should be your workspace for now, per the notice above.

Two cells open on two different folders show two different lists, and opening a collection in one does not move the other, or the app around them. If a cell’s directory has no collection tools available, the button is not offered there at all.

For what a collection is and how an agent authors one, see Features overview in the living guide.

Completion bells now fire for a project’s collection

If a collection declares a completion field, MulmoTerminal rings when an agent finishes writing a record. Until this release the watcher was mounted for the workspace only, so a collection in a project folder asked for a bell that could never ring — and the pane did not refresh by itself either.

Now one watcher runs per directory this server serves: the workspace, plus every directory saved in cwdPresets. Worth reading twice, because it is the thing people get wrong: “open” means served by this server, not visible on screen. A directory in your saved list is watched whether or not a cell is showing it.

Nothing to configure. If you want a folder watched, it needs to be one you have saved — see Configuration for cwdPresets.

“Would this collection survive a clone?”

A collection is meant to be a folder someone else can clone and use. Five things quietly break that, and there is now a check for them:

curl 'http://localhost:8080/api/collections/<slug>/self-containment?project=<id>'

Each rule is named for what goes wrong on the other machine:

code	severity	what happens over there
user-scope	blocker	the skill lives in ~/.claude/skills, so the clone gets whatever that machine happens to have
data-ignored	blocker	the schema is committed but the records are gitignored — it reads as an empty collection
sqlite-store	blocker	one binary file, which git cannot merge
csv-runtime	warning	the file travels, but the DuckDB runtime has to be installed there too
no-primary-key	warning	ids are 4 random bytes, so two machines can mint the same one
not-a-repo	info	the directory is not a git repository, so nothing is being cloned yet

The project id comes from GET /api/collection-projects, which lists the directories this server will serve. Leave it off and the workspace is checked.

Scheduled tasks now run what they missed

If you turned the dev worklog on and never saw a page appear, this is why — and it is fixed.

Built-in scheduled tasks (the dev worklog, collection feed refresh, calendar sync) fire on UTC-aligned boundaries. A six-hour task can only fire during the one minute at 00:00, 06:00, 12:00 or 18:00 UTC — that is 09:00, 15:00, 21:00 and 03:00 JST. Until this release, a server that was asleep, restarting or simply off through that minute skipped the run forever: nothing recorded that a window had passed, so nothing could make it up. Starting MulmoTerminal with npx a few times a day, as most people do, meant the worklog could go for days without running once, with no error anywhere.

Now every run is recorded in <workspace>/config/scheduler/state.json, and at startup the scheduler runs what it missed. The worklog catches up once — a single batch covering everything since its last run, not one batch per missed window.

How to tell it is working

Nothing to turn on beyond the worklog setting itself (Configuration → worklogEnabled). To confirm:

1. Restart MulmoTerminal and let it settle for a few seconds.

2. Look for the state file in the directory you started the server in:

   cat config/scheduler/state.json
   

   Each task has a lastRunAt and a nextScheduledAt. On the very first start after upgrading, a task that has never run gets a starting point with totalRuns: 0 — that is the scheduler saying “the clock starts here”, not that a run happened.

3. Ask the server directly:

   curl http://localhost:8080/api/scheduler/tasks
   curl 'http://localhost:8080/api/scheduler/logs?limit=20'
   

   The first lists every task with its last and next run; the second is the run history, newest first. A run made up after downtime is logged with "trigger":"catch-up".

The history is on disk too, under <workspace>/data/scheduler/logs/, one file per day.

A note on what a “run” means for the worklog. It spawns a background session, and the scheduler records the dispatch rather than waiting for the session to finish — a batch can take minutes, and the scheduler must keep ticking for everything else. If that session then fails, the failure is recorded afterwards, so a task whose last entry is an error really did fail. For what the worklog writes and what it costs, see Configuration → worklogEnabled.

Also in this release

• Staging is workspace-only, and the agent is told so. Drafts under data/skills/ exist to route around the permission gate on .claude/. A project folder has no such gate, and the engine reads staging first — so a stray data/skills/<slug>/ could shadow the committed skill in a repo whose whole point is to be self-contained. The authoring instructions an agent reads now say which directory to write in for which scope.
• A card that says “Collection not found” when the collection is right there. An agent working in a project folder could create a collection, write records, and have the rendered card fail to find it — because the card fetched by name through whichever surface was active, and with no Collections pane open that was the workspace. The canvas is now a surface of its own: it shows one session’s cards, and that session’s directory is the project they belong to.
• @mulmoclaude/core moved to 3.1.0, the shared library MulmoTerminal and MulmoClaude both run on.
• Two guide screenshots were retaken. They had captured a maintainer’s real screen — project names in the cockpit roster, and an account email in Claude Code’s startup banner. Same framing, no personal data, and docs/guide/images/README.md now indexes all 74 images.

How to tell you have it

1. Restart MulmoTerminal (npx mulmoterminal@latest).
2. Open Settings from the gear in the toolbar. The version sits directly under the Settings heading, at the top of the dialog. It should read 4.8.0.
3. Open a cell’s right pane. Collections should be one of the choices beside Canvas / Tools / Files, in any directory whose tools include collections.

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

If the restart itself is the part that goes wrong, see Getting started.