4.7.0 — Muse, and the GUI tools it was not supposed to be able to reach

A snapshot of 4.7.0 as released on 2026-08-07. 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 for the Windows fix — it is on the moment you run 4.7.0. Muse needs the muse CLI on your PATH and one experimental flag of Muse’s own; both are below.

Muse is the fifth agent

Muse (muse, running Muse Spark) now sits in the Agent Picker beside Claude, Codex, Antigravity and Grok. Pick it in an empty cell and launch, exactly like the others.

A Muse cell behaves like the rest: it wears a mu badge, its header shows the model and how full the context is, and its conversations appear under OR RESUME HERE when Muse is the selected agent.

What you need

muse --version          # the CLI has to be on your PATH

Point elsewhere with MUSE_BIN (a pinned version, a wrapper, a path outside PATH), and override the model with MUSE_MODEL. Neither is required.

If you do not use Muse, you need nothing. An agent whose command is missing simply fails to start that cell, and the other four are unaffected.

Its GUI tools — the part that was said to be impossible

The 4.6.x notes said Muse could not have the GUI tools. That was wrong, and the reason it looked right is worth stating: Muse does have MCP — behind an experimental flag of its own, through a mechanism neither of the other agents uses.

Turning it on

export MUSE_EXPERIMENTAL_PLUGINS=1

Without it, muse plugins answers “plugins are not available in this build” and a Muse cell starts with no GUI tools (and one warning). With it, MulmoTerminal registers its plugin the first time a Muse cell starts, and the cell gets the groups that directory switched on — the same four toggles in the launcher form that Grok and Antigravity get.

To check it worked, ask the cell what tools it has. In a directory with only render on, it answers with exactly these four and nothing else:

mcp__plugin_mulmoterminal_render__presentChart
mcp__plugin_mulmoterminal_render__presentDocument
mcp__plugin_mulmoterminal_render__presentForm
mcp__plugin_mulmoterminal_render__presentHtml

Why the tool names look different

They do, and that is deliberate. The same tool is:

mcp__mt__presentChart in a Claude or Codex workspace cell,
mcp__mulmoterminal-render__presentChart in a project cell,
mcp__plugin_mulmoterminal_render__presentChart in a Muse cell.

All three are current. Muse builds a tool name out of the plugin id and the capability id, so the shape is its own. Nothing needs doing about it.

Two things to know

The plugin is machine-wide. muse plugins install records per machine, not per directory — so one plugin holds all four group servers and each session is narrowed to its directory’s switches. It will appear in muse plugins list for every Muse session on the machine, including ones MulmoTerminal did not start; those serve nothing. Remove it with muse plugins remove mulmoterminal — the next Muse cell re-registers it.
A group the session is not entitled to serves an empty toolset, not an error. A cell that switched one group on would otherwise show three broken servers.

The living reference, including how the other four agents reach their tools: Which coding agent.

A new guide page: which coding agent to use

Five first-class agents is enough that “which one, and what does it cost me” deserved its own page rather than a row in a table. Which coding agent covers, for each of Claude Code, Codex, Antigravity, Grok and Muse:

what has to be installed, and the *_BIN / *_MODEL overrides
where its conversations live, and therefore why only it can resume them
the three different routes to the GUI tools — a per-session URL (Claude, Codex), a file in the directory (Antigravity, Grok), a per-machine plugin (Muse) — and why that is a property of each CLI rather than a setting
what the header badges mean

It also covers the two things that widen what “Claude” means — a providers entry for any Anthropic-compatible backend, and a customAgents entry for your own way of starting Claude Code — and why a launch command is none of these.

Muse fixes that came with it

Three things a Muse cell used to get wrong. Nothing to do; they are simply right now.

A resumed session kept losing its workspace tools. The resume command dropped --workspace, which is what registers the policy-gated workspace tools — so the conversation came back without the tools it had been using.
The context badge read a high-water mark. It showed the largest context any call had ever used, so it never came down after a compaction: ctx 397k against a live 266k, telling you to /compact when you need not. It now reads the last completed call, which is what the Codex and Grok badges have always meant.
The badge poll re-read the whole session log every time — 33 MB after a day’s work, once per cell per minute. Measured after the fix on that same log: 105 ms cold, 2 ms warm, with byte-for-byte the same totals.

A Muse resume takes no seed prompt — Muse does not accept one on a resume command line. That is now stated in the code rather than being dropped silently.

Windows: every Claude session can start again

If you run MulmoTerminal on Windows with Claude installed from npm, this is the release you want.

What was broken. Every Claude session — new or resumed — failed with:

Failed to start Claude: argument contains a NUL, CR or LF: "## Closing summary …

A Windows command line has no way to carry a newline, and the default --append-system-prompt text is 44 lines. So a .cmd-installed Claude could not be launched at all. It had been that way since 2.3.0.

How to tell you have the fix. Start a Claude cell on Windows with the defaults. If it starts, you have it. If you switched End replies with a closing summary or End a created PR with the clone name off as a workaround, turn them back on — they were never the problem.

Codex, Grok, Antigravity, Muse and shell sessions were never affected.

Reported by @chikara813, who traced it to the exact release that introduced it.

Also in this release

Collection documentation caught up with the code, and the places where MulmoTerminal’s /api/* paths deliberately differ from MulmoClaude’s are now written down rather than left to be rediscovered. Documentation and comments only.