4.7.4 — Your projects, recognisable on your phone

A snapshot of 4.7.4 as released on 2026-08-08. 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 in this release. If your projects already show an icon in the grid — and most do without anyone setting one, because the repository ships a favicon — they will show the same icon on your phone as soon as both sides are up to date. The other two changes are fixes that need no setting at all.

Your project’s icon now reaches your phone

The picture a directory marks its cells with has been in the grid since 4.5.0: icon in that project’s .mulmoterminal.json, or — when the key is absent — the favicon the repository already ships (public/favicon.svg, apple-touch-icon.png, a web manifest). Until now it stopped at the browser. It now also appears in the phone app:

  • the terminal list, where it takes the place of the terminal glyph on every row that has one
  • the terminal screen, at the head of the row the status badge is on

On the list, the glyph was identical on every row and only its colour ever said anything — whether the session is live. That colour did not disappear: it moved to a small green or grey dot on the corner of the icon. A row whose directory has no icon keeps the glyph exactly as before.

How to tell you have it

  1. Update the Mac side to 4.7.4 and restart it (npx mulmoterminal@latest).
  2. Open mulmoserver.web.app on your phone, signed in with the same Google account, and pull the terminal list up to date with the refresh button in the header.
  3. Rows whose project has an icon show it. If they all still show the terminal glyph, see below.

If the icons do not appear

The phone side has to be current too. The app updates itself when you bring it to the front, but a home-screen PWA resumes from memory and may be running an older build. Close it fully and reopen it, or open the site in the browser once.

Check the project actually has an icon — the grid on your Mac is the fastest test. If the cell header shows no picture there either, the directory has none, and the phone is right to show the glyph. Settings → Directory appearance has the switch for the automatic favicon search, and a single project opts out with "icon": false.

A very large icon is left out on purpose. An image over 48 KiB does not travel, and neither does anything past 256 KiB of icons in one list. The reply the phone receives has a hard size limit, and going over it would empty the whole list rather than drop one picture — so the rows at the bottom lose their icon instead. In practice nothing reaches this: the largest real favicon measured while building the feature was 25.9 KB, and a full set of twenty-two came to 148 KB. If a project of yours has a hand-made multi-resolution .ico, exporting a smaller PNG and pointing icon at it is the fix.

A data: icon over 64 KB was already refused before this release, by the same rule that keeps a directory’s config small. That is unchanged.

For what icon accepts, where else it appears, and how the automatic search picks a file, see Project icon and The favicon is picked up on its own in the living guide.

A claude or codex launch from your phone now starts

Tapping + on the phone’s terminal screen and choosing an agent opens a new cell on the desktop grid. Before 4.7.4, that cell stopped at the empty cell-creation form — the agent already picked, the directory already filled in, waiting for someone sitting at the Mac to press Start. shell worked. The other agents did nothing at all if you were not there.

Nothing to do: update and it starts. The cell opens, the agent launches, and the phone can watch it through the same terminal screen it was launched from.

See Your phone as a remote for what else the phone can start.

Codex session discovery got much cheaper

If you run codex cells, the Mac side was re-reading far more than it needed while a codex session started up. A JSONL file is one JSON object per line, but the code read the whole file to look at its first line — and it did that once a second, for up to thirty minutes, across every codex session file from the last two days. On the machine where this was reported: 149 files and 37 MB re-read every second, to look at a few hundred bytes.

It now reads the first line only.

Nothing to configure, and nothing visible changes — except that a machine with a lot of codex history should feel less busy while a codex cell is starting.

This is not the fix for the out-of-memory crashes some people have seen. Those are still being investigated; this was a real waste found along the way, and ruling it out is part of that work. If MulmoTerminal has crashed on you, an issue with the crash report attached is genuinely useful — the FAQ has the /mulmoterminal-bug-report route for filing one.

Also in this release

  • Dependency refresh. No behaviour change.
  • The 4.7.3 release documentation, which landed just after 4.7.3 was tagged.

Where to go next

This site uses Just the Docs, a documentation theme for Jekyll.