MXterm Pro

Coding agents and Control Room

MXterm Pro starts each agent's own CLI in a real terminal pane and watches its output. It does not install agents: the CLI has to be on your machine already. Control Room is also known as War Room.

Supported agents

MXterm Pro can launch 27 coding agents. The full list is on the Agents page. The table below lists some of them.

Pick agents in the AI agents list when you create a workspace, or switch a pane's agent later from the agent icon at the left of its header. An agent pane starts the command below. Terminal runs no command.

AgentCommandBypass flagState dotsMCP
Claude Codeclaude--dangerously-skip-permissionsYesAutomatic
Codexcodex--dangerously-bypass-approvals-and-sandboxYesAutomatic
OpenCodeopencodeNoneYesManual
GitHub CopilotcopilotNoneNoManual
Qwen Codeqwen--yoloPermission prompts onlyManual
AmpampNoneNoManual
Gemini CLIgemini--yoloYesAutomatic
Cursor Agentcursor-agentNoneYesManual
AntigravityagyNoneNoManual
OMP (Oh My Pi)ompNonePermission prompts onlyAutomatic
Grokgrok--always-approvePermission prompts onlyAutomatic

For Claude Code, Codex, Gemini CLI, Cursor Agent, OpenCode and Grok, MXterm Pro looks for the executable on your PATH and in common install folders (on macOS and Linux, for example /opt/homebrew/bin, ~/.local/bin and ~/.npm-global/bin) and marks the agent Not installed when it finds none. Gemini CLI also counts as installed when a ~/.gemini folder exists. The other agents in the table are always offered; if their CLI is missing, the pane's shell reports that the command was not found. Agents not in the table, such as OpenClaw, OpenClaude, Hermes Agent, Devin CLI, Kimi Code, Aider, Cline, Goose, Crush, Kilo Code, Kiro CLI, Auggie, Autohand Code, Codebuff, Command Code and Continue, are offered in the composer only after MXterm Pro finds their CLI. Settings → Agents shows the installed state of every agent; see Settings.

Bypass Mode

Enable Bypass Mode (Auto-approve CLI permissions) is off by default. Left alone, every agent asks before it runs a command or edits a file, exactly as that agent's own CLI would.

Tick it and MXterm Pro starts Claude Code with --dangerously-skip-permissions, Codex with --dangerously-bypass-approvals-and-sandbox, and Gemini CLI and Qwen Code with --yolo, and Grok with --always-approve. Those agents then run commands and edit files without asking you first, and Codex also skips its sandbox.

The box is on the workspace composer, the screen a new tab opens with. The choice is saved and applies to every agent pane started after that, in any workspace. Agents that are already running keep the flags they started with.

The flag is added or removed when the pane starts, so the box governs every flag-based agent equally. Besides the five above, MXterm Pro knows a skip-approval flag for OpenClaude, Hermes Agent, Devin CLI, Kimi Code, Aider, Crush, Kiro CLI, Autohand Code and Command Code, 14 agents in all. Goose has no flag: its auto mode is an environment variable (GOOSE_MODE=auto) offered only in Settings. The other agents, including OpenCode, GitHub Copilot, Amp, Cursor Agent, Antigravity and OMP, start with their plain command either way; guessing a flag for them would only make the CLI refuse to start.

Agent state and notifications

For Claude Code, Codex, Gemini CLI, Cursor Agent and OpenCode, MXterm Pro reads the pane's screen to tell what the agent is doing. It shows a dot next to the pane in the sidebar terminal list and in the Control Room (formerly War Room) member list, and on the workspace tab, which shows the most urgent dot among its panes. OMP, Grok and Qwen Code are read for one thing only: when one shows a tool waiting for your approval, its dot turns red. MXterm Pro has no rule for their working state. Gemini CLI is read at its approval, plan, question and folder-trust dialogs. Goose is read as well, with rules that have not been checked against a real session. In all, 9 of the agents have state detection; the others show no dot.

  • Red: the agent is blocked and needs your input.
  • Yellow: the agent is working. Other panes show the same yellow dot while they print output.
  • Green: the agent finished while you were not looking at that pane. It clears when you focus the pane.

Notification settings are in Settings → Notifications, under the master switch Agent notifications. Three events can notify, each with its own switch, all on: An agent finishes, An agent needs your input and An agent stops unexpectedly. Control Room messages that stay held (see Sending messages in Control Room) also raise a banner, Messages waiting to be sent, under the An agent needs your input switch.

SettingDefaultWhat it does
Sound NotificationsOnA chime when one of those three things happens.
System Desktop NotificationsOnA banner titled with the tab and the agent, such as my-project · Claude Code, and a body of Finished, Needs your input, Stopped unexpectedly or Messages waiting to be sent.
Only when MXterm Pro is in the backgroundOffOff means you also get a banner for a pane in another tab while you are working in this window. On limits banners to when the app is not focused.
Show terminal text in bannersOffAdds the agent's terminal title to the banner. Off, the banner ends click to open instead. Notification Center keeps banners and can show them on the lock screen, which is why this is off.
Dock badgeOnA count of panes waiting on you: finished and not yet looked at, or needing input. Built for the macOS Dock; the badge has not been verified on Windows or Linux.
Per Agent NotificationsOn for eachOne switch for each agent that has state detection.

Clicking a banner takes you to the pane it was about. The window comes forward, the right tab opens, a pane hidden behind a maximized sibling is restored, the pane takes focus and it scrolls to the latest output. If the pane has been closed since, the window still comes forward and nothing else happens.

Click-to-pane needs the macOS app you downloaded. On other systems MXterm Pro asks the system to show the banner, but a click is not wired to take you to the pane. This has not been verified on Windows.

A few rules keep banners quiet. You are never notified about the pane you are looking at. A finished turn shorter than 5 seconds earns its dot but no banner and no chime. Events arriving close together are collected and delivered as one chime and one banner. And on macOS, looking at a pane pulls its banners back out of Notification Center.

MCP connection and the Claude status line

MXterm Pro runs an MCP server on 127.0.0.1 with a random port and sets these environment variables in every pane: MXTERM_MCP_URL, the server address, and MXTERM_SESSION, a token unique to that pane, plus the older names SWARMTERM_MCP_URL and SWARMTERM_SESSION with the same values, which the agents' config entries below read. Agents use the server to open a web preview beside the pane, to talk in Control Room and, in workspaces with worktree isolation, to create and remove worktrees.

The tools are named mxt_room.*. Versions before 1.1.43 named them war_room.*; those names still work for now.

Claude Code, Codex and OMP are connected automatically, and Gemini CLI when its pane starts. On every launch MXterm Pro checks these files and writes the entries when they are missing or out of date, whether or not the agents are installed:

  • ~/.claude.json (or $CLAUDE_CONFIG_DIR/.claude.json): an mxterm entry under mcpServers that reads the URL and token from the pane's environment. When it writes that entry it also adds "crossSessionInbound": "accept" if the key is not set.
  • ~/.codex/config.toml (or $CODEX_HOME/config.toml): an [mcp_servers.mxterm] table with the current server URL and no token: each Codex pane that MXterm Pro starts sends its own, so several Codex panes can join a room. The URL is rewritten each launch because the port changes.
  • ~/.omp/agent/mcp.json: an mxterm entry under mcpServers that reads the URL and token from the pane's environment, the same as Claude Code's, plus a $schema line if the file has none.
  • ~/.zshrc, only if the file exists and does not mention SWARMTERM_SESSION yet: the line export SWARMTERM_SESSION="${SWARMTERM_SESSION:-global}" is appended.

Gemini CLI cannot read environment variables in its MCP settings, so it is set up differently. Each time a Gemini CLI pane starts in a folder, MXterm Pro writes <folder>/.gemini/settings.json with the server address and that pane's own token as plain text, and adds .gemini/settings.json to the folder's .gitignore, creating the file if there is none. Grok reads the mxterm entry in ~/.claude.json, so MXterm Pro writes nothing more for it. Settings → Agents shows which agents MXterm Pro treats as set up.

Other agents are not set up automatically, and MXterm Pro has not verified whether they pick up its tools. If an agent shows none, add an HTTP MCP server with the URL $MXTERM_MCP_URL and the header Authorization: Bearer $MXTERM_SESSION. Read both from the environment instead of copying the values, because the port changes on each launch and the token differs per pane.

The Claude Code status line integration is on by default. On every launch MXterm Pro sets statusLine in ~/.claude/settings.json (or $CLAUDE_CONFIG_DIR/settings.json) to type: "command" with a command that runs the MXterm Pro executable with --statusline. Claude Code then shows mcp ✓ (connected), mcp … (server reachable, Claude has not called it) or mcp ✗ (unreachable), followed by context use such as ctx 84k/200k 42%. The setting is user-wide, so Claude Code in other terminals shows the context part too. A custom statusLine you already have is never overwritten. Turn it off in Settings → Terminal → Manage Claude Code's status line, which removes the entry.

Git worktree isolation

Check Isolate features in git worktrees on the workspace composer to give each agent pane its own worktree and branch. It is off by default and applies only to the workspace you are creating.

  • Each agent pane gets a branch such as swarm/brave-otter and a worktree at <folder>/.worktrees/swarm-brave-otter. The branch name shows in the pane header.
  • Plain Terminal panes stay in the folder itself. So does an agent pane whose worktree could not be created.
  • Worktrees start from the current HEAD commit. Uncommitted changes and ignored files such as node_modules are not copied, so install dependencies in each worktree.
  • MXterm Pro adds .worktrees/ to the folder's .gitignore, creating the file if needed, and does not commit that change.
  • Agents in the workspace can call the MCP tools worktree.spawn, worktree.list and worktree.remove.
If the folder is not a git repository, MXterm Pro does not create one. Isolation is skipped for that workspace and every pane shares the folder directly; each pane says so once, in a bar you can dismiss: This folder isn't a git repository, so this pane shares it directly with the others (no worktree isolation). Nothing is initialised, staged or committed. A folder that *is* a repository but has no commits yet still gets an empty .gitkeep, and MXterm Pro stages and commits only that file as "Initial commit" (other files already in the folder are not staged), because a worktree needs a commit to branch from.

To remove worktrees when you are done with them, open the right panel's Git tab and click Clean up worktrees… next to the worktree list.

  1. Entries whose directory is already gone are pruned straight away, with no confirmation.
  2. The rest open in Clean up worktrees. Worktrees with no uncommitted files are only counted ("N worktrees will be removed (directory and branch).") and are removed when you confirm.
  3. Worktrees with work in them are listed separately under These have unsaved work — tick to remove anyway:, each showing how many files are uncommitted and how many commits are unmerged. They are not ticked for you.
  4. Clear worktree (or Clear N worktrees) removes each directory and deletes its branch. A pane still running in one is moved out first.

The worktrees MXterm created are also listed, with size and age, in Settings → Agents (see Settings); that card removes a folder only when you press Remove and always keeps the branch. You can still do it by hand with git worktree list, git worktree remove and git branch -d from the folder. An agent can also call worktree.remove, which refuses when the worktree has uncommitted changes and leaves the branch in place.

Review notes on a diff

The right panel's Git tab shows the changes in the folder or worktree as a diff. You can leave a note on a line of it and hand the lot to the agent that made the changes.

  1. Hover a line in the diff and click the note icon — Add a note on this line, or Edit note on a line that already has one.
  2. Type the note. mod+Enter saves it, Esc cancels.
  3. When you have written what you want, click Send N notes at the foot of the diff. Clear all notes throws them away instead.

Each note reaches the agent as its file, line, the code on that line, and your comment. The block is pasted into the agent's pane but not submitted — the app tells you to press Enter in the pane yourself, so you can add to it first.

Sending is refused, with the reason shown on the button, when the app cannot tell which pane to send to or the pane is not ready: no agent pane is working in that worktree, several are, the pane is not running, it has input you have not sent yet, or it does not accept pasted blocks. The typing rule is the same one Control Room uses.

Notes live in memory for as long as the app is open. They are never written to disk, and a note disappears when its line or its file leaves the diff.

Chat view (experimental)

Chat view shows an agent pane as a readable chat of the agent's own conversation, drawn over the terminal. It is off by default. Turn it on with Chat view (experimental) in Settings → Terminal.

  • It works for Claude Code, Codex, OMP and Grok. For another agent, or a plain shell, the pane says Chat is not available. It is not offered on SSH panes.
  • With the setting on, agent panes open in Chat. Each pane keeps its own choice, which is remembered across restarts. The button in the pane header or mod+Shift+J switches the focused pane between Chat and Terminal. Turning the setting off returns every pane to its terminal.
  • Chat is an overlay. The terminal process underneath is not touched either way.
  • In the composer, Enter sends and Shift+Enter adds a line. You can attach files, paste images and pick the model from a menu.
  • For Claude Code and Codex, a permission prompt that MXterm Pro recognises shows Approve once and Reject and stop the agent. For other prompts the chat says the agent is waiting in the terminal.
  • The microphone button in the composer is a mockup. It records nothing, asks for no microphone permission and inserts no text.

Control Room: rooms and members

Control Room lets agents in different panes message each other, with you as the Moderator. Press ⌘⌥B on macOS or Ctrl+Alt+B on Windows and Linux to open the right panel, then pick the Control Room tab. The panel has five tabs: Control Room first, then Explorer, History, Git and Preview. Control Room is the only one with its name written next to its icon, the crossed swords; the other four are icon-only, with the name in a tooltip. The panel opens wider on the Control Room tab. Each workspace tab has its own room, and the panel shows only the rooms of the tab you are looking at, its main room first. Rooms of other tabs sit under an Other rooms menu.

Add a pane with the Control Room button (connected nodes) in its header — adding a pane opens the panel on the Control Room tab for you, so you do not have to open it first. The button shows a small + while the pane is in no room and, once it is, takes the pane's own colour. A small mark beside the icon shows the state of the pane's messages: a solid dot for new messages, a hollow ring while messages wait until the pane is free, a diamond when a task was handed to it, and a dot in a ring when older messages were skipped because the queue was full. Hover the mark for its text. The button is not shown on SSH panes, on a pane attached from Machines (it runs no terminal on this machine, so it cannot join a room), or on very narrow panes. Dragging a pane onto the panel does not add it.

  • Add to Control Room, or Add to "room name" for an existing room, adds the pane and opens the panel.
  • New room creates a room and adds the pane to it.
  • For a pane already in a room, the menu lists the other rooms under Switch Control Room (pick one to move the pane) and offers Leave Control Room, which asks once more before it removes the pane (the session keeps running). A pane belongs to one room at a time.

A pane's right-click menu has Copy pane ID. For a pane that is in a room and already has a handle, it also has Copy room handle, which copies it with the @, such as @claude-2, and Mention in room, which adds that handle to the room's composer.

In the panel, the selected room tab and the selected Members or Discussion tab are filled in, so the one you are on is easy to see. The room strip adds a room with +, renames one when you double-click it or click the pencil icon that shows when you point at it, and deletes one with its ✕ (a tab's main room has no ✕ and cannot be deleted). Members lists the panes in the room. Click a row to jump to that pane; selecting its name or folder to copy it does not jump. Right-click a row to rename the pane. Each row has a copy button, which copies the member's handle, such as claude-2 (the value an agent puts in to), a crown button that sets or clears the coordinator (see Control Room: the coordinator), and a ✕, always visible, that removes the pane from the room after asking once more. A phone, or another computer through its Machines panel (see Panes and splits), whose Can manage Control Rooms switch is on here (see Remote Access & Devices) can also make a room, add members, remove a member and delete a room from its own screen, under the same Free limits; a tab's main room cannot be deleted.

The Add button at the top of Members lists the panes of the room's own tab first, then the panes of other tabs under their tab names, so agents from other tabs can still join. Plain SSH panes, which cannot run an agent, and panes attached from Machines are not listed. A pane already in another room is greyed out with Already in "room name". Click a row to tick it, then press Add N; Select all and Clear change every tick at once, and the + at the end of a row adds just that pane straight away. Adding three or more panes at once asks first (Add N panes to "room name"?). If some panes cannot join, for example because the room is at the Free limit, a note under the button says how many and why, for about 12 seconds.

A member leaves a room through its ✕, through Leave Control Room in its pane's menu, when you move its pane with Switch Control Room, when its room is deleted, or when its terminal ends. Dragging a row does not remove it. The Discussion records each departure and, when it knows why, ends the line with the reason: (its pane left this window), (removed from the Members list), (left from the pane menu), (its terminal ended) or (its pane was not reopened).

Rooms and their members are saved. After you quit and reopen the app, each member whose pane is restored is back in its room, shown as no handshake until its agent calls mxt_room again. A member waits in the list as Waiting to reconnect for up to 5 minutes for its pane to come back; if the pane does not, the member leaves the room. When an agent exits back to its shell prompt, MXterm Pro notices within a few seconds (it checks every 3 seconds, on macOS and Linux only) and marks the member disconnected, and the Discussion says <name> disconnected (its agent exited). The member stays in the room and its claims are released. Messages are no longer typed into its shell, and a broadcast skips it. It connects again when the agent is started and calls mxt_room again.

When you add an agent pane, MXterm Pro types a short introduction into the agent's prompt that tells it to call mxt_room.list_peers. A pane cannot pose as you: a pane whose name contains "Moderator", in any letter case, joins as (pane, not the real Moderator) followed by its own name, and a name that claims the coordinator role is prefixed (pane, not the coordinator) the same way. When an agent that already saw the rules joins a room again, it gets a single line naming the room and the coordinator instead of the full introduction. Until the agent makes its first mxt_room call, the member shows no handshake and cannot receive messages. A plain shell never makes that call, and agents without automatic MCP setup need the manual setup above. The MCP server tells agents not to call mxt_room tools unless you added their pane to a room, and a call from a pane that is in no room fails with an error asking the agent to have you add it. A connected member shows idle when MXterm Pro cannot read its agent's state (the state is unknown, or the pane has no state detector) and it has made no mxt_room call for more than five minutes.

A pane without a name of its own gets a name and a handle made from its agent and a number, for example Claude 2 and claude-2. The agent is the one the pane was opened as or, for a plain terminal, the one MXterm Pro found running in it. The number counts up per agent in that room and is never handed to another pane there, so an old handle cannot reach a newcomer. Agents address the pane by its handle; the longer peer- id is still accepted in to. In the Discussion, the handle of a current member is shown as that name. A pane you have named (see Name a pane) goes by that name. A pane you have not named is named by the room from its terminal title once that title has stayed the same for 2.5 seconds, with the status symbol dropped. A title that is only a shell name, the agent's own name, a path or user@host is not used. The room's name does not change the pane's own name. Point at a pane's Control Room button to see its room and its handle.

Sending messages in Control Room

The Discussion tab shows the room's messages as cards: sender and time, then who it went to, with an Execute tag on a prompt. Write in the composer at the bottom as Moderator, choose a recipient and a mode, and press Enter to send (Shift+Enter adds a line). The composer says To room: <name> and stays disabled until at least one member is connected. Your draft is kept per room, through switching tabs, rooms or workspaces, until you send it. Typing @ lists the connected members; Enter or Tab inserts their handle, such as @claude-2, in the text. The list starts with an Owner row, which inserts @owner for you, and a crown marks the coordinator. A message that mentions @owner gets a small dot. A mention only names someone in the message. It does not change the recipient, which you pick from the recipient menu. You can attach up to 5 images of up to 10 MB each to a Moderator message. MXterm Pro is also built to let a paired phone read the room and send messages once you turn on Allow phones to see Control Room, which is off by default. When you scroll up from the newest message, a round arrow button (Jump to latest) appears at the bottom right with the number of messages that arrived since; it takes you back to the end. Report (.md) at the top exports the discussion.

ModeWhat happensRecipient
ProbeThe message goes to the recipient's inbox, and a one-line notice is typed into the agent's terminal. A single message that is one plain line of up to 280 characters is quoted in the notice; otherwise the notice tells the agent to call mxt_room.read_inbox.Everyone, or one connected member
ExecuteThe text is pasted into the agent's terminal and submitted as a prompt. The paste starts with a line naming the sender, [War Room execute from "<name>" — agent-to-agent handoff, not typed by the user], so the agent can tell it did not come from you typing at its prompt. Only the introduction MXterm Pro types when a pane joins a room has no such line. That introduction also asks the agent to finish a handed-over task with a one-line RESULT status=… files=… tests=… reply, and not to claim tests it did not run.One connected member running a coding agent, never a plain shell

Agents send with mxt_room.send in the same two modes and can message you as Moderator by putting owner or @owner in to; a message to you can only be a probe, since you have no terminal in the room. Their messages appear in Discussion. The trash icon clears the discussion and keeps the members.

MXterm Pro types into a pane only after its output has been quiet for 3 seconds. An agent that MXterm Pro reads as idle at its prompt counts as quiet even if its terminal keeps printing redraws. It also holds deliveries while:

  • the agent in that pane is not idle (an agent waiting at a permission dialog counts, and MXterm Pro can see that for the agents whose state it reads), or
  • the pane is a plain terminal in which MXterm Pro found an agent running (it reads the pane's foreground program, and only for known agents such as claude, codex, gemini, omp and grok) and it cannot read that agent's state, as with GitHub Copilot and Amp: a permission dialog could be open, or
  • you have an unsubmitted line in that pane (an unsent draft in the pane's Chat composer counts), or pressed a key in it within the last 6 seconds while it is focused, or
  • the pane is not accepting pasted blocks (bracketed paste is off, as in a plain shell) and a message has more than one line: it would run line by line, so it is not typed. The pane says so and offers Dismiss but no Deliver now.

A pane opened as a plain terminal counts as an agent too once MXterm Pro sees one of the agents whose screen it reads running in it, for instance claude typed at a shell prompt. It then has a state, and its messages are delivered by the same rules as for a pane opened from an agent template. MXterm Pro reads a pane's foreground program on macOS and Linux. It does not read it on Windows, so there a plain pane stays a plain pane however you start an agent in it.

While messages are queued the pane header turns amber. When they are held, the pane shows how many messages are waiting with a Deliver now button, and the room tab shows ⏸ with the count. The member's row in Members shows ⏸ and the count as well. Deliver now sends them even if the agent is busy or you are typing, but still waits for the pane's output to go quiet. While the agent is working and the pane is still printing, the pill has no button and reads Waiting for the agent to be free; after you press Deliver now it reads Sends when the agent is free. A hold that lasts 10 seconds raises one Messages waiting to be sent banner, then at most two reminders 2 minutes apart, until the queue is empty.

Next to it, Dismiss (✕) drops the queue without typing anything. A queue of notices goes in one click, and the messages stay in the agent's inbox. A queue that holds an Execute asks for a second click (Discard?), because that text is pasted and is kept nowhere else; the sender is told it was dismissed. A notice that has gone stale, because the agent has already read every message it announces, is dropped instead of typed.

mxt_room.list_peers tells each agent who is in the room. Each peer has a state (working, blocked when waiting at a permission dialog or a question, done, idle, or none when MXterm Pro cannot read that pane) and agentSource, which says whether the pane was opened as that agent (template) or MXterm Pro saw the agent running (process). The Moderator seat carries isModerator: true; that is the only field that identifies the person driving the app, since a pane's name can say anything. The room's coordinator, if you have set one, carries isCoordinator: true.

Called with changesOnly: true, mxt_room.list_peers returns only the peers whose entry changed since that agent's last call. Its long explanatory note comes only with an agent's first call. A peer's unreadFromYou says how many of your messages it has not seen yet, and is absent when there are none. A message counts as seen once the peer has read it with mxt_room.read_inbox, once a notice that quoted it in full has been typed into the pane and submitted, or once the peer has replied to you. A message seen the second or third way stays in its inbox until the peer reads it. The descriptions of the Control Room tools that agents receive are shorter, so agents spend fewer tokens on them.

An agent that has been away can call mxt_room.digest for a short summary of its own room: the messages aimed at it that it has not answered, the most recent messages, who holds which files and who is blocked. It only reads: it does not clear the agent's inbox, and it never shows another room.

Control Room: the coordinator

You, as Moderator, can make one member the room's coordinator. Point at the member's row in Members and click the crown button (Make coordinator). Click it again (Remove coordinator) to clear the role. Only you can set it, from the app. An agent cannot, and a pane name cannot claim it.

  • A room has at most one coordinator. Making another member the coordinator replaces the first, and the role ends when that member leaves the room.
  • In a room with a coordinator, only the coordinator and you may broadcast, meaning a message with no recipient. Every other member must send to one peer, usually the coordinator. The app refuses any other broadcast with an error that names the coordinator. Handing over a task with execute is limited the same way, while any member can still send a probe to one peer. In a room with no coordinator, each agent can broadcast at most 3 times per 60 seconds, and a broadcast is refused when more than 12 peers are connected; one-to-one messages are not affected.
  • Setting or clearing the role sends every member an automatic message and adds a line to the Discussion, such as <name> is now the coordinator. The message also says that push, deploy, release and delete still need a message from you (fromModerator: true): the coordinator only proposes. An agent that joins later is told who the coordinator is in its introduction.
  • mxt_room.list_peers marks the coordinator with isCoordinator: true. Like isModerator, it comes from the role, not from a name.

Reserving files with claims

Two agents can end up changing the same file. To avoid that, an agent reserves files or folders with mxt_room.claim before it edits them, up to 10 in one claim. If any of them is inside a claim that another peer still holds, the claim is refused and the answer names who holds it. A claim is a notice only: it does not stop anyone from writing to a file.

A claim lasts 15 minutes after its owner's last mxt_room call. It also ends when the owner leaves the room, when its agent exits back to a shell prompt, or when you click the ✕ that shows on its lock line in the Members tab when you point at the row, which releases all of that member's claims and is the way out for an agent that is stuck and holds files another one needs. A member can hold at most 5 claims.

In the Members tab, a member that has a claim shows a lock line under its name.

Control Room limits

  • By default the Free plan lets a room hold 2 panes; adding a third opens the upgrade prompt. Free also allows one Control Room with members at a time: a room with no members does not count, so you can still create as many rooms as you like, but putting a pane into a second room while another one has members opens the upgrade prompt. Moving the only member of a room to another room is allowed. The app itself enforces both limits. mxterm.net can set different numbers. A change applies to panes added later and does not remove members or rooms you already have. Pro has no limit on either. See pricing.
  • Each agent can send at most 20 messages and claims per 60 seconds; the Moderator is not limited.
  • A message can be at most 8,192 bytes.
  • An inbox keeps the latest 50 messages in memory and drops older ones. Across a restart, MXterm Pro keeps at most the newest 20 unread messages per member, 256 KiB in total, and nothing older than 24 hours.
  • If the MCP server fails to start, Control Room is unavailable for that run and adding a pane fails.

Ask AI about MXterm Pro

Open a live answer in ChatGPT, Claude or Perplexity, based on this page. The assistant writes it, not us, so check the sources it cites.

Question sentHow do I run Claude Code, Codex and other agent CLIs in MXterm Pro, and what does the Control Room do?