4.8.2 — GitHub beside the cell, and a header you can read while it runs

A snapshot of 4.8.2 as released on 2026-08-13. 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 worth doing after you restart. The GitHub view moved into the cell’s right pane and needs nothing configured — there is a new button to press. The header colours while a session runs are now yours to choose, and that one is a config edit: if you gave a project a headerColor and the header became unreadable the moment the cell started working, this is the release that fixes it.

GitHub opens beside the cell, on that cell’s repository

Before. The toolbar’s Pull requests button took over the whole screen and listed every registered repository in the configured order. Reading one project’s issues meant leaving the grid, then finding that project somewhere down the list.

Now. An enlarged cell has its own GitHub button, and it opens the same list in the right pane beside the terminal, with that cell’s repository first.

How to open it

  1. Enlarge a cell — the panes only exist beside an enlarged cell.
  2. Press the merge icon in the cell’s header (its tooltip reads Show GitHub PRs and issues).
  3. The pane opens on the right. This cell’s repository gets its own block at the top — its open PRs and its open issues together, under one heading — and everything else follows below the rule, grouped per repository exactly as before.

It replaces whatever pane that cell had open — Canvas, Tools, Files and Collections were already mutually exclusive per cell, and GitHub joins the same rule. Press the button again to close it.

If your repository does not float to the top

Two things have to be true, and the second is the one that catches people:

  1. The cell’s directory is inside a working directory you registered in Settings. The clone itself or anywhere under it — a cell sitting in myrepo/src counts. Each registered directory is mapped to an owner/repo by reading its origin, so a directory that is not a git repository, has no origin, or points at a forge this app cannot read names no repository and cannot lead.
  2. That repository is one of the ones you registered under Settings → Pull request repos. The block at the top is a section of this list, so a repository the list does not carry has nothing to promote — even when its clone is a perfectly ordinary registered directory.

If either is false the pane opens in the plain configured order. Nothing breaks: everything is still listed, just without a repository lifted out to the top.

A registered repository with no open PRs and no open issues still gets its block, saying No open PRs / No open issues. That is deliberate — an empty answer to “what is open on this repo” is an answer, and it is why the pane lifts the section out rather than scrolling to a position.

What did not change

  • The full-screen view is still there, from the toolbar, for looking across every repository at once.
  • A bookmark on /prs still works — it redirects to /github.
  • A header button configured with "view": "prs" still opens it. The name changed where you reach it, not where you type it.
  • gh still has to be logged in, and the repositories listed are still the ones registered in Settings.

Reference: GitHub — cross-repo PRs & Issues in the living guide.

A header you can read while the session is running

This one is for anyone who has coloured their projects.

The symptom. You set headerColor (and perhaps headerTextColor) on a project, the idle cell looks right, and then the agent starts working — the header turns pale and the text on it all but disappears. Measured on a real report: white text on the theme’s working tint is 1.15:1.

Why it happened. While a session is working, done, or needs you, the theme replaces the header background with its own status tint — that is what lets you read the grid’s state from across the room. Your headerTextColor stayed on top of it. An ink chosen against a dark purple is not readable on a pale blue.

What 4.8.2 does. Two things:

  1. headerTextColor now applies only while your own colour is what shows. A running cell goes back to the theme’s own background-and-ink pairing, which was designed together.
  2. You can name the colours for those states yourself.

Choosing your own status colours

Write them in the project’s .mulmoterminal.json:

{
  "headerColor": "#8e44ad",
  "headerStatusColors": {
    "working": "#6d28d9",
    "done": { "background": "#166534" },
    "blocked": { "background": "#7c2d12", "text": "#ffe8a3" }
  }
}
  • Only working, done and blocked. There is no idle — headerColor is idle.
  • A status you do not name keeps the theme’s tint.
  • Omit text and a readable one is derived from the background you gave, so naming a single colour can never come out unreadable.
  • A bare string is shorthand for { "background": … }.

The same keys work in ~/.mulmoterminal/config.json, where they become the default for every directory; a project that names either key outranks it for that directory.

Or keep your own colour the whole time 

{ "headerColor": "#8e44ad", "headerStatusTint": "none" }

"none" leaves headerColor in place while working and done — the status still reads from the cell border, the status dot and the pill.

It deliberately does not reach blocked, the one state where nothing proceeds until you answer; a switch whose purpose is “keep my palette” taking the amber off that is an accident waiting to happen. Give blocked a colour of its own in headerStatusColors if you want one.

Making the edit take effect

  • A project’s .mulmoterminal.json needs no server restart, but it is not filesystem-watched: edit it by hand and an already-open terminal keeps the old colours until you reload the browser tab. Ask the /mulmoterminal-dirs skill to write it instead and the cell recolours as you watch.
  • ~/.mulmoterminal/config.json is read once at server startup — restart the server and reload the tab.

How to tell it worked

Give a coloured project a deliberately obvious working colour, start any agent in one of its cells, and watch the header while it thinks. It should be your colour, with legible text, and go back to headerColor when the turn ends.

One thing to be straight about

With nothing configured, the default is better but not good. The theme’s dim chip ink on its own status tint measures 1.9–3.1:1 across the four themes. That is not new — it is what every cell without custom colours has always shown — and 4.8.2 takes the reported case from 1.15:1 to about 2.5:1, not all the way. Naming headerStatusColors.working is what gets you to 12.9:1. Whether to raise that floor for everyone is still open; if the running header reads badly for you after this release, please say so in an issue.

Reference: the seven chrome colours in the living guide, and the /mulmoterminal-dirs skill, which owns these keys.

Fixes

  • A “finished” push no longer shows the previous turn’s reply. The phone’s completion banner read the last completed exchange, so a turn that produced no reply of its own — you pressed ESC, or it ended on a tool call — was announced with the answer from the turn before it. The banner now falls back to your prompt or the session’s title rather than putting an old answer under “finished”. The issue stays open: one other possible route (the order pushes are delivered in) has not been ruled out, so if you still see a stale banner, please say so on #1650.
  • A replayed terminal no longer starts with �. When the scrollback a reattach restores was cut exactly between the two halves of a non-BMP character — an emoji, a rare kanji — the orphaned half survived the cut and showed as a replacement character at the top of the screen. The cut now moves off the pair. (#1639)
  • A new document can no longer overwrite an existing one. Saving a document built its filename from 32 bits of randomness and wrote it unconditionally, so two documents that collided in the same month with the same title prefix left one silently replaced by the other. The name is now 64 bits and the write refuses to clobber an existing file. (#1623)

Not written up yet

Work on shared collections and shared apps continues under the surface in this release. It is not finished, so it is not documented here — it gets its own page when it ships. Nothing you have today changes because of it.

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.2.

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

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

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