Skip to content

Coding Agents

Coding agents are the heart of LeapMux. Each agent is a real coding-assistant CLI (Claude Code, Codex, and others) running on a Worker, wrapped in a chat tab so you can talk to it, watch its tool calls, approve its actions, and steer it without leaving the browser. This chapter covers which agents are supported, how to open one, how to chat with it, how tool calls render, how to answer permission prompts, and how to change models and settings mid-session.

For where agents live in the workspace layout, see Tabs & Layout. For the git side of opening an agent in a branch or worktree, see Worktrees & Branches. To drive agents from a script instead of the browser, see Remote Control CLI.

Supported agents

LeapMux integrates nine coding-agent providers:

ProviderCLI binary detected on the Worker
Claude Codeclaude
Codexcodex (or codex-x86_64-pc-windows-msvc)
Cursorcursor-agent
GitHub Copilotcopilot
Kilokilo
OpenCodeopencode
Goosegoose
Pipi
Reasonixreasonix

All nine are first-class: each one supports the core workflow — chat, streamed tool calls, permission prompts, and session resume. How much of that workflow you see still depends on what each provider’s CLI exposes. The plan/todo sidebar, for example, only appears for agents whose CLI emits task or todo updates, and resume falls back to a fresh session when the agent’s own resume can’t pick up the prior conversation. The available models, settings, and prompt styles vary from provider to provider (each CLI exposes its own); the rest of this chapter covers those per-provider details.

Which agents you can actually open

A provider only appears in the picker if its CLI is installed on the selected Worker. When you choose a Worker, LeapMux probes its shell for each provider’s binary (command -v <binary>) and shows only the providers it finds.

While that probe is still loading, LeapMux shows a default list of all nine providers, sorted alphabetically by label; once the probe completes, the list narrows to the providers actually installed on the Worker.

If no provider is detected, the picker shows a disabled No agents available button. Install the relevant CLI on the Worker and use the Refresh available providers button to re-probe.

Opening a new agent

Open the New agent dialog from the workspace, then fill in the fields below and click Create (the button shows Creating… while the agent spins up).

Dialog fields

FieldWhat it does
WorkerThe machine that will run the agent. Determines which providers are available and where the working directory lives. See Managing Workers.
Agent ProviderWhich agent CLI to launch. Shows the provider icon, label, and a chevron; a check marks the current choice.
DirectoryThe working directory for the agent, chosen from a directory tree on the Worker.
Resume an existing sessionOptional. Paste a prior Session ID to continue an earlier conversation (see Resuming a session).
Git optionsAppears once a Worker is selected. Lets you start the agent on the current branch, switch branches, create a branch, or create/use a worktree. See Worktrees & Branches.

Note: The dialog has no model, effort, or permission-mode fields. A new agent always starts with the provider’s defaults; you change the model, reasoning effort, and permission mode afterward from the in-chat settings dropdown (see Changing settings mid-session).

LeapMux remembers your most recently used provider and pre-selects it (when it is available on the chosen Worker), so you usually only have to pick a directory and click Create.

Quick-open (no dialog)

If you trigger “new agent” from a tab that already has a Worker and working directory, LeapMux skips the dialog and opens an agent directly, reusing the active tab’s provider (or your most-recent provider). It only falls back to the full dialog when the Worker, directory, or provider can’t be inferred.

Where the new agent lands

The Worker assigns a friendly title from a shared name pool (you’ll see titles like “Agent ”); you can rename the tab later. For how tabs are placed, split, and tiled, see Tabs & Layout.

Chatting with an agent

The chat tab has the conversation transcript above and a Markdown editor at the bottom.

Composing and sending

The editor is a full Markdown editor with a formatting toolbar. Type your message and send it with the Send button (the paper-plane icon) or with the keyboard. While the message is in flight, the Send icon is replaced by a spinner.

Send is disabled when the editor is empty and there are no attachments.

Enter-key send mode

A toggle in the editor toolbar controls what the Enter key does. The two modes are:

ModeEnterModifier+Enter
Enter sendsSends the message(Shift+Enter for a new line)
Cmd/Ctrl+Enter sends (default)Inserts a new lineCmd+Enter (macOS) / Ctrl+Enter (other platforms) sends

The default is Cmd/Ctrl+Enter sends, so plain Enter adds a newline. Click the mode label in the toolbar to switch; the choice is saved as a preference and persists across sessions.

Attachments

You can attach files by clicking the upload (paperclip) button, or by pasting or dropping them into the editor. Pending attachments appear in a strip above the editor. What you can attach depends on the provider:

ProviderTextImagePDFOther binary
Claude Codeyesyesyesno
Codexyesyesnono
Piyesyesnono
Reasonixyesnonono
Cursor, GitHub Copilot, Goose, OpenCode, Kiloyesyesyesyes

Message persistence and offline behavior

Your messages appear immediately (optimistically) and are reconciled when the server echoes them back. If you send while the agent subprocess is still starting, the message is queued and delivered once the agent is ready. Optimistic messages survive a page refresh; if delivery fails, you can retry or delete the message.

Interrupting a turn

While the agent is actively working — and there is no pending permission prompt — an Interrupt button (a square icon) appears. Click it to stop the current turn; it shows Interrupting… while the stop is in flight. LeapMux asks the agent to stop via its native interrupt/cancel mechanism rather than killing the process, so it can wind down gracefully.

Note: The Interrupt button is hidden whenever the agent is waiting on you with a permission or question prompt — answer the prompt instead (see Permission and approval prompts).

How tool calls and results render

As an agent works, the transcript shows its assistant text, its thinking (where the provider exposes it), and a row for every tool call it makes, followed by that tool’s result. The exact set of tools depends on the provider, but you will commonly see:

  • File reads — the file the agent opened.
  • Edits and writes — rendered with a diff. The result toolbar offers a split / unified diff toggle.
  • Bash / command execution — the command and its output.
  • Search / grep / glob — the query and matches.
  • Web fetch / web search — the URL or query and what came back.
  • Todo / plan updates — feed a persistent todo sidebar (see below).
  • MCP tool calls — calls into Model Context Protocol servers the agent has access to, rendered like any other tool call.

Long tool results are collapsible (an Expand button), and most rows have a Copy button. Where it makes sense, a row’s header also offers a Quote button (tooltip “Quote”, pulls the row’s text into the editor as a quoted reply), a Copy Markdown button (tooltip “Copy Markdown”), and a Copy Raw JSON button for debugging. The permission-prompt banner (see Permission and approval prompts) carries its own Copy Raw JSON action too.

Tip: Some rows are intentionally hidden to keep the transcript readable — for example, Claude Code suppresses its internal todo-list and tool-search bookkeeping rows. The information still drives the UI (the todo sidebar), it just isn’t repeated inline.

The todo / plan sidebar

When an agent produces a task plan or todo list, LeapMux shows it in a persistent sidebar with each item’s status (pending, in progress, completed). Codex turn plans, Claude Code’s todo and task tracking, and other providers’ plan updates all feed this sidebar. The list is server-authoritative, so it stays correct across reconnects.

Turn boundaries and notifications

The end of each turn is marked by a divider that may carry a label such as a duration (“Took 2.1s”) or an error (“API Error: 529 …”). LeapMux also surfaces notifications for events like rate limits, context compaction, retries, and settings changes, collapsing repeated or no-op notifications so they don’t flood the transcript.

Permission and approval prompts

When an agent needs your approval — to run a command, edit a file, or proceed with a plan — or wants to ask you a question, LeapMux shows a control request banner directly above the editor. The banner has its own action buttons, and the editor placeholder changes to hint at what to type:

  • For a question: “Type a custom answer…”
  • For any other request: “Type a rejection reason…”

If several prompts queue up, you answer them one at a time. LeapMux de-duplicates requests and remembers answered ones, so a reconnect never re-asks something you already handled.

The exact buttons depend on the provider.

Claude Code

Tool permission — title Permission Required: <toolName>, with the tool input shown as collapsible JSON. Buttons:

  • Reject — becomes Send Feedback if you’ve typed a reason.
  • Allow — approve this one request.
  • & Bypass Permissions — allow this request and switch the agent into its bypass mode (tooltip: “Allow this request and stop asking for permissions”).

Plan review — when Claude Code finishes planning, the banner is titled Plan Ready for Review and lists requested permissions grouped by tool. Buttons are Reject / Send Feedback and Approve. The Approve action includes checkboxes to clear context or switch out of bypass permission mode.

Questions — when the agent asks you something, the banner is titled Agent Question. Single questions show options as radio buttons (single-select, auto-advancing) or checkboxes (multi-select); multi-question prompts show Question N of M with pagination dots. You can also type a custom answer. Footer buttons:

  • Stop — abandon the question (sends a “User stopped” denial).
  • YOLO — auto-fill every unanswered question with “Go with the recommended option.” and submit (tooltip: “Auto-fill unanswered questions and submit”).
  • Submit — disabled until every question is answered.

Codex

Codex approval banners are titled by the kind of request: Command Execution, File Change, Permission Request, or Approval Required, and show the reason, command (collapsible), and working directory. The buttons come from the request itself; depending on the request you may see:

  • Allow — approve this one request.
  • Allow for Session — approve and stop asking for the same kind of request for the rest of the session.
  • Reject — deny the request.
  • Cancel — dismiss the request without approving it.
  • Allow & Remember — approve and remember the amended execution policy for similar commands.
  • Apply Network Policy — approve and apply the proposed network-access amendment.

An & Bypass Permissions option is also available (it switches Codex to Full Auto). Codex’s plan-mode prompt is titled Implement the proposed plan? with Stay in Plan Mode / Send Feedback and Implement Plan.

Pi

Pi shows method-specific dialogs: confirm (Deny / Approve), input (an inline text field; Cancel / Send), editor (an inline textarea; Cancel / Send), and select (uses the shared question UI). Some Pi prompts show a timeout hint (“Auto-resolves in Ns if no response.”).

Other providers

Cursor, GitHub Copilot, Goose, OpenCode, Kilo, and Reasonix render a permission banner whose title comes from the tool call (default Permission Request) and whose buttons come from the options the agent offered. An & Bypass Permissions option appears when the provider declares a bypass mode (Reasonix declares none). Cursor, OpenCode, and Kilo plug in their own richer question handling where they support it.

Changing settings mid-session

The editor footer (when no prompt is active) has a settings dropdown showing the agent’s current model, an effort icon, and mode. Open it to change the agent’s model, reasoning effort, permission mode, and provider-specific options.

Note: Changing the model or effort restarts the agent process (the change is optimistic and rolls back if it fails). Changing Claude Code’s permission mode is live — no restart. For Codex and the other providers, a permission-mode change restarts the agent.

The model picker shows radio buttons for up to 7 models and switches to a searchable list above that.

Reasoning effort and the “Auto” default

Every effort-capable provider defaults effort to Auto — “let the CLI pick.” When effort is Auto, LeapMux omits the effort flag entirely, so older CLI versions that don’t recognize newer effort names still work. You only need to set effort explicitly if you want to force a particular tier.

Plan mode shortcut

For providers that support a plan mode, Shift+Tab in the editor toggles between plan mode and the previous mode. (Goose has no plan mode and doesn’t wire this.)

Per-provider settings

Claude Code — Extended Thinking, Effort, Model (left); Fast Mode, Output Style, Permission Mode (right).

  • Default model Opus (1M context) (opus[1m]); also offered: Opus, Sonnet, Sonnet (1M context), Haiku.
  • Effort tiers depend on the model:
    • Opus and Opus (1M context) offer the full set: Auto, Ultracode, Max, X-High, High, Medium, Low.
    • Sonnet and Sonnet (1M context) offer Auto, Max, High, Medium, Low (no Ultracode or X-High).
    • Haiku has no effort tiers at all — the effort selector is hidden entirely when Haiku is the model, and the Worker never sends an effort flag for Haiku.
  • Permission modes: Default (the default), Plan Mode, Accept Edits, Bypass Permissions, Don’t Ask, Auto Mode.

Codex — Fast Mode, Reasoning Effort, Model (left); Workflow, Network Access, Sandbox, Approval Policy, plus a Bypass permissions button (right).

  • Default model GPT-5.4 (gpt-5.4); also offered: gpt-5.4-mini, gpt-5.3-codex, gpt-5.2-codex, gpt-5.2, gpt-5.1-codex-max, gpt-5.1-codex-mini.
  • Effort tiers: Auto, Extra High, High, Medium, Low, Minimal, None.
  • Approval Policy: Full Auto (never), Suggest & Approve (on-request, the default), Auto-edit (untrusted).
  • Sandbox defaults to Workspace Write (also Full Access / Read Only); Network defaults to Restricted (also Enabled).
  • The Bypass permissions button sets network = enabled, sandbox = full access, and approval = Full Auto in one click.

Pi — a single column with Thinking Level (effort) and Model. Default model gpt-5.5. Pi has no permission mode, no plan mode, and no bypass.

Other providers — a single option group plus a model selector. The trigger label reads <model> · <option>.

ProviderDefault modelDefault modeNotes
CursorautoagentHas plan mode.
GitHub Copilot(CLI default)agentHas plan and autopilot.
Goose(CLI default)autoBypass = auto — Goose’s default mode already is its bypass mode (it has no separate ask-first mode); no plan mode.
OpenCode(CLI default)Primary Agent buildHas plan mode.
Kilo(CLI default)Primary Agent codeHas plan mode.

In the UI you pick these as named radio options (Auto, YOLO, Build, Code, and so on); the literal mode IDs above are only typed directly when driving an agent with leapmux remote agent set --permission-mode.

Reasonix — a Model selector only; it has no permission mode, no plan mode, and no bypass. Default model DeepSeek Flash (deepseek-flash); also offered: DeepSeek Pro, MiMo Pro, MiMo Flash (the MiMo models need MIMO_API_KEY). Reasonix fixes its model at launch, so switching the model restarts the agent. It is text-only — image, PDF, and binary attachments aren’t supported — and still shows per-request approval banners.

Resuming an existing session

To continue a previous conversation, paste its Session ID into the Resume an existing session field (placeholder “Session ID”) in the New agent dialog. LeapMux validates the ID as you type:

  • Input that contains control characters or any of the characters ", \, $, and % produces “Session ID contains invalid characters.”
  • Input longer than 128 characters produces “Name must be at most 128 characters”.

Leave the field empty to start a fresh session.

Once you submit, the Worker resumes the prior session using that provider’s own resume mechanism, picking up where the earlier conversation left off. If a session can’t be resumed, the Worker starts a fresh one rather than failing.

Tip: Session IDs for Claude Code, Codex, and the other CLIs come from those tools’ own session bookkeeping. If you’ve run the same CLI directly in a terminal, you can resume that session inside LeapMux by pasting its ID here.

Resume across restarts and reconnects

Pasting a Session ID is the manual path; most resumption happens automatically. Agent sessions are durable: they resume across Hub restarts, Worker restarts, and client reconnects without you doing anything. When an agent’s process has to be respawned — for example after a Worker restarts or after a model/effort change — LeapMux reconnects it to the prior session using that provider’s own resume mechanism, and the transcript continues where it left off. As with manual resume, if the agent’s own resume fails the Worker falls back to a fresh session rather than dropping the conversation.

Per-provider differences worth knowing

  • Defaults vary by provider. Claude Code starts in Default permission mode (it will ask before risky actions); Codex starts in Suggest & Approve. Both ask before doing dangerous things unless you bypass.
  • Bypass is a deliberate, sticky choice. The “& Bypass Permissions” / “Bypass permissions” actions stop the agent asking for approval for the rest of the session (Codex’s button also opens the sandbox and network). Use them only when you trust the working directory and the task.
  • Attachment support differs by provider (see the attachments table) — every provider takes text and images, but PDF and other-binary support varies.
  • Pi is minimal — model and thinking level only, no permission/plan/bypass controls.
  • Strict provider dispatch. LeapMux never tries to render or encode one provider’s messages with another provider’s code. If a provider plugin is missing it surfaces a clear warning rather than guessing.

Driving agents from a script

Everything in this chapter has a programmatic counterpart in the leapmux remote CLI, which agents themselves can call (the Worker injects credentials into each spawned agent’s environment). The most relevant commands:

# Send a message to an agent tab
leapmux remote agent send --tab-id <id> --message "Refactor the auth module"

# Interrupt the current turn
leapmux remote agent interrupt --tab-id <id> --reason "wrong file"

# Change model / effort / permission mode mid-session
leapmux remote agent set --tab-id <id> --model gpt-5.4 --effort high

# Open a new agent in a tab (provider, model, working dir, worktree, etc.)
leapmux remote tab open --type agent --worker-id <id> --provider "Claude Code" \
  --working-dir /repo --initial-message "Start on the bug fix"

# Answer a Claude-Code-style control request
leapmux remote agent send-control-response --tab-id <id> --content '<raw JSON>'

See Remote Control CLI for the full command tree, entity-ID resolution, and the JSON output contract.

Last updated on