5.2.0 — Drag the roster, and every agent gets a summary
A snapshot as of 5.2.0 (released 2026-09-18). It will go stale as the app moves on — that is expected, and the living reference is the guide each section links to.
Three things ship. The first needs one setting, the second needs nothing, and the third may need you to edit a binding you already have.
1. Drag a roster row where you want it
The cockpit roster could only be reordered a step at a time — the ⋮ menu on a row and the ◀▶ buttons on a tile both swap with the neighbour, so moving a row across a long list meant pressing the same thing over and over. Now each row has a drag handle and can be dropped anywhere.
Turn it on
It appears only in manual sort, because that is the only mode where a hand-placed row stays put: auto and priority recompute the order whenever a cell’s status changes, so a dragged row would be undone by the next recomputation.
Click the sort button in the toolbar until it reads manual. The handle appears on each roster row; drag it and drop the row at any position.
- The ⋮ menu and the tiles’ ◀▶ still work — this is an added gesture, not a replacement.
- The ⋮ menu remains the keyboard route, which a drag cannot be.
- The order is one flat list, so the tiled grid re-orders with the roster.
2. The roster’s summary line fills in for every agent
Nothing to configure.
That line used to be blank unless the cell was Claude. It showed Claude Code’s own title, and no other agent writes one — so a codex, cursor, Antigravity, grok, copilot or muse row had a gap where the answer to “what is this cell about” should be.
Each agent now answers from its own store — the same label its history list already shows:
| agent | what the line shows |
|---|---|
| Claude | the title Claude Code writes for itself |
| codex, cursor, Antigravity, grok | the prompt the session was opened with |
| copilot, muse | the agent’s own summary, which it rewrites as the conversation goes |
A row whose agent has written nothing yet stays blank, as before. And when the summary would only repeat the prompt line beneath it — a cell that has had one turn — it stands down rather than saying the same thing twice.
3. Cmd+Shift+<letter> on macOS — check your keymap
This one may already affect you. A binding like:
{ "keymap": { "files-find": "Cmd+Shift+P" } } ← uppercase P: loads, never fires
loads, shows in Settings as bound, and never fires on macOS. While Cmd is held, a Mac browser puts the unshifted character in the key event, so the keystroke arrives as p and the binding waits for a P that never comes.
The fix is the spelling in the file, not the keys you press:
{ "keymap": { "files-find": "Cmd+Shift+p" } }
The same physical keystroke, and it now fires.
- MulmoTerminal now warns at startup and in
validateKeymapwhen it sees one, naming the lowercase spelling. - The warning is non-fatal on purpose: the identical entry is correct for a Windows or Linux browser, where
Meta+Shift+Preally does reportP. A Mac browser against a Linux host is normal here, and the server cannot know which browser will connect. - Matching stays case-sensitive —
aandAare different keystrokes — so nothing about how your other bindings match has changed.
How to check yours
Open ~/.mulmoterminal/config.json, look at every keymap value containing both Cmd (or Meta) and Shift, and lowercase any single letter at the end. Restart the server and the warning goes.
Also in this release
Every keymap sample this repo ships is now parsed and run through the real validator in CI — warnings fail the build as well as errors. That check exists because the guide had been handing readers Cmd+Shift+A in both languages, the exact spelling the section above describes as dead; the release checklist had required validating samples all along, and nothing executed the checklist.
5.2.0 carries #2127 (for #2125), #2128 (for #2123), #2129 (for #2126) and #2131 (for #2130).