mulmoterminal 4.2.0 → 4.3.0

package/README.md

@@ -8,6 +8,10 @@ coding with a single agent needs nothing but a shell — this is for when you ru
 track of which is waiting. Sessions survive a reload (tmux), work isolates in **git worktrees**,
 and a **phone push** reaches you when a turn finishes.
 
+**Every cell is a real pty.** `htop`, `lazygit`, a dev server and Claude Code are the same kind
+of object here — which is why the one-session-per-worktree limit applies to **agents only**, and
+a shell or a `yarn dev` launcher can sit in the same worktree an agent is working in.
+
 ### 📖 Documentation — **[receptron.github.io/mulmoterminal](https://receptron.github.io/mulmoterminal/)**
 
 - **User guide:** [English](https://receptron.github.io/mulmoterminal/guide/en/) — the grid
@@ -386,9 +390,10 @@ today — **Claude Code** (the default), **Codex**, and **Antigravity** (`agy`).
 
 - **Claude** — spawned as `claude` (override with `CLAUDE_BIN`). The server passes
   `--session-id <uuid>`, so it knows the live session's id even before its transcript
-  file exists, and injects activity hooks + the GUI MCP per spawn (see
+  file exists, and injects activity hooks per spawn (see
   [Claude hook injection](#claude-hook-injection)) plus the
   [closing summary](#closing-summary) instruction.
+  The **whole** GUI MCP (`--mcp-config` + `--strict-mcp-config`) goes only to a session that is not a grid cell, or to a grid cell whose cwd IS the workspace — `carriesFullGuiMcp` in `server/session/spawn-claude.ts`, which is what gives a workspace cell the tools the single view had before 4.0.0 removed it. That equivalence is about what the session *carries*: a workspace cell is still a grid cell in every other respect. A cell in a project directory attaches neither flag, so Claude Code loads MCP servers the ordinary way — the directory's own local scope, any `.mcp.json` up the tree, and your global ones — including whichever [Canvas switches](#wiki-collections--the-gui-panel) are registered for it.
 - **Codex** — spawned as `codex` (override with `CODEX_BIN`; `CODEX_MODEL` sets
   `--model`). Codex runs on its own WebSocket (`/ws/codex`) and its sessions appear in the
   cockpit roster next to Claude's. Because Codex only mints its rollout id **after** the first
@@ -547,7 +552,7 @@ The Settings modal (⚙) persists per-user UI choices to `~/.mulmoterminal/confi
 | `repoDirs`   | `{ "owner/repo": "/abs/path" }` — which local clone work on a repo starts in, when you keep several side by side. Only the *choice* is stored; which clones exist is re-derived from `cwdPresets` on every read, and an entry that no longer names a clone of that repo is ignored. |
 | `launchers`  | `{ label, command }` entries offered in a grid cell's launcher besides the agents — any interactive command. A plain shell needs no entry: the launch form's **Shell** toggle opens `$SHELL` unconfigured. |
 | `quickCommands` | `{ label, text, agents? }` phrases the **phone** offers as chips on a session's terminal view. Tapping one puts `text` in the input box; it is not sent until you press send. `agents` (`"claude"` / `"codex"` / `"shell"`) scopes a chip to session kinds — omit it to offer the chip everywhere. Empty by default. |
-| `userMcpServers` | `{ id, url }` HTTP MCP servers merged into the `--mcp-config` of the Claude sessions that carry the full GUI MCP — a cell whose working directory is the **workspace**, and any session the server starts itself (the phone, a scheduled task). A cell in a project directory loads its own MCP config instead. Takes effect on the next session. |
+| `userMcpServers` | `{ id, url }` HTTP MCP servers merged into the `--mcp-config` of the Claude sessions that carry the full GUI MCP — a cell whose working directory is the **workspace**, and a session the server starts itself (the phone, a scheduled task) unless it asks for a grid cell's shape, as an issue's seed session does (`issueSpawnOptions`). A cell in a project directory loads its own MCP config instead. Takes effect on the next session. |
 | `buttons`    | Header action buttons — see [Header buttons](#header-buttons). Omit to keep the defaults; set to replace them. |
 | `chips`      | Header info chips (`dir` / `git` / `work` / `diff` / `ctx` / `usage` / `status` / `tools`, or custom text). Omit to keep the default set; `[]` hides all built-ins. `work` shows which PR / issue the cell is on (`#977 → #966`) and clears itself when the PR merges — see the [Configuration guide](https://receptron.github.io/mulmoterminal/guide/en/config.html#work-chip). |
 | `pushEnabled` | `true` to send a **Web Push** to your registered devices. Off by default; only sends while the **RemoteHost** channel is connected (see below). The master switch — `pushKinds` picks which moments. |
@@ -707,7 +712,7 @@ malformed file is ignored.
 | `theme`      | xterm palette for terminals in this directory (one of the built-in theme ids). |
 | `colors`     | Per-key xterm palette overrides applied on top of `theme` (or the app theme when `theme` is unset). Keys are xterm `ITheme` names (`background`, `foreground`, `cursor`, `selectionBackground`, the 16 ANSI colors, …); values are hex (`#rgb` / `#rrggbb` / `#rrggbbaa`). Unknown keys / bad values are dropped. |
 | `fontSize`   | Terminal font size in px for this directory (8–32), overriding the Settings value. A size outside the range is clamped; a non-number is ignored. Changing it re-fits the terminal, so the PTY learns the new width — unlike browser zoom, which leaves the two disagreeing. |
-| `orderPriority` | This directory's rank in the grid's **priority** ordering — the third mode on the toolbar's ordering button, next to auto (attention-first) and manual (the move buttons). Any integer, **lowest first**; negatives are allowed. Directories that set nothing sort last, keeping their existing order, so adding the key to one project doesn't shuffle the rest. The grid reads it in **priority** mode only; the launcher's directory chips always sort by it, so a project sits in the same place on both. |
+| `orderPriority` | This directory's rank in the grid's **priority** ordering — the third mode on the toolbar's ordering button, next to auto (attention-first) and manual (the move buttons). Any integer, **lowest first**; negatives are allowed. Directories that set nothing sort last, keeping their existing order, so adding the key to one project doesn't shuffle the rest. The grid reads it in **priority** mode only; the launcher's directory chips sort by it, so a project sits in the same place on both. The one exception is the **workspace** chip, which always leads the launcher's row regardless of any rank — it is not one of the directories being ranked against each other, and it is the one place every GUI tool is reachable (see [MCP server ids](#mcp-server-ids-why-a-workspace-cell-and-a-project-cell-disagree)). |
 | `fontFamily` | CSS font-family stack for this directory's terminals, overriding the global `fontFamily`. Use the names as your OS lists them (`"'Cica', 'MS Gothic', monospace"`). An unusable stack is ignored whole rather than half-applied; `monospace` is appended if you name no generic family. Prefer fonts whose fullwidth glyphs are exactly twice the Latin width, or box-drawing frames tear. |
 | `sound`      | Attention sound for this directory's sessions, a path **relative to the directory** (served at `GET /api/dir-sound`). The fallback for every kind. |
 | `sounds`     | Per-kind override of `sound`: `{ "command-failed": "preset:gong" }`. Each value is a `preset:<id>` or a directory-relative path, under the same confinement. |
@@ -766,7 +771,22 @@ In dev, open the Vite URL; its proxy forwards `/ws`, `/ws/pubsub`, and `/api` to
 ## Scripts (Run menu)
 
 An empty grid cell's launcher sets the **Working directory** by typing, by a preset
-chip, or with the **📁 folder button** (a native OS folder dialog). It also offers a
+chip, or with the **📁 folder button** (a native OS folder dialog). The preset chips are
+the directories you have launched in; the **workspace** leads them always, marked with an
+icon, whether or not you have ever launched there — it is the one directory where a
+session reaches every GUI tool, so it is never a click you can lose. It has no remove
+button for the same reason.
+
+**The launcher is shorter in the workspace**, because two of its choices do not apply
+there. The per-directory **Canvas switches** are replaced by a line saying every GUI tool
+is already available — a session there is handed the whole GUI MCP at spawn, so switches
+would write a registration that `--strict-mcp-config` then ignores. And the **worktree**
+section is hidden: a worktree isolates work on one codebase onto a branch, while the
+workspace is what a session works *from* (the shared wiki, collections and accounting
+live there), which is precisely what a detached branch would cut it off from. Both come
+back the moment you point the field at a project directory.
+
+It also offers a
 **run a script** row
 that launches project scripts (a dev server, tests, a build, …) **in that cell, in
 the directory the cell is pointed at** — so a whole workflow lives in one window
@@ -1046,11 +1066,61 @@ GUI-protocol tools the agent calls — documents (`presentDocument`), forms (`pr
 generated images, charts, HTML, and collection cards. Each result is drawn by its plugin's
 own Vue view inside a Shadow-DOM `PluginFrame` (so a plugin's bundled CSS can't leak),
 mirrors the active session, and replays history on re-select. Plugins reach the agent over
-an **in-process MCP server** served per session at `POST /api/mcp/:sessionId` (server name
-`mulmoterminal-gui`). Which plugins load is gated by `plugins/plugins.json`; the shipped
-set includes markdown, form, image generation (needs `GEMINI_API_KEY`), chart, HTML,
-collection, and mulmoscript (MulmoCast video/slides/PDF playback) views. You can also merge
-your **own HTTP MCP servers** into a workspace session via Settings → `userMcpServers`.
+an **in-process MCP server** served per session at `POST /api/mcp/:sessionId`. Which plugins
+load is gated by `plugins/plugins.json`; the shipped set includes markdown, form, image
+generation (needs `GEMINI_API_KEY`), chart, HTML, collection, and mulmoscript (MulmoCast
+video/slides/PDF playback) views. You can also merge your **own HTTP MCP servers** into a
+workspace session via Settings → `userMcpServers`.
+
+### MCP server ids: why a workspace cell and a project cell disagree
+
+A tool is never called by its own name. Every MCP client prefixes it with the id of the server
+it came from — `mcp__<id>__presentChart` in Claude Code, `mcp-<id>-presentChart` in Codex (which
+also rewrites `-` in the id to `_`). So the id you register under is repeated on every tool, in
+every listing, for the life of the session.
+
+MulmoTerminal delivers the GUI MCP by **two different routes**, and they do not share an id:
+
+| | Workspace cell / single view | Project-directory grid cell |
+|---|---|---|
+| How it arrives | generated per spawn into `--mcp-config` (Claude) or `-c mcp_servers.<id>.url=` (Codex) | the user's OWN per-folder config — `.mcp.json`, `claude mcp add -s local` |
+| Server id | **`mt`** | **`mulmoterminal-render`**, `-data`, `-media`, `-external` — one per tool group |
+| Tools carried | all of them, on one URL | only the groups that directory registered |
+| Tool name looks like | `mcp__mt__presentChart` | `mcp__mulmoterminal-render__presentChart` |
+
+Which route a session takes is decided by `carriesFullGuiMcp()` in
+`server/session/mcp-config.ts` — the single view, a cell-less chat, or anything whose cwd **is**
+the workspace take the first; anything in a project directory takes the second.
+
+**The workspace is agent-agnostic, and so is the way you start a terminal there.** All three
+agents and the launcher chips ask the same predicate, so two terminals in the workspace reach
+the same tools no matter how they were started:
+
+| Started as | In the workspace | In a project directory |
+|---|---|---|
+| claude cell (including `?gui=0`) | `mt`, every tool | the directory's registered groups |
+| codex cell | `mt`, every tool | the directory's registered groups |
+| launcher chip running `claude` | `mt`, every tool — flags inserted into the command line | nothing injected; its own `.mcp.json` loads |
+| launcher chip running `codex` | `mt`, every tool — `-c` overrides inserted | the directory's registered groups |
+| launcher chip running anything else | untouched | untouched |
+
+A chip is a command line the user wrote, so the injection is a **rewrite of their text** and is
+deliberately narrow: only a bare `claude` or `codex` is recognised, and anything else — a wrapper
+script, `FOO=1 claude` — is passed through unchanged.
+
+A `claude` chip in the workspace is given `--strict-mcp-config`, same as the cell. That makes the
+generated config the only source — but it already contains your Settings `userMcpServers`, so
+**those still load and are still pre-approved**. What stops contributing is a project directory's
+per-folder `.mcp.json`, which in the workspace is the intent: that file is where the per-group URLs
+live, and the chip is being handed the all-tools URL instead.
+
+**The asymmetry is deliberate.** `mt` is ours to name: nothing on disk holds it, it is
+regenerated on every spawn, so it was shortened to stop paying 17 characters per tool name. The
+group ids are the opposite — they are keys in config files **users wrote**, they are what the
+launcher's per-group switch reads back, and they are documented in the setup guide. Renaming
+them breaks working setups silently, and would need a migration that rewrites existing
+per-folder configs. Both live in [`common/toolGroups.ts`](common/toolGroups.ts), where the
+constants carry the same warning.
 
 **Wiki.** The toolbar **Wiki** button opens a read-only browser over `<workspace>/data/wiki/`
 — an **index** (tag-filterable page catalog), rendered **pages** with `[[wiki links]]` and
@@ -1730,6 +1800,19 @@ and `fetch` are mocked so the tests run without a server.
 
 ---
 
+## Who builds this
+
+MulmoTerminal is built by the **[Singularity Society](https://singularitysociety.org)** team,
+including **[Satoshi Nakajima](https://x.com/snakajima)** — software architect for **Windows 95**,
+**Windows 98** and **Internet Explorer 3.0 / 4.0** at Microsoft, later founder of UIEvolution /
+Xevo, and still building from Seattle.
+
+It exists because we run several coding agents every day and kept losing track of which one was
+waiting on us. Everything here was built for that, then kept because it worked. MIT licensed.
+
+- **Updates** are announced in Japanese on X: [@SingularitySoci](https://x.com/SingularitySoci)
+- **Sister project:** [MulmoClaude](https://github.com/receptron/mulmoclaude)
+
 ## Contributing
 
 **Please open an issue rather than a pull request.** Bug reports and feature requests are very

package/common/toolGroups.ts

@@ -96,8 +96,45 @@ export const toolsInGroup = (group: ToolGroup): string[] => [...GROUP_BY_TOOL].f
 // `mcp__<server id>__<tool>`, and the id comes from the USER's config key — so this is a
 // convention the enable-it-for-this-folder affordance has to write, and a user who registers
 // the same URL under another name simply gets permission prompts (nothing breaks).
+//
+// DELIBERATELY long, and deliberately NOT the same id as GUI_SERVER_ID below. The two are
+// reached by different routes (see that constant), so the same tool is named
+// `mcp__mulmoterminal-render__presentChart` in a project cell and `mcp__mt__presentChart` in a
+// workspace one. That is not drift to be tidied up: shortening these would break every
+// `.mcp.json` and `claude mcp add -s local` entry users have already written against them,
+// which the launcher's per-group switch also reads back and the setup guide documents. It needs
+// a migration over existing per-folder configs, not a rename. README's "MCP server ids" section
+// is the long version.
 export const toolGroupServerId = (group: ToolGroup): string => `mulmoterminal-${group}`;
 
+// The MCP server id the SINGLE VIEW registers — every tool on one URL, rather than the per-group
+// ids above. Unlike those, a user never writes this one: it is generated per spawn into
+// `--mcp-config` (claude) or `-c mcp_servers.<id>.url=` (codex), so it is ours to name.
+//
+// Which of the two ids a session gets is decided by `carriesFullGuiMcp` in
+// server/session/spawn-claude.ts: the single view, a cell-less chat, and a cell whose cwd IS the
+// workspace carry this one; a cell in a project directory is handed no --mcp-config at all and
+// reaches the group ids through the user's own per-folder config. Both are live, on purpose.
+//
+// It is SHORT because the id is not what the agent sees — the client prefixes every tool with it.
+// claude turns `presentChart` into `mcp__<id>__presentChart` and codex into `mcp-<id>-presentChart`
+// (with `-` in the id normalised to `_`), so a long id is paid on every tool name in every listing.
+// `mulmoterminal-gui` cost 17 characters per tool to say what the surrounding config already says.
+//
+// It had been spelled out at four sites (this server's registration, the advertised server name,
+// the allowedTools prefix and the reserved-id list). It lives here now because both the server and
+// the UI-facing config validation decide from it — see the `common/` rule in CLAUDE.md.
+export const GUI_SERVER_ID = "mt";
+
+// Ids this project has shipped for the SAME single-view server before. Not live: kept so the place
+// that must recognise our own past output still does — the Antigravity config merge, which deletes
+// our entries by id and would otherwise leave a stale `mulmoterminal-gui` behind forever.
+//
+// Only where we WROTE them, though. A legacy id is not reserved against the user's own
+// `userMcpServers`: nothing writes it any more, so a server someone names `mulmoterminal-gui`
+// today is reachable and works, and treating it as ours would be claiming a name we abandoned.
+export const LEGACY_GUI_SERVER_IDS: readonly string[] = ["mulmoterminal-gui"];
+
 // The tools MulmoTerminal pre-approves via `--allowedTools`, so they run without a permission
 // prompt. A list of TOOLS, not of groups: a group says which tools a directory can reach, and
 // that is not the same question as which may run unattended.

package/dist/assets/{abnfDiagram-VRR7QNED-RjiYivmv-Ko4XgYrQ.js → abnfDiagram-VRR7QNED-RjiYivmv-Bdog-CiH.js}

@@ -1 +1 @@
-import{n as e}from"./chunk-Y2CYZVJY-Bdt8pFDJ-DsF7k-Jl.js";import{f as t}from"./src-Brzfja-q-ch1VcTiG.js";import{_ as n,g as r}from"./mermaid-parser.core-DxEa8E3F-C7Z349Pq.js";import"./chunk-WYO6CB5R-BlzOfotS-CbdIi1Rx.js";import"./chunk-VAUOI2AC-CS9QJ4yz-o20b35Qf.js";import{n as i,r as a,t as o}from"./chunk-MOJQB5TN-CMZRaeqt-BwgEBlFh.js";import{t as s}from"./chunk-JWPE2WC7-BQ3zXr2k-DSd3Ct95.js";var c=r().RailroadAbnf.parser.LangiumParser,l=e(e=>{let t=e.alternatives.map(u);return t.length===1?t[0]:{type:`choice`,alternatives:t}},`transformAlternation`),u=e(e=>{let t=e.elements.map(f);return t.length===1?t[0]:{type:`sequence`,elements:t}},`transformConcatenation`),d=e(e=>{if(e.includes(`*`)){let[t,n]=e.split(`*`);return{min:t?parseInt(t,10):0,max:n?parseInt(n,10):1/0}}let t=parseInt(e,10);return{min:t,max:t}},`parseRepeat`),f=e(e=>{let t=p(e.primary);if(!e.repeat)return t;let{min:n,max:r}=d(e.repeat);return n===0&&r===1?{type:`optional`,element:t}:{type:`repetition`,element:t,min:n,max:r}},`transformElement`),p=e(e=>{switch(e.$type){case`AbnfStringLiteral`:return{type:`terminal`,value:e.value};case`AbnfNumVal`:return{type:`terminal`,value:e.value};case`AbnfRuleName`:return{type:`nonterminal`,name:e.name};case`AbnfGroup`:return l(e.element);case`AbnfOptionalGroup`:return{type:`optional`,element:l(e.element)};default:throw Error(`Unsupported ABNF primary node: ${e.$type}`)}},`transformPrimary`),m=e(e=>({name:e.name,definition:l(e.definition)}),`transformRule`),h=e(e=>{s(e,a),e.title&&a.setTitle(e.title),e.rules.map(e=>a.addRule(m(e)))},`populateDb`),g={parser:{parse:e(e=>{a.clear(),t.debug(`[ABNF Parser] Starting Langium parse`);let r=c.parse(e);if(r.lexerErrors.length>0||r.parserErrors.length>0)throw new n(r);let i=r.value;t.debug(`[ABNF Parser] Parsed rules:`,i.rules.length),h(i),t.debug(`[ABNF Parser] Parse complete`)},`parse`),parser:{yy:a}},db:a,renderer:o,styles:i};export{g as diagram};
+import{n as e}from"./chunk-Y2CYZVJY-Bdt8pFDJ-DsF7k-Jl.js";import{f as t}from"./src-Brzfja-q-ch1VcTiG.js";import{_ as n,g as r}from"./mermaid-parser.core-DxEa8E3F-D6oVwac4.js";import"./chunk-WYO6CB5R-BlzOfotS-DMj-dLn7.js";import"./chunk-VAUOI2AC-CS9QJ4yz-DDJgABqC.js";import{n as i,r as a,t as o}from"./chunk-MOJQB5TN-CMZRaeqt-ePkETRCM.js";import{t as s}from"./chunk-JWPE2WC7-BQ3zXr2k-DSd3Ct95.js";var c=r().RailroadAbnf.parser.LangiumParser,l=e(e=>{let t=e.alternatives.map(u);return t.length===1?t[0]:{type:`choice`,alternatives:t}},`transformAlternation`),u=e(e=>{let t=e.elements.map(f);return t.length===1?t[0]:{type:`sequence`,elements:t}},`transformConcatenation`),d=e(e=>{if(e.includes(`*`)){let[t,n]=e.split(`*`);return{min:t?parseInt(t,10):0,max:n?parseInt(n,10):1/0}}let t=parseInt(e,10);return{min:t,max:t}},`parseRepeat`),f=e(e=>{let t=p(e.primary);if(!e.repeat)return t;let{min:n,max:r}=d(e.repeat);return n===0&&r===1?{type:`optional`,element:t}:{type:`repetition`,element:t,min:n,max:r}},`transformElement`),p=e(e=>{switch(e.$type){case`AbnfStringLiteral`:return{type:`terminal`,value:e.value};case`AbnfNumVal`:return{type:`terminal`,value:e.value};case`AbnfRuleName`:return{type:`nonterminal`,name:e.name};case`AbnfGroup`:return l(e.element);case`AbnfOptionalGroup`:return{type:`optional`,element:l(e.element)};default:throw Error(`Unsupported ABNF primary node: ${e.$type}`)}},`transformPrimary`),m=e(e=>({name:e.name,definition:l(e.definition)}),`transformRule`),h=e(e=>{s(e,a),e.title&&a.setTitle(e.title),e.rules.map(e=>a.addRule(m(e)))},`populateDb`),g={parser:{parse:e(e=>{a.clear(),t.debug(`[ABNF Parser] Starting Langium parse`);let r=c.parse(e);if(r.lexerErrors.length>0||r.parserErrors.length>0)throw new n(r);let i=r.value;t.debug(`[ABNF Parser] Parsed rules:`,i.rules.length),h(i),t.debug(`[ABNF Parser] Parse complete`)},`parse`),parser:{yy:a}},db:a,renderer:o,styles:i};export{g as diagram};

package/dist/assets/architecture-TIHT7OUA-0NsD2xW1-rsT_LNkQ.js

@@ -0,0 +1 @@
+import{f as e}from"./mermaid-parser.core-DxEa8E3F-D6oVwac4.js";export{e as createArchitectureServices};