Skip to main content
Glama

pmux_agent_start

Launches an interactive agent CLI in a new terminal tab, checks shell readiness via boot echo, and provides a boot ID for confirmation. Wait for readiness before sending commands.

Instructions

Primary agent orchestration tool: create a terminal tab, poll briefly for shell readiness, then send an interactive agent CLI command. ORCHESTRATOR CONTRACT: before launching, ask the user which model/effort (and codex sandbox / claude permissionMode) each subagent should use, unless the user already specified them. Use pmux_send_input/pmux_capture_pane only as low-level fallbacks. Returns recommendedFileOutput: false for read-only/plan agents that should be sent fileOutput:false. Boot verification: returns bootId — by default (bootstrapEcho:true) the CLI is launched with a fixed initial prompt that makes the model print a DONE marker (req=bootId), and a SessionStart hook writes a boot-signal file; verify with pmux_agent_wait_ready {bootId, expectEcho:true}, then send user work from turn=1 (bootstrap consumed turn 0; do not pass expectPrevTurnEnd on turn 1). bootstrapEcho costs one tiny model turn — pass false to skip. codex hook trust (실측 2026-07-08): the FIRST launch that wires the boot hook requires a one-time interactive trust approval in the codex TUI — until approved, boot.fileSeen stays false while the echo still works; treat fileSeen:false + echoSeen:true on codex as this case, not a failure. This is non-blocking: after a successful start return, use pmux_agent_wait_ready before sending work. wait_ready launch_failed is meaningful only after start has successfully sent the command; an idle shell before command send is indistinguishable to the stateless wait tool. Session lifetime contract: keep the tab open until the task is finished, then close it with pmux_close_tab. Codex command: codex --no-alt-screen -s ; Claude permissionMode choices are based on claude 2.1.201 and intentionally exclude bypassPermissions; claude effort maps to the --effort flag (claude >=2.1.202).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional display name for the terminal tab.
modelNoOptional model id. Must satisfy ^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$; invalid values return ToolError.
effortNoOptional reasoning effort. codex: -c model_reasoning_effort=<v>; claude: --effort <v> (claude >=2.1.202).
sandboxNoCodex-only sandbox. Defaults to read-only in the command profile.
providerYesAgent CLI provider: codex or claude.
workspaceIdYesTarget workspace id (from pmux_list_workspaces).
bootstrapEchoNoDefaults to true. Appends a fixed single-line initial prompt (positional arg, auto-submitted by both CLIs) asking the agent to print the bootstrap DONE marker, so pmux_agent_wait_ready with {bootId, expectEcho:true} can verify the LLM actually responds — evidence-based boot readiness. Costs one tiny model turn; set false to skip.
permissionModeNoClaude-only permission mode; bypassPermissions is intentionally excluded.
shellTimeoutMsNoHow long pmux_agent_start waits for the new terminal shell prompt before returning not_shell_ready. Defaults to 5000; max 30000.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations present, so description fully discloses boot verification (bootstrapEcho, bootId, wait_ready), codex hook trust behavior, session lifetime contract, and return hint about recommendedFileOutput. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but all information is necessary; front-loaded with primary purpose. Could be slightly more structured but earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers boot verification, session lifetime, and important behavioral nuances. Missing explicit error handling but sufficient given complexity and no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by explaining bootstrapEcho cost, permissionMode exclusion, codex vs claude command construction, and shellTimeoutMs defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly specifies the tool creates a terminal tab, polls for shell readiness, and sends an agent CLI command. Distinguishes from low-level fallbacks like pmux_send_input and pmux_capture_pane.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit orchestration contract on when to ask user for model/effort etc., and directs to use low-level tools only as fallbacks. Lacks explicit when-not alternatives but offers clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yoway030/purplemux-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server