MX Code is a terminal-native environment for running and managing multiple coding agents across different repositories.
It started as a fork of Grok Build, but it very quickly became its own thing. The original idea was fairly simple: I wanted to add support for more coding agents and make the interface fit my workflow better. That then turned into a dashboard where I could see every agent I had running, open any conversation, inspect what it was doing, intervene when necessary, review its work, and let agents communicate with each other when they were working in the same repository.
The main problem MX Code is trying to solve is that coding agents are now spread across completely separate tools. Cursor has its agents, Codex has its own app and CLI, OpenCode has its own interface, Claude has Claude Code, and every new provider seems to arrive with another place where you are expected to manage conversations. That becomes incredibly difficult once you are running more than one agent at a time.
MX Code gives those agents one shared environment. It is not trying to make every provider behave identically or replace the things their individual harnesses are good at. It provides the layer around them: workspaces, session management, plans, reviews, communication, repository awareness, merge handling, and one dashboard where you can see what is actually happening.
The dashboard
The dashboard is the main place where you manage MX Code. It shows every agent inside the current workspace and makes it clear whether they are working, waiting, reviewing, merging, finished, idle, or archived.
You can inspect an agent's current activity without opening the full conversation. If you need more information, you can enter the chat, read what it has done, send another instruction, review its plan, or intervene before it continues. Returning to the dashboard takes you back to the wider view of the workspace.
This matters because once you have three or four agents running, the problem is no longer simply talking to a model. The problem is remembering which agent is changing what, whether one is blocked, whether another has finished, and whether two agents are about to touch the same part of the repository.
MX Code is designed around supervising that whole workflow rather than forcing you to manage every agent through a separate chat window.
Quick chat
From the dashboard you can open a quick chat over the agent list.
It is a lightweight peek into an existing conversation. You stay on the dashboard, see the recent turns and what the agent is doing right now, and you can reply without leaving the wider workspace view. Press Enter to open the full chat when you need the complete timeline, plan, tools, or more room to steer.
That sounds small, but it changes the pace of supervision. Most of the time you only need a glance: is this agent still on track, is it waiting, did it just finish a test run. Quick chat gives you that glance. Full chat is still one keystroke away when you need to go deeper.
Persistent repository workspaces
Every repository gets its own persistent MX Code workspace.
Starting MX Code from one repository opens the workspace connected to that repository. Starting it from another repository creates or reconnects to a different workspace with its own agents, chats, tasks, and state.
The interface itself is separate from the background processes. Closing the TUI does not stop the agents. They continue working in the background, and when you reopen MX Code from the same repository, you reconnect to the workspace exactly where you left it.
That means I can start an agent in the MX Code repository, another agent in PCIFIC, close the interface, and allow both of them to carry on working. When I return, their conversations and progress are still there.
There are also global commands for checking what MX Code still has running and shutting everything down properly:
mx --show-all
mx --quit-all
mx --show-all displays every active workspace that MX Code is currently managing.
mx --quit-all completely stops every workspace, agent, watcher, and background process. Persistent sessions are useful, but there still needs to be an obvious way to see what is running and make sure there are no forgotten processes left behind.
PR Mode and Merge Mode
MX Code is built around two workflows: PR Mode and Merge Mode.
These modes control how an agent finishes and integrates its work. They are separate from whether Git worktrees are enabled. Both workflows can use native worktrees, while worktrees can also be switched off when agents need to operate directly inside the same repository.
PR Mode is the more deliberate workflow. Merge Mode is for faster integration where the agent can merge its own work after completing the necessary checks and coordinating with the other active agents.
PR Mode
In PR Mode, an agent starts inside a native Git worktree, investigates the repository, creates a plan, implements the task, tests the result, commits its changes, and opens a pull request.
The pull request becomes the point where the work is reviewed before it reaches the main branch.
Inside the review panel, you can inspect the original plan, the implementation summary, the full diff, individual commits, changed files, test results, review-agent feedback, unresolved concerns, and the pull request itself. The agent's work remains isolated until it has been reviewed and deliberately merged.
A normal PR Mode workflow looks like this:
Create worktree
→ investigate
→ create plan
→ implement
→ test
→ commit
→ open pull request
→ review
→ merge
This mode is useful when the review process matters just as much as the implementation. It gives every task a focused branch, a clear pull request, and a complete record of what the agent changed and why.
It is slower than allowing an agent to immediately merge into the repository, but that is the point. You can properly inspect the result before accepting it.
Merge Mode
Merge Mode is the faster workflow.
The agent can still start inside its own Git worktree and implement the task in isolation. The difference is that, when the task is complete, the agent can merge the changes itself rather than stopping after opening a pull request.
Inside /config, you can choose whether the agent must ask for permission before merging or whether it can merge automatically once it believes the work is safe.
Before merging, the agent checks the other active sessions working on the same repository. If several agents finish at roughly the same time, they do not all attempt to merge at once.
One of the agents can take on the orchestrator role, inspect the other sessions, and establish an order:
Agent 1: merging
Agent 2: waiting
Agent 3: waiting
Agent 4: waiting
Once the first agent finishes, the next agent updates against the new repository state, checks whether its changes still apply correctly, and then begins its own merge.
Agent 1: complete
Agent 2: merging
Agent 3: waiting
Agent 4: waiting
The orchestrator is not one fixed central agent. Any active agent can step in, inspect what the others are doing, establish the merge order, and then place itself somewhere in that queue.
I originally expected the communication tools to exist without the agents using them very much. What actually happened was that the agents started coordinating their own merges through messages.
In one session, I asked an agent to ignore the normal finish command, merge its work, and watch out for the other active agents. I then asked it to message the other agents with the same instruction. It contacted every session and told them to avoid merging while another merge was in progress.
Agent 1 began merging, while Agents 2 and 3 waited. When Agent 1 finished, Agent 2 started its merge, while Agent 3 continued waiting. The agents had effectively created their own merge queue through conversation.
After every merge, the repository is checked again in its combined state.
This is important because two changes can be completely correct on their own and still break something once they are combined. One agent may rename a type, move state ownership, change an interface, or alter behaviour that another agent depends on.
MX Code therefore does not treat the merge as the final step. The agent updates against the latest repository state, inspects the combined diff, reruns the relevant tests, checks for regressions, and confirms that the result still works before the next merge continues.
This is something I have noticed while using it. The agents often take longer to implement a task than I initially expect. They investigate more, ask more questions, test more thoroughly, and then check everything again after the merge. The result is that, when they finally say the work is finished, it usually just works.
Native Git worktrees
MX Code has native Git worktree support.
When worktrees are enabled, every agent gets its own isolated copy of the repository. It can edit files, compile the project, run tests, make commits, and prepare its changes without constantly colliding with the other active agents.
PR Mode uses that isolation to produce a separate pull request for each task. Merge Mode uses it to let agents work independently before returning their changes to the main repository in a controlled order.
Worktrees can also be turned off.
There are times when it is useful to have every agent working directly inside the same repository, particularly while developing parts of MX Code itself. This is where the communication and repository-awareness features become much more important because the agents are no longer protected by separate worktrees.
Working inside the same repository
When worktrees are disabled, every agent operates inside the same repository and can see the changes happening around it.
Agents can inspect the other active sessions, understand what tasks they are working on, identify overlapping files, and message one another directly. They can warn each other before touching the same area, explain which edits belong to their task, request that another agent commits only its own changes, or ask to be notified when it is safe to continue.
One of the strangest examples happened while several agents were working inside the MX Code repository.
One agent was fixing the dashboard queue-preview interface. Another agent was changing the dashboard layout in some of the same files. The layout agent saw the queue-preview changes, assumed they were unrelated leftovers, and removed them.
The queue-preview agent noticed that its work had disappeared. It had not been explicitly told to coordinate with the other agent, and it had not been given special context about what had happened.
It stopped its own task, inspected the other active sessions, identified which agent had removed the changes, opened that agent's conversation, and sent this message:
I am actively fixing the dashboard peek queued-message UI on the same branch/files. The PeekQueuedPrompt/DashboardPeekSteerLocalQueued edits you removed were mine, not leftovers. Please finish and commit only your bottom-pin hunks, then do not reset/remove subsequent queue-related edits. Message me when your commit is stable so I can reapply safely.
The other agent understood the problem, isolated its own dashboard-layout changes, committed only those changes, opened a draft pull request, and confirmed when the repository was safe.
The first agent then reapplied its queue-preview work on top of the stable commit.
That interaction was not a scripted demonstration. I did not prompt the agent to find the responsible session, enter its chat, explain the ownership problem, request a stable commit, and wait for a handoff.
The agent was given the ability to inspect and communicate with the other sessions, and it decided that messaging the responsible agent was the safest way to solve the conflict.
That was the point where I realised MX Code was becoming more than a way to run several agents at once. The agents were beginning to understand that they were sharing a repository with other active workers.
Agent communication
The communication system allows agents to send direct messages to each other and inspect the other active sessions.
This can be used for practical coordination, such as warning another agent about overlapping files, establishing a merge order, asking another agent to pause, or explaining that a particular set of edits is still live work.
The important part is that the communication is not limited to a rigid central orchestration system. The agents can inspect the situation and decide when they need to communicate.
One agent may notice a conflict and contact the session responsible. Another may take on the orchestrator role when several agents are ready to merge. An agent that is not directly involved can still inspect the activity and understand why another session is waiting.
This behaviour can be funny when you read the conversations, but it is also genuinely useful. It allows agents to solve coordination problems before those problems become destructive Git conflicts.
Launching several agents in parallel is not particularly difficult. The difficult part is making those agents aware that they are not working alone.
The review panel
MX Code includes a full review panel rather than treating review as nothing more than a raw diff.
The panel brings together the information needed to understand whether the work is actually ready. It includes the proposed plan, implementation summary, complete diff, file-by-file changes, commits, tests, command results, pull request information, merge state, review comments, agent timeline, outstanding concerns, and the final review verdict.
A separate review agent can inspect the completed task from a fresh perspective.
The implementation agent understands the decisions it made, but that familiarity can also cause it to overlook mistakes. The review agent starts with fewer assumptions and can question whether the task was actually completed, whether unnecessary files changed, whether the tests cover the new behaviour, and whether a regression was introduced.
The review panel keeps that entire process inside MX Code. You do not need to jump between a terminal, GitHub, a separate diff viewer, and several agent conversations just to understand what happened.
Learn Mode
MX Code also includes a built-in Learn Mode.
Learn Mode works inside the actual repository and uses the current task, plan, diff, and source code as context. It is intended to help you understand what the agent is changing rather than hiding the implementation behind a finished result.
It can explain why a file matters, how a function is called, where state is created and moved, what the compiler is seeing, why an error occurred, how a particular diff changes the program, and how different parts of the repository connect.
I originally started working on MX Code while learning much more Rust, so this became an important part of the product for me. Instead of leaving the repository and asking a separate chatbot to explain a generic Rust concept, I can investigate the exact code and task that the agent is currently working on.
The agent still does the implementation, but I can follow the plan, inspect the code, and understand the decisions being made.
Repository search
MX Code includes file search and repository text search directly inside the interface.
Both are designed to be fast and keyboard-first. You can locate a file, search for a symbol or string, inspect the relevant code, and then return to the agent or review without leaving the TUI.
This is particularly useful when reviewing plans and diffs because you can check the wider repository context rather than relying entirely on the files the agent chose to show you.
Custom themes
MX Code supports complete custom themes.
Themes can change the dashboard, agent states, chats, borders, status indicators, review surfaces, diffs, and the rest of the terminal interface.
The terminal is where I spend most of my development time, so I wanted the interface to feel properly designed rather than looking like an unfinished internal tool. It still needs to remain readable and practical, but there is no reason a terminal application cannot also feel personal and visually considered.
Multi-provider support
MX Code is being designed to work with different coding agents and harnesses, including Codex, Cursor, OpenCode, Claude, Grok Build, and future local or cloud agents.
The aim is not to flatten every provider into the same generic model. Each agent can retain the things its own harness does well, while MX Code provides the environment around it.
That includes persistent workspaces, agent supervision, plans, reviews, repository search, direct communication, merge coordination, and background execution.
I do not want to be forced to choose one company's interface simply because I want to use its agent. MX Code gives those agents somewhere to work together while still allowing them to behave like the tools they actually are.
Why it is in the terminal
MX Code went through several forms before arriving at the current terminal version.
I first explored a native SwiftUI interface. I then tried Electron. Both versions helped me understand the product, but neither of them properly matched how I work.
My development workflow already lives in the terminal. I use repositories, panes, commands, logs, diffs, tmux, cmux, and long-running CLI agents. Building another desktop application meant adding a separate environment on top of the one I was already using.
The TUI version fits the product much better. It can run inside my existing setup, keep agents working after I leave the interface, reconnect to persistent repositories, and provide one place where I can supervise several agents without constantly changing applications.
MX Code has become a terminal-native environment for managing the entire agent workflow. It brings together persistent workspaces, multiple providers, PR Mode, Merge Mode, native worktrees, shared repository coordination, reviews, repository search, Learn Mode, custom themes, and direct agent communication.
The most interesting part is not simply that several agents can run at the same time. It is that they can see what the others are doing, message each other when their work overlaps, wait for safe merge points, and check the repository again after their changes have been combined.