Agent Bridge

Agent Bridge connects two running agent sessions so they can talk to each other directly — say one in your local project and another SSH’d into a related service. The two sides can be any supported agents, so a Claude Code and a Codex can bridge across runtimes just as easily as two of the same. Instead of you copy-pasting context back and forth between two agents, you bridge them once and they collaborate: one asks the other questions, requests research, or shares context, and the replies arrive as new turns in each session. You watch the whole exchange, and you stay the one making the decisions.

Need more than two?

A bridge connects exactly two agents. To let every named agent in a workspace message any other by role, turn the workspace into a Mesh Workspace — the N:M generalization of a bridge, with topics, loop control, and a cockpit.

When to use it

Agent Bridge shines whenever two projects need to talk:

• A client and its API — your frontend agent asks the backend agent about an endpoint’s exact shape instead of guessing.
• Local and remote — bridge a local agent session to one running over SSH on the server it deploys to, so each can answer the other’s questions about the live environment.
• A library and its consumer — the app-side agent asks the library-side agent how a function is meant to be called, and the library-side agent learns how it’s actually used in the wild.

Two related codebases, two agents that each know their own half deeply — Agent Bridge lets them fill in each other’s blind spots without you playing messenger.

Bridging two agents

From a terminal tab running an agent, press Cmd+Shift+L — or right-click the tab in the tab strip and choose Create Agent Bridge… — to open the Agent Bridge picker. Because the entry lives on the tab’s own menu, you can bridge a background agent without switching to it first. Pick another running agent session, and the two are bridged. Candidates are sorted by most recent activity, and a search box filters by tab name, workspace, or working directory — so finding the right peer stays quick even with a fleet of agents running.

The picker offers two modes:

• Fork into new pane (default for agents that support it) — maiTerm forks the chosen session into a split pane right beside your current one. The fork inherits the target session’s full context but runs as an isolated peer, so reaching out to it never disturbs the original. You end up with both sides of the bridge side by side, ready to interact with each. Claude Code sessions fork through Claude’s own session fork; Codex sessions fork through codex fork, which is new in v2.2.0 and lightly travelled — try it before you depend on it. A runtime with no fork of its own isn’t offered as a fork target.
• Connect existing tab — link two already-running agent tabs directly, with no fork and no new pane. This works for any pairing, including across runtimes (Claude Code ↔ Codex). It’s idempotent: re-selecting your current partner repairs a broken link in place, and it won’t hijack a tab that’s already bridged to someone else.

There’s also an optional purpose field. Describe the peer for your own agent — what it’s an expert on, how it should be used — and that context is handed to your agent so it knows what the bridge is for instead of firing off questions blindly.

An agent can ask for one

An agent can ask for a bridge too, with the bridgeWith tool — to connect with another agent’s tab in the same window, or to fork it into a new tab beside itself — and for its bridge to close, with disconnectBridge. Neither happens on the agent’s say-so. Like a mesh change, each only files a request: a card in the Loom’s Decisions and on your paired phone, in maiTerm’s own words, and nothing happens until you click Approve. The phone has no bridge picker, so this is also how you set up a bridge while you’re away from the desk: tell an agent to bridge itself, and approve its card.

The picker’s rules hold: a tab already bridged with a third agent is neither connected to nor forked, and if the asking agent has a bridge already, the card says it closes. When the agent to be forked is over SSH, the copy runs on that host, and the card says so and shows the ssh command it will run through. See what agents can change, and what they ask.

How the agents talk

Once bridged, each agent reaches the other through the sendToBridgedAgent MCP tool. Messaging is asynchronous: a message is injected as a real prompt turn in the recipient’s pane, the recipient works on it, and its reply comes back later as a new turn in the sender’s pane.

Because every message lands as a visible turn in a real terminal, you see the entire conversation as it happens — and you can step in at any point. Hit Esc to interrupt either side, just like any agent session.

Everyone knows their role

The agents are kept fully aware of the situation they’re in:

• They know they’re talking to a peer, not to you. maiTerm stamps each message with the sender’s identity — tab, workspace, and working directory — pulled from its own session registry. An agent can’t fake being the human operator, so the recipient always knows a message came from a peer agent.
• They know you’re still in charge. Rather than letting the calling agent interrogate its new peer unprompted, the opener tells it to check in with you first — summarize what the peer offers, propose a few things it could ask — and wait for your direction before reaching out. You remain the decision-maker the agents defer to.

A tab can be bridged and on a mesh

The two aren’t alternatives. A tab can hold a 1:1 bridge and sit on a mesh workspace at the same time — which happens by default the moment you fork a peer beside a mesh member — and maiTerm routes each message by what the sender actually asked for rather than by which system the sender belongs to:

• A message naming a recipient (and optionally a topic) goes to the mesh.
• A bare message goes to the live bridge if there is one, and to the mesh otherwise.
• A recipient naming the bridge partner goes over the bridge — unless that name also resolves to a mesh peer, in which case the mesh wins, because a mesh send that quietly arrived over a bridge loses its topic, its loop control and its place in the cockpit.

Each message says how to answer it, so an agent never has to work this out: a bridge envelope delivered to a mesh member tells it to reply with no recipient, while its mesh envelopes say the opposite. Underneath, a tab in both has one delivery queue rather than two systems taking turns at the same terminal, so a bridge disconnecting can’t drop messages the mesh had waiting.

Bridges survive restarts

A bridge is durable. The pairing is saved on both tabs, so it survives quitting and reopening maiTerm. On the next launch the bridge is rebuilt automatically, and because an agent can pick up a fresh session id when it auto-resumes, maiTerm re-binds the pair instead of dropping the link. If one side ends its session, the bridge is suspended rather than torn down — when that agent resumes, it reconnects. Only an explicit disconnect or closing the tab removes a bridge for good.

An agent’s claim to its own tab comes back with it: a tab names itself on every request its agent makes, so a restarted or resumed session is bound without anyone typing anything. Addressing a peer speaks under your tab’s name into someone else’s session, so it’s one of the few tools that needs a stated identity rather than a deduced one — if sendToBridgedAgent ever refuses on those grounds (a shell that inherited another tab’s environment, say), run /maiterm init in that session once and retry. See acting as the right tab.

Bridged tabs show a small link badge in the tab bar so you can see which sessions are paired at a glance. To break a bridge, right-click the tab and choose Disconnect Agent Bridge — the same tab menu that offers Create Agent Bridge….

Note

Agent Bridge is part of maiTerm’s agent integration. It needs a supported agent (Claude Code or Codex) running in both tabs, and works over SSH through the same reverse-tunnel MCP bridge that powers the rest of the integration.