Skip to main content
Glama
README.md
# agentmux

Use any coding agent as a subagent of another — across Codex, Claude Code, Gemini, and more.

> Early alpha. The goal is a small orchestration runtime, not another multi-agent UI.

`agentmux` lets you keep using the coding-agent interface you already like and delegate work to other installed coding-agent CLIs through one MCP server.

```text
Codex / Claude Code / any MCP host
              |
          agentmux MCP
        /      |       \
     Codex   Claude   Antigravity
                      (Gemini)
```

## Current scope

The MCP server exposes a provider-neutral session API:

- `spawn` / `spawn_many` — create one or many agent sessions and start their jobs asynchronously
- `send` — continue the same provider-native conversation
- `whoami` — identify a managed child agent from inherited runtime context
- `message_send`, `inbox`, `message_ack` — persisted, attributed agent-to-agent messaging
- `status` — inspect an agent and its latest job
- `result` / `wait` — fetch results or wait for multiple jobs in one MCP call
- `list` — list local sessions
- `kill` — cancel an active job and stop the session
- `team_create`, `team_status`, `team_list` — group sessions and record supervision
- `providers` — show runtime adapters
- `doctor` — detect installed provider CLIs and versions

Provider sessions are preserved using their native IDs:

| Provider | CLI | Native session ID |
| --- | --- | --- |
| Codex | `codex exec --json` | `thread_id` |
| Claude Code | `claude -p --output-format json` | `session_id` |
| Antigravity | `agy -p --output-format json` | `conversation_id` |

## Main vs subagent

`agentmux` does not hard-code one model as the main agent.

When a team has no `supervisorAgentId`, the interactive MCP host is the control tower:

```text
You
 |
Codex UI                 <- external supervisor
 |
agentmux team
 |- Claude reviewer
 |- Antigravity implementer
 `- Codex researcher
```

A managed agent can also supervise children. Provider subprocesses inherit `AGENTMUX_AGENT_ID`, `AGENTMUX_TEAM_ID`, `AGENTMUX_PARENT_AGENT_ID`, and `AGENTMUX_ROLE`. If that coding agent starts its configured agentmux MCP server, `whoami` resolves the inherited identity and nested `spawn` automatically creates children inside the same team.

Managed agents are team-scoped: they can inspect and send work within their team, read only their own inbox, and stop only themselves or descendants. An external Codex/Claude Code/Antigravity UI has no inherited agent ID and remains the unrestricted control tower. This is a coordination boundary, not an OS-level security sandbox.

Multiple agentmux MCP processes on the same machine can share this state safely. State mutations are serialized with an inter-process filesystem lock and committed by atomic replacement, while each job records the process/instance that owns its running provider subprocess. This allows, for example, a Codex host to discover and resume a session originally created from Claude Code.

## Requirements

- Node.js 20+
- At least one supported CLI installed and authenticated: `codex`, `claude`, or `agy`

## Install from a local checkout

Until the package is published to npm, build a local checkout first:

```bash
git clone https://github.com/seaweedsoup98/agentmux.git
cd agentmux
npm install
npm run build
```

Then register the built stdio server with whichever coding-agent UI you want to use as the control tower.

### Codex CLI

```bash
codex mcp add agentmux -- node /absolute/path/to/agentmux/dist/index.js
codex mcp list
```

Codex CLI and the Codex IDE/desktop surfaces on the same host share Codex MCP configuration.

### Claude Code

```bash
claude mcp add agentmux --scope user -- node /absolute/path/to/agentmux/dist/index.js
claude mcp list
```

Remove `--scope user` if you only want the server registered for the current project.

### Antigravity CLI

Open `/mcp` and add a local stdio server, or add it to `~/.gemini/config/mcp_config.json`:

```json
{
  "mcpServers": {
    "agentmux": {
      "command": "node",
      "args": ["/absolute/path/to/agentmux/dist/index.js"]
    }
  }
}
```

A workspace-only Antigravity configuration can instead live at `.agents/mcp_config.json`.

On Windows, forward-slash paths such as `C:/code/agentmux/dist/index.js` are convenient inside JSON.

## Development

```bash
git clone https://github.com/seaweedsoup98/agentmux.git
cd agentmux
npm install
npm run check
```

Run the MCP server over stdio:

```bash
npm run dev
```

The server stores local session metadata in `~/.agentmux/state.json`. Override that directory with `AGENTMUX_HOME`.

The state store is shared across local agentmux MCP processes. Reads use fresh snapshots; mutations use a process-safe lock plus atomic file replacement. A running job records its owner PID/instance so starting another MCP host does not incorrectly recover or overwrite work owned by a live host.

## Example

Once the MCP server is registered in your host, you can ask the host agent naturally:

```text
Create a team for this task.
Spawn two Antigravity agents to review this repository independently.
Use one Codex agent to compare their findings, then report the consensus.
```

The host remains the control tower. `agentmux` provides the runtime/session layer.

### Agent-to-agent messaging

A managed child can discover itself and its team with `whoami`, then inspect peers with `team_status`.

```text
message_send(
  to_agent_id="<peer>",
  message="I changed the repository interface. Rebase your implementation on it.",
  wake=false
)
```

Messages are persisted before delivery. `wake=false` leaves the message unread in the peer's inbox. `wake=true` additionally resumes the peer's provider-native session when that peer is idle and resumable; if it is busy, the wake fails but the message remains in the inbox.

A wake job is owned by the agentmux MCP process that launched it. A nested managed agent that needs the peer's work to complete should call `wait` on the returned `wakeJob.id` before ending its own turn. A detached broker that lets nested wake jobs outlive their launching host is intentionally left for a later layer.

```text
inbox(unread_only=true)
message_ack(message_ids=["msg_..."])
```

This lets agents communicate without requiring a separate agentmux UI.

## Workspace isolation

Each spawned agent accepts `workspace: shared | worktree | auto`.

- `shared` uses the requested working directory directly.
- `worktree` creates a detached Git worktree under `~/.agentmux/worktrees/<agent-id>`.
- `auto` is the default. Read-only agents share the workspace. A single writable agent normally shares it; parallel writable agents in the same `spawn_many` batch are isolated before they start, and a later writable agent is isolated when another shared writer is already running.

Worktrees are created from Git `HEAD`. To avoid silently dropping local edits, worktree creation refuses a dirty repository; commit/stash first or explicitly choose `shared`. This keeps the normal single-writer workflow simple while making parallel writes explicit and reproducible.

## Access modes

`spawn` accepts a provider-neutral access mode. Adapters map it to the nearest native behavior:

| agentmux | Codex | Claude Code | Antigravity |
| --- | --- | --- | --- |
| `read-only` | `read-only` sandbox | `plan` permission mode | `plan` mode + terminal sandbox |
| `workspace-write` | `workspace-write` sandbox | `acceptEdits` | `accept-edits` + terminal sandbox |
| `full` | `danger-full-access` | skip permission prompts | `accept-edits` + skip permission prompts |

These mappings are intentionally conservative and are not identical security models.

## Design principles

1. Keep the existing Codex, Claude Code, or other MCP-host UI.
2. Treat main vs subagent as a session relationship, not a model property.
3. Preserve native provider sessions instead of flattening everything into stateless API calls.
4. Make workspace isolation optional; `auto` only isolates concurrent writers.
5. Keep the core small. Worktrees, messaging policy, and richer supervision sit above provider adapters.

## Roadmap

- worktree cleanup and merge helpers
- explicit handoff/delegation history across MCP hosts
- message subscriptions / push notifications instead of inbox polling
- streaming progress and richer tool events
- persistent named roles and reusable team templates
- package publishing and one-command MCP registration

## License

Apache-2.0

TDQS

B3.1/5.0

Scored across 17 tools

Disambiguation4/5

Most tools target distinct resources and actions: sessions, jobs, teams, messages, and provider metadata are clearly separated. The main ambiguity is between send and message_send, but their descriptions clarify session continuation versus persisted messaging.

Naming Consistency3/5

Naming is readable but mixes conventions: verb_noun (team_create, team_status), noun_verb (message_send, message_ack), bare verbs (send, wait, list, kill), and nouns (inbox, status, providers). The send/message_send pair is especially inconsistent.

Tool Count3/5

With 17 tools, the server is at the borderline of feeling heavy for an orchestration/mux utility. Each tool covers a distinct concern, but the count is above the typical well-scoped range.

Completeness3/5

The surface covers core session, job, team, and messaging workflows, but there are notable gaps: no way to list all jobs, no team deletion or update, and no session transcript/history retrieval. These gaps can force workarounds but basic orchestration is functional.

Maintenance

ActivityMaintained
ResponsivenessNo issues