MulmoTerminal

English · 日本語 · 简体中文 · 繁體中文 · 한국어

Run multiple coding-agent sessions in parallel — and see which one needs you.

A browser terminal for parallel AI coding agents: several sessions side by side, each in its own cell, with the one that needs you marked in colour. Claude Code is the default and six more CLIs are first-class — Codex, Antigravity, Grok, Muse, GitHub Copilot CLI and Cursor CLI. Vibe coding with a single agent needs nothing but a shell — this is for when you run several and lose 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.

Demo

!MulmoTerminal — a grid of live Claude Code sessions, each color-coded by state, updating in real time

The grid, live — each cell coloured working, done or needs you.

https://github.com/user-attachments/assets/0b8dd582-6c0d-4be3-b0b4-3740ad0bdba6

90 seconds, with sound: one agent, then a grid of them. Zoom into one and the roster still holds what every other session asked, answered and did, so you go to whichever is lit and lose nothing catching up.

MulmoTerminal turns Claude Code — and six other agent CLIs — into a parallel, observable workspace: many agent sessions at once in a grid, each one color-coded so you see at a glance which are working, which need you, and which are done — plus rich GUI output, git worktrees with one-click PRs, cost readouts, and a ping to your phone when a task finishes. One npx command, no Electron, no config.

npx mulmoterminal@latest        # starts on http://localhost:34567 and opens your browser

Requires Node ≥ 22.12, and by default the claude CLI — on your PATH or named by CLAUDE_BIN, already logged in. Declare a different default agent (--agent codex, or "defaultAgent" in ~/.mulmoterminal/config.json) and start-up checks that one instead. npx mulmoterminal@latest init reports what it can't find. On an older Node it stops before starting the server, with a banner and the upgrade commands for however that Node was installed.

Why not tmux + iTerm panes?

Running agents in parallel was never the hard part — tmux does that fine. What gets lost is which of them is waiting for you. A pane is opaque: working, finished and blocked-on-a-permission all look the same until you read it. Here every cell reports its state back to one grid — working (blue), done (green), needs you (amber) — with a chime when one goes amber off-screen, and a cockpit roster of one line per session so you can answer one without losing your place in the other four. It runs on tmux when you have it, for persistence across restarts.

Built by receptron — Satoshi Nakajima, software architect for Windows 95 at Microsoft, and Isamu Arimoto; the same two behind GraphAI. More ↓

Why you'll want it

• See every agent at once. A grid of live sessions, each cell color-coded by state —

• A GUI for your agents, not just a terminal. Beside the terminal, a Canvas panel

• Get pulled back from anywhere. A finished — or input-waiting — task sends a **Web Push

• Nothing is lost on a restart. With tmux, every session survives a server crash,

• Ship without leaving the grid. Each repo cell shows a git branch chip, isolates

• Know what it's costing. Per-session context %, token, and estimated $

• Make it yours. Per-directory themes, colors, and name badges (prod in red,

!MulmoTerminal's grid view — four live Claude sessions running side by side, each in its own color-coded project

The grid is a cockpit for parallel agents — here, four live Claude sessions, each in its own color-coded project. Every cell's header carries what you need to triage at a glance: model · context %, token counts (⇡in ⇣out), the git branch / changes chip, and an AI summary of what the agent is doing. A cell's border color signals state — working (blue), done (green), needs-you (amber — e.g. waiting on a permission), idle — with an attention chime so a stuck cell off-screen still pulls you back. Supervise many; only step in where you're called.

!The cockpit roster — a one-row-per-session summary list beside the enlarged terminal

*Zoomed in, the cockpit roster replaces thumbnails with information: every session as a text row — directory, AI summary, your last prompt, the agent's latest reply, a status word, and the branch's PR phase badge. A row whose agent is waiting on you rings amber and blinks; one that has merely finished rings green and stays still (Settings → Waiting rows turns the movement off). Click a row to swap the enlarged terminal.*

What it is, under the hood

Each session runs as a real PTY on the server (the agent CLI in a pseudo-terminal) and is streamed to an xterm.js terminal in the browser over a WebSocket. The cockpit roster lists every session and reflects, in real time, which are working (the agent is thinking, a spinner), which are waiting on you (a permission prompt or a question — an amber dot; nothing proceeds until you answer) and which are **finished with output you haven't seen** (a green dot) — driven by the activity each agent reports; claude's hooks are injected per spawn. The horizontal tab bar carries the same two dots.

!One agent zoomed, with the GUI panel beside it

To focus on one agent, zoom its cell: it takes the window, and the GUI panel ("Canvas") opens beside it, where that agent's tool calls render as documents, forms, charts, images, and HTML rather than printed text. The app opens on the grid (/, settling on /terminals), which is the only view; 3.x had a separate single view at /chat and 4.0.0 removed it, so that URL now lands on the grid like any other.

Inserting a file path — like a native terminal, you can put a file's absolute path into the prompt: drag a file onto the terminal, or click the file button in the terminal header, which asks the local server to open the OS file dialog and inserts the chosen path. The path is inserted at the cursor — it is not submitted, so you can review it first.

A drag inserts the file's own path where the browser exposes one via file:// (Firefox/Safari), so editing it afterwards edits the file you dropped. Where the browser withholds it — Chrome, and every browser when MulmoTerminal is open **from another machine**, where a local path would name nothing on the host — the file's bytes are sent instead, saved to a private per-session directory under the OS temp dir, and that path is inserted. The session is granted that directory at launch (Claude Code's --add-dir), so the agent reads it without a permission prompt; the copies are removed when the session ends, and any left by a crash are swept at the next start. Up to 110 MiB per file — the same ceiling as a phone attachment. **A session already running when you upgrade was launched without that grant**, so drops into it still prompt; new sessions don't.

Pasting a screenshot — take a screenshot and paste it straight into the terminal (Cmd/Ctrl+V). The image is saved to the session's own drop directory — the same place a dropped file goes, with the same grant, the same 110 MiB ceiling and the same cleanup when the session ends — and its absolute path is inserted at the cursor, so the agent can read it. Unlike a drop, this does not need the browser to expose a path — the bytes are on the clipboard — so it also covers Chrome, where dropping a file cannot insert a path. It works wherever the browser puts the image on the clipboard as image/png, image/jpeg, image/gif, or image/webp. Anything else is left to the terminal's own paste handling, exactly as before — including a paste that carries plain text next to the image, which copying from a web page usually does, so that pasting text keeps working.

Clicking a file path — the other direction. A path an agent prints becomes a link, and what it opens is chosen by its extension, so each kind arrives as the thing it is rather than as bytes (files within the session's working directory only):

| A clicked … | opens as | |---|---| | .md .markdown | rendered markdown in a new tab — the same sandboxed …/md HTML the Files preview renders, minus the scripts the preview needs (the one that reports where you are reading, and the one that draws mermaid diagrams — so a mermaid fence stays a code block here). It follows your system light/dark setting, since under the sandbox CSP it can't ask the app which theme is on | | .json | indented in a new tab (Chrome and Safari otherwise show one long line) | | .csv .tsv | a table in a new tab, with a sticky header that scrolls inside its own box | | source, config, logs, and .txt — 46 extensions | the app's own Files view (/files?path=), where CodeMirror highlights it, the tree is right there, and it can be edited | | .html .htm | the rendered page in a new tab, under the same sandboxed policy as the Files pane's Preview: its scripts run at an opaque origin with no fetch or XHR (so they cannot reach the app or its API), and an image beside it loads by its relative path (a relative stylesheet or script does not). The raw route answers .html as plain text, so opening one there showed its source | | images, PDF, SVG, video, audio | raw bytes in a new tab, which the browser renders better than an editor would | | everything else — .xlsx, .docx, .zip, a Makefile | the app's own Files view. A tab cannot display these, so opening one there is not a view — it is a download starting with no warning. The pane names the file and offers Open in OS, which hands it to the application that owns it (Excel for an .xlsx) |

A line after the path is followed. src/a.ts:42, src/a.ts:42:7 (gcc, clang, eslint -f unix, stack traces) and src/a.ts(12,5) (tsc) are one link. In the pane, and in the Files view, the file opens as text with the caret on that line and column — an HTML page, an SVG or a table included, and a tab reading in Preview switches to Edit. An image, a PDF, a video or an audio file has no line to go to and simply opens as itself. A route that renders the file in a new tab (.md, .json, .csv, .html with no cell enlarged) ignores the line. When the pane beside an enlarged cell takes the click, the keyboard stays in the terminal; the full-screen Files view, with no terminal beside it, puts it in the editor. (ESLint's default output puts the path on a line of its own, with no line number to follow.)

While a grid cell is enlarged, the Files pane takes the click first — every row above, since the pane is the same editor with a Preview for Markdown, HTML and SVG, shows an image as a picture and a PDF in a frame, and plays a video or an audio file with the browser's own controls (seeking included, whatever the file's size). The file opens beside the terminal that printed it, and the pane opens itself if it was closed. It declines, leaving the routing above untouched, when nothing is enlarged, or when the path is not under that cell's own directory (the pane cannot walk above its root). A file too large to edit as text still offers Open in OS.

Highlighting in the Files view covers the JS/TS family, JSON and Markdown (the modes cmEditor.ts bundles); other languages open as plain text.

This set is deliberately asymmetric with the set the server serves as viewable text — .md goes to the rendered viewer rather than the Files view, .txt does the opposite, and dotfiles are server-only. The 45 extensions both sides agree on live in common/sourceExtensions.ts, each side adds its own extras, and test/common/sourceExtensions.spec.ts pins the asymmetry so it isn't "fixed" into symmetry.

Changing this? The routing table is ROUTE_BY_EXTENSION / IN_APP_EXTENSIONS in

src/composables/terminalFilePathLinkProvider.ts. Update this section, the

docs/guide/{en,ja}/features.md row, and the link table in docs/terminal-notes.md

together — all three went stale once already (#834).

What people say after switching

These are experiences reported by users who moved over from an IDE or a split terminal —

not benchmarks, and not claims we measured. Your setup may differ.

"It stopped eating my memory"

Keeping several agents apart by opening several IDE windows is expensive: each one brings its own editor, language server, extensions and file watchers. One user reported a **64 GB machine stuttering** under that load, and running smoothly after moving over — here the agents are PTYs on a server and the UI is browser tabs.

"I stopped answering the wrong agent"

Six panes of scrolling text look identical. Users have described **typing a reply into another agent's terminal**, and losing track of what they had asked in the first place. As one put it, the windows all look the same, so switching between them costs time just to work out what you are looking at.

The problem isn't attention — it's that N identical panes means holding N contexts in your head. Colour-coded state, a name badge and a per-directory colour move that onto the screen instead.

"Watching many and reading one stopped being a trade-off"

Splitting a terminal six ways leaves every pane too small to read a long answer without constant scrolling and resizing — one user described exactly that with a 4,000-character reply. So you quietly accept worse reading every time you add an agent.

Grid ↔ enlarge removes that. Watch all of them, then blow one up and read it properly — the cockpit roster keeps the rest in view as text while you do.

"My existing sessions came with me"

Sessions resume as-is — same claude --resume, same transcripts. Point it at a directory you already work in and your history is there. Nothing to migrate, nothing to redo. One user said this alone made the switch worth it, having previously lost context to killed sessions.

You don't need ten agents for this to pay off. Users have reported the switch being worth it at one to three parallel sessions. The wins above are about not losing track, not about running more.

📖 Documentation — receptron.github.io/mulmoterminal

• User guide: English — the grid

• ユーザーガイド: 日本語 —

• Updates / アップデート情報: new releases and features are announced on X —

Install & run

Needs Node ≥ 22.12, plus these CLIs — on your PATH, or named by the matching _BIN:

Never installed any of this before? The guide walks it end to end, macOS and Windows,

assuming no command-line experience:

Getting started ·

はじめに — 起動するまで

| | Tool | What it gives you | Install | | --- | --- | --- | --- | | Required (unless you declare another) | claude | every Claude session — this app is a cockpit for it. Start-up requires it by default; declare a default agent and it checks that one instead — npx mulmoterminal --agent codex, or "defaultAgent": "codex" in ~/.mulmoterminal/config.json (#2082). CLAUDE_BIN is honoured, so an install off PATH counts | npm i -g @anthropic-ai/claude-code, then run claude once to log in | | Required | git | worktree isolation, each cell's branch / unsaved-dot / diff readout, the PR footer | brew install git · sudo apt install git · sudo dnf install git · Windows: git-scm.com | | Required | gh | the cross-repo PRs & Issues view and one-click PR creation — it uses your gh login, so no token is stored | cli.github.com, then gh auth login | | Optional | glab | the same for GitLab projects (#981) — gitlab.com, and a self-hosted instance you declare in gitlabHosts (#1332). Same arrangement: the CLI holds the credentials, this app stores no token | brew install glab, then glab auth login (self-hosted: glab auth login --hostname gitlab.example.com) | | Recommended | tmux — the latest release (3.8 as of 2026-10-10); older ones are not supported | session persistence — terminals survive a server restart | brew install tmux · sudo apt install tmux · sudo dnf install tmux · no native Windows build (falls back to plain PTYs) | | Optional | any other agent CLI | a cell can run Codex, Antigravity (agy), Grok, Muse, GitHub Copilot CLI or Cursor CLI instead of Claude — install only the ones you use, and a missing one simply fails to start that cell. What each can do is the capability matrix; how to install and pick one is the agents guide | e.g. npm i -g @openai/codex | | Optional | ffmpeg | video rendering from the mulmo-script panel (its plugin ships enabled) | brew install ffmpeg · sudo apt install ffmpeg · sudo dnf install ffmpeg | | Optional | remotion packages | MulmoCast's remotion beats, where Claude Code writes each scene as a Remotion component (mulmocast 2.13.0). Not a dependency of this app: install them yourself, into your home directory so an npx upgrade does not lose them — init reports whether mulmocast can see them | Remotion scenes · 日本語 | | Optional | ollama | claude-ollama — Claude Code against a fully local model | ollama.com/download | | Linux only | a file dialog | the launcher's Choose a folder button and the path menu's Insert a file path, which open an OS dialog on the machine the server runs on. macOS and Windows have one built in; WSL uses the Windows one over interop and needs nothing installed. A Linux desktop needs one of these — without any, they say so and you type the path instead (#1447) | sudo apt install zenity · sudo dnf install zenity · kdialog, qarma and yad also work |

The server starts without any of the non-required rows; you just lose that row's feature, and the header/panel for it says so. git and gh are marked required because losing them costs whole views rather than one button. claude is required only until you name a different default agent — see Starting without Claude Code · 日本語. npx mulmoterminal@latest init (below) reports which of these it can find.

npx mulmoterminal@latest           # start on http://localhost:34567 and open the browser
or install globally:
npm install -g mulmoterminal
mulmoterminal

Stopping it. Ctrl+C in the terminal that started it — or, if you can no longer find that terminal, Settings → Quit MulmoTerminal in the browser, or npx mulmoterminal@latest stop from any terminal (installed globally, just mulmoterminal stop; it stops every server running on this machine, and --port stops only that one). All three run the same shutdown: with tmux installed the agent sessions survive and come back under **Settings → Sessions that survived a restart**; without it they end with the server.

First-run setup (optional). npx mulmoterminal@latest init checks your environment (Node ≥ 22.12 and every CLI in the table above), says how to update when Node is behind the latest LTS of its line or Claude Code is behind its stable release, seeds the launcher's **directory presets** from the projects in your Claude Code history, and writes ~/.mulmoterminal/config.json. It's idempotent — re-run it any time to refresh the presets; it overwrites the managed parts and keeps your other settings. When claude is installed it can hand off to the /mulmoterminal-config skill for interactive tweaks — it routes to the one that owns what you want to change. Once the app is up you can also reach them from Settings: each section that a skill can write ends in a button that starts that skill in a new session, which is how the settings with no UI (a theme of your own, keymap) get written without hand-editing JSON.

Google account (optional). Link a Google account to enable the chat's google tool and the phone's google.calendar.* commands: read/create events on any calendar (not just your primary), list the calendars you've subscribed to, and read the colour palettes. Sign in from Settings → Google account, or run npx mulmoterminal@latest google login — the CLI is the fallback for when you're driving MulmoTerminal from another machine, since consent finishes on a loopback listener and needs a browser on the host. Either way it needs a Desktop OAuth client JSON saved as ~/.secrets/client_secret_*.json; the refresh token lands in ~/.config/mulmo/google-token.json and is shared with MulmoClaude, so one link per machine covers both apps.

Local models (optional). The package also ships claude-ollama — a one-command launcher that runs Claude Code fully locally against an Ollama model (no cloud, no API key). It starts a large-context Ollama server and launches claude with a minimal system prompt so small models aren't drowned:

ollama pull qwen3:4b
npx -p mulmoterminal claude-ollama qwen3:4b   # or, if installed globally: claude-ollama qwen3:4b

See Local models with claude-ollama for the details and model notes.

Already linked before the calendar-list / colour features? They need a read scope your existing

link doesn't have, so listCalendars (and, in practice, colors) fail with an insufficient-scope

403 until you re-authorize: Settings → Google account → Unlink, then sign in again (or re-run

google login). Reading/creating events on your primary calendar keeps working without re-linking.

A global install isn't auto-updated, so on startup MulmoTerminal checks npm and prints a one-line notice when a newer version is available — and the web toolbar shows a clickable update badge with the exact command for your install (npm i -g mulmoterminal, or git pull for a clone). The server repeats that check every few hours, so a release that ships while it is running still reaches the badge; the startup console notice is printed once and is not repeated. Disable with MULMOTERMINAL_NO_UPDATE_CHECK=1 (or NO_UPDATE_NOTIFIER=1).

Options: --cwd

npx mulmoterminal@latest --cwd ./my-project   # work in a specific directory

┌──────────────────────────────────────┐         ┌─────────────────────────────────────────────┐
│ Browser (Vue 3 + xterm.js)            │         │ Server (Express + Node)                       │
│                                       │         │                                               │
│  App.vue ──────subscribe("sessions")──┼──SIO───►│  socket.io  /ws/pubsub   ── publish ──┐       │
│      ▲  refetch on any push (favicon) │         │                                       │       │
│      └──── GET /api/sessions ─────────┼──HTTP──►│  Express   /api/sessions              │       │
│                                       │         │            /api/hook  ◄──curl── hooks │       │
│  Terminal.vue ── ws JSON msgs ────────┼──WS────►│  ws        /ws  ──► node-pty ─► claude──hooks┘
│      (input / resize / output)        │         │                     (one PTY per session)     │
└──────────────────────────────────────┘         └─────────────────────────────────────────────┘