Skip to main content
Each AI provider has unique capabilities and limitations. Maestro adapts its UI based on what each provider supports.

Custom Configuration

All providers support custom command-line arguments and environment variables. Configure these in Settings → Providers for each agent type.
Provider configuration showing custom arguments and environment variables

Custom Arguments

Additional CLI arguments are appended to every call to the agent. Common use cases:
  • Claude Code: --model claude-sonnet-4-20250514 to specify a particular model
  • Codex: -m o3 to use a specific OpenAI model
  • OpenCode: --model anthropic/claude-sonnet-4-20250514 to configure the model

Environment Variables

Environment variables are passed to the agent process. Use these for:
  • API keys and authentication tokens
  • Configuration overrides (e.g., CLAUDE_CONFIG_DIR or CODEX_HOME for multiple accounts)
  • Provider-specific settings
The MAESTRO_SESSION_RESUMED variable is automatically set to 1 when resuming sessions - you don’t need to configure this manually.

Switching Providers with Memory and Session Carry

Memory and session conversion is available as a preview between Claude Code 2.1.296/2.1.302 and Codex 0.162.1/0.163.0, in both directions. Live checks on Claude Code 2.1.302 and Codex 0.163.0 verified native conversation recall in both directions, including a message added after switching, and access to carried project resource definitions. Both adapters remain unverified overall: skill execution, subagent invocation, arbitrary tool/image payloads, and repeated incremental synchronization are not certified. Other provider/version combinations have no supported converter and are blocked by preflight. In Edit Agent → Provider, destinations with a converter from the agent’s current provider have a Carry Over pill at the right of the provider list. The hint below the selector uses the same pill. It identifies a declared adapter; Maestro still checks the installed versions and conversation contents before allowing the switch. Conversion is opt-in. Select the destination and check Convert memory and session history to read the conversion plan and see any listed limitations, then click Save Changes; saving accepts them. Translation runs as part of saving. Leave the box unchecked for a plain switch: tabs keep their transcripts and start fresh conversations on the new provider. When a plan is blocked or the conversion fails, a notice says so and Save Changes switches providers without converting. It carries project memory and session history while preserving tabs, drafts, queued messages and file previews. Additional user-level resources, such as skills, must be selected explicitly; account-global knowledge is excluded. A spinner shows when Maestro is reading history, waiting for the current turn, translating, or finishing the switch. The status follows the current migration operation. There is no percentage bar because completion units are not measured. A failed conversion reports the error and retains the source provider. The CLI uses the same conversion operation:
Switch back with --provider claude-code --convert. The second command accepts conversion warnings; it does not bypass a blocked plan. --provider without --convert (or any translation option, which implies it) is a plain switch with no conversion. --dry-run returns the reviewed operation ID as plan.id. Passing it with --migration-plan rechecks the source and scope before applying; changed evidence requires a fresh plan. --migration recover and --migration rollback can also address an operation by ID. Failure or a deferred switch exits nonzero; a command-node pipeline must inspect the reported state rather than treating an accepted request as completed translation. The CLI and desktop must both include this translation protocol. The new CLI uses a dedicated provider_translation request, so an older desktop refuses it instead of interpreting a preflight as the old destructive provider change. A source build does not replace the CLI bundled in an already installed application.

Starting Translation from Cue

Cue can invoke these commands using an existing shell Command node. Use a separate controller agent and trigger after the source agent completes. Replace the two agent-ID placeholders before installing this example:
The example prepares a plan only. Apply a reviewed ID with the second CLI command above. Shell Command nodes already capture JSON output and exit status; structured command.mode: cli currently supports send, so translation uses mode: shell. An applied translation changes the source agent’s active provider. Return switches reconcile intervening history using native lineage and checkpoints. This is not continuous synchronization of two independently active agents, nor an inactive replica update that leaves the source provider unchanged. Independent destination edits currently produce a divergence block rather than being silently merged. Do not schedule alternating provider switches as a substitute for a non-switching sync operation.

Claude Code

Notes:
  • Claude Code’s TUI supports injecting user messages mid-turn (between tool calls in its agentic loop), but this is not available in batch mode (--print). Maestro uses batch mode, so new messages are queued and sent after the current turn completes via --resume. This is a limitation of the CLI’s batch interface, not Maestro.
  • Maestro sets CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 by default for every Claude Code spawn (desktop UI, CLI batch, --live, SSH). This disables Claude Code’s Bash run_in_background + Monitor feature, which is incompatible with Maestro for two reasons: (1) short-lived CLI batch sessions exit before background tasks finish, silently losing results; and (2) the polling wrapper Claude Code generates around each background task can deadlock on a self-matching pgrep -f predicate when the watched command regex appears verbatim in the wrapper’s own argv, leaving long-running desktop tabs stuck on a zsh until loop that can never satisfy its exit condition. Maestro’s multi-tab terminals cover the same use cases (watch a dev server, tail a log) more reliably. To re-enable, export CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=0 from your shell, or set it per-agent under Settings → Providers → Claude Code → Environment Variables.
  • Ask-back questions require Standard permission mode. In Standard mode Maestro injects a permission relay into Claude Code (API mode) that surfaces tool approvals and AskUserQuestion ask-backs as in-app prompts you answer inline. Full Access passes --dangerously-skip-permissions and skips the relay, so an AskUserQuestion call there has nowhere to go: the question never appears and the turn stalls until you stop the agent. A follow-up message won’t recover it either: it only queues behind the stalled turn, which never completes to dispatch it. Read-Only mode also runs without the relay. SSH remote agents can’t use Standard mode at all: a Standard-mode Claude Code spawn over SSH fails loudly (the relay socket is local-only and can’t mediate a remote spawn) rather than downgrading, so SSH agents always run in Full Access or Read-Only, which is why ask-backs never surface there. This is the expected trade-off of bypassing permissions, not a defect; switch the tab to Standard mode when you want ask-back questions to work.

Token Source

A Claude Code agent can run each turn in one of two ways. Pick one per agent under Settings → Providers → Claude Code (or in the New Agent / Edit Agent dialog), and Maestro can show a matching pill on each captured turn. The mode does not decide what you are billed. The agent’s credentials do:
  • Signed in with a Claude plan (Pro, Max, Team): both modes draw from that plan’s 5-hour and weekly limits. Anthropic confirms this for claude -p in Monthly API credits for Max and Team plans.
  • An API key, gateway, or cloud provider (ANTHROPIC_API_KEY, ANTHROPIC_BASE_URL, Bedrock, Vertex) in the agent’s environment: both modes bill that credential instead. A Max or Team plan’s monthly API credits are spent this way, through a key from the linked Claude Console organization.
Dynamic’s switch only buys time when the agent also has an API key. Signed in with a plan alone, claude -p hits the same limit the TUI just hit, and Agent Resilience is what carries the turn to the reset.
Anthropic plans to make --bare the default for claude -p in a future Claude Code release. Bare mode never reads your plan login, so a claude -p agent with no API key would start failing with “Failed to authenticate”. If that happens, switch the agent to TUI Wrapper.
The pill is off by default. Turn it on under Settings → Display → Provider Mode Pill to show it under chat responses and on History entries. When a window does run dry, Agent Resilience takes the turn over: it reads the reset moment out of Claude’s own banner (resets 11:40am (America/Chicago)) and resends your prompt then, instead of leaving you to notice and retype it. The TUI Wrapper and Dynamic modes are powered by maestro-p, a small standalone helper that drives Claude Code’s interactive TUI and hands Maestro the same output claude -p would. It ships bundled with the desktop app, so local agents work out of the box. Like claude -p, maestro-p never stops on a permission prompt: it runs Claude with permissions bypassed, unless the agent is in read-only (plan) mode. A Task subagent’s tool calls show up under the Task card as they run, and each turn reports its cost and per-model usage from Claude’s own tracker.
For SSH remote agents, maestro-p must be installed on the remote host’s PATH, since the TUI runs there rather than on your machine. If it is missing, Maestro disables the TUI Wrapper and Dynamic options and falls back to claude -p. Install it from the maestro-p install page, then click Re-check in the agent’s Claude Token Source panel.

Codex (OpenAI)

Notes:
  • Codex’s resume subcommand doesn’t accept the -i/--image flag. Images can only be attached when starting a new session. Maestro hides the attach image button when resuming Codex sessions.
  • Your custom Codex commands appear in Maestro’s / autocomplete. Maestro reads them straight off disk from <CODEX_HOME>/skills/<name>/SKILL.md and .codex/skills/ (plus <CODEX_HOME>/prompts/*.md on older Codex builds), so no extra setup is needed. CODEX_HOME is honoured, and a project-local command shadows a global one with the same name. A skill marked user-invocable: false is skipped, matching Codex’s own picker.
  • Because Maestro drives Codex through codex exec, the CLI never expands the slash itself. Maestro substitutes the command’s file contents before sending, so the agent receives the fully expanded prompt.
  • Codex’s built-in slash commands (/compact, /diff, /model, etc.) are still unavailable: they are implemented inside the interactive TUI and have no on-disk prompt to expand.
  • Codex commands on an SSH remote agent are not discovered yet, since the skills live on the remote host.

App Server Transport (Experimental)

By default Maestro runs every Codex turn through codex exec. A Codex agent can opt into codex app-server instead, which keeps a live connection to the running turn. That connection is what makes the Steer button available on a queued message: Maestro hands the message to the turn already in progress, and Codex folds it into its work instead of waiting for the turn to end. Turn it on per agent:
  • Agent settings: set Codex Transport to codex app-server in the New Agent or Edit Agent dialog.
  • CLI: maestro-cli update-agent <agent-id> --codex-transport app-server (use exec to switch back).
Only local chat turns use the app server. These keep running on codex exec even with the option on:
  • SSH remote agents
  • Prompts with attached images
  • Auto Run, Maestro Cue, and maestro-cli batch runs
If the app server cannot start (an older Codex build, or a handshake error), Maestro runs the turn on codex exec automatically. Conversations carry over in both directions, because both transports share the same Codex session.

Nonfatal notices

Codex can report configuration notices as item-level error events without failing the turn. In standard desktop agent chats, Maestro displays these as separate STDERR diagnostics even when Thinking is off. They are not assistant answers and do not trigger failure or reasoning-effort retries. Top-level errors and turn.failed events still use normal error handling. These examples show a synthetic warning followed by a successful answer, with Thinking off, in dark and light themes:
Codex warning separate from the successful answer in Dracula

OpenCode

Notes:
  • OpenCode uses the run subcommand which auto-approves all permissions (similar to Codex’s YOLO mode). Maestro enables this via the OPENCODE_CONFIG_CONTENT environment variable.

Factory Droid

Notes:
  • Maestro drives Factory Droid through its droid exec batch subcommand with -o stream-json output. Read-only agents run in the default mode with no auto-approval flags.

Copilot-CLI

Notes:
  • Copilot-CLI is multi-model via models.dev. Maestro maps image uploads to temporary-file @image mentions in the prompt, which also works on resumed sessions.

Hermes

Notes:
  • Hermes is Nous Research’s coding agent. Set a documented model override (for example anthropic/claude-sonnet-4-20250514) under Settings → Providers → Hermes, or leave it blank for the CLI default.
  • On Windows, Maestro passes batch prompts through stdin with hermes chat -Q --yolo --query-file -. The explicit query source keeps Auto Run and tab naming out of the interactive TUI without exposing long prompts to the Windows command-line limit. Hermes must support chat --query-file; update Hermes if your installation does not list it in hermes chat --help.

Pi

Notes:
  • Pi is a customizable agent harness. Maestro uses its JSON output mode and enforces read-only agents by restricting the tool set to read-only tools.

Qwen3 Coder

Notes:
  • Qwen3 Coder is Alibaba’s Qwen Code agent, a Gemini CLI fork. It is multi-provider, so any model id works (for example qwen3-coder-plus or an OpenAI-compatible id); leave the model blank for the account default.

Oh My Pi

Notes:
  • Oh My Pi is a multi-model coding agent, invoked via the omp CLI.
  • OpenCode Agent (in an agent’s settings) picks the primary OpenCode agent for that Maestro agent, running it as opencode run --agent <name>. Use it to keep an agent pinned to a specific persona, model, and instruction set: point one Maestro agent at build, another at a plugin-provided agent, then group chat across them. Plugin agents (for example the ones oh-my-opencode registers) work even though opencode agent list doesn’t print them, since OpenCode resolves the name at run time. The value is stored in that agent’s Custom Arguments, so it is per-agent rather than shared across every OpenCode agent. Plan mode still forces --agent plan and ignores the selection for that turn.