What CMUX does
CMUX serves as a command-line interface for managing agent teams within the LifeOS environment, specifically designed for macOS users. It allows developers and designers to boot, race, and monitor multiple agents in a visual workspace, enhancing the ability to observe and interact with agents in real-time. By providing a structured command set, CMUX enables users to orchestrate complex workflows, making it easier to oversee agent performance and facilitate collaboration among team members.
The skill operates through a single command wrapper, which interacts with the cmux application to manage agent workspaces. Users can execute commands to boot teams, conduct races, or monitor agent activities. The system is designed to ensure that agents are visible and manageable, addressing the common issue of dealing with invisible agents that hinder improvement and oversight. With its focus on visibility and control, CMUX is particularly useful for teams working on iterative development processes or those needing to troubleshoot and optimize agent performance.
In addition to its core functionalities, CMUX emphasizes security with a default-deny socket policy, requiring authentication for external processes. This ensures that only authorized commands can control the agent fleet, providing a layer of protection against unauthorized access. The skill also integrates with existing LifeOS components, allowing users to leverage the cmux dashboard while maintaining a clear separation of concerns between the terminal-watching layer and the underlying system.
CMUX is ideal for developers and designers who need to manage multiple agents in a macOS environment, particularly those looking to enhance their workflow through better visibility and control. However, it is not suitable for users on Linux or Windows platforms, nor for those seeking a simple one-off execution of subagents without the need for terminal interaction.
When to use it
Use CMUX when you need to orchestrate and oversee multiple agent teams in a macOS environment, particularly for development and debugging tasks.
When not to use it
Do not use CMUX if you are working on non-macOS systems or if you require simple, one-off executions without the need for a terminal interface.
What you can build with it
Booting a Debugging Team
Quickly set up a team of agents to troubleshoot a flaky test by booting them with specific roles.
Racing Agents for Hotfixes
Execute a race among agents to address urgent production issues, allowing for rapid resolution.
Monitoring Agent Performance
Utilize CMUX to keep track of agent activities and receive updates on their progress, ensuring effective oversight.
How to install CMUX
View source1. Install with the skills CLI
npx skills add danielmiessler/lifeos/CMUX --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by danielmiesslerCMUX
Make cmux the cockpit for every agent — LifeOS's own and your hands-on coding teams. One command boots a named, color-identified workspace of agents you can see, prompt, and steer, because an agent you can't see is an agent you can't improve. {{DA_NAME}} drives them through cmux's real send/read/open-close loop; a poll-based monitor speaks up when they finish.
Everything routes through one wrapper: bun ~/.claude/skills/CMUX/Tools/cmux.ts <subcommand>. It auto-launches the cmux app — but cmux's socket is default-deny, so driving it needs auth (see the first Gotcha).
Status (2026-07-07): built and offline-verified — wrapper is type-clean (
tsc/bun build),voiceworks live, public-clean grep passes, Kitty hooks untouched. Live-driving (boot-team/race/fleet/monitor) is UNPROVEN — it needs the socket-auth handshake, which has not yet executed. To prove it: run the wrapper inside a cmux surface (inherits auth), or set a cmux Settings socket password →CMUX_SOCKET_PASSWORD. Security note: a socket password lets any local process holding it drive your whole agent fleet — set it deliberately and never commit it to a public file.
Workflow Routing
| Trigger | Workflow |
|---|---|
| "boot a team", "3-tier team", "orchestrator/lead/workers" | Workflows/BootTeam.md |
| "race agents", "hotfix race", "throw N agents at this", "needle in a haystack" | Workflows/AgentRace.md |
| "fleet", "2x2 fleet", "named teams", "the remote fleet", "mini-fleet" | Workflows/Fleet.md |
| "watch/monitor my agents", "tell me when they're done", "observe to improve" | Workflows/Monitor.md |
Quick Reference
CT=~/.claude/skills/CMUX/Tools/cmux.ts
bun $CT ping # ensure cmux is up (auto-launches)
bun $CT boot-team --name debug --tiers orchestrator,lead,worker,worker
bun $CT race --feature login-500 --agents 4 # first-to-solve wins
bun $CT fleet --name alpha --grid 2x2 --cmds "claude;codex;claude;bun test --watch"
bun $CT mini-fleet # SSH panes from USER fleet.json
bun $CT send --surface workspace:1/surface:2 "run the tests" --enter
bun $CT read --surface workspace:1/surface:2 --lines 40
bun $CT monitor --workspace workspace:1 # poll + {{DA_NAME}} voice on done
bun $CT flash --workspace workspace:1 # visual attention
The loop that makes it work: send (type a prompt) → send-key Enter (submit — --enter does both) → read (see the result) → close-surface (tear down). That send/read/open-close cycle is the whole programmatic-access story; the recipes are just it, composed.
What stays underneath (not replaced): Pulse (localhost:31337) is still the dashboard, {{DA_NAME}} voice still fires via /notify, the Algorithm/ISA/memory/model-routing are untouched. cmux replaces the terminal-watching layer, not the system. See DESIGN.md for the full feature map and the staged Kitty→cmux migration.
Gotchas
sendtypes but does not submit. cmuxsendputs text in the surface; it does not press Enter. Always use--enter(or a followsend-key Enter) when you mean to run the prompt, thenreadto confirm it actually ran. Asendwith no Enter that claims "the agent is working" is a false done-claim.- The socket is default-DENY — this is the #1 gotcha. Even while the app runs, an outside process gets
Access denied — only processes started inside cmux can connect. Two ways through: (a) run the orchestrator inside a cmux surface — it inherits auth via a taggedCMUX_SOCKET_PATHenv, no password; or (b) set a socket password in cmux Settings and export it asCMUX_SOCKET_PASSWORD(the wrapper passes--password). The socket also only exists while the app runs (cmux.sockabsent when closed). Pick (a) for agent-driven work, (b) for external scripting. - cmux is push-native — prefer hooks over polling. Launch Claude agents with
cmux claude-teamsand cmux auto-injects Claude Code lifecycle hooks (SessionStart/Stop/Notification/UserPromptSubmit/... → cmux claude-hook <event>), so agents report their own status. Also available: tmux-styleset-hook <event> <cmd>, a blockingwait-for -S <name>,pipe-pane --command, and OSC9/99/777escapes.monitor'ssurface-health+read-screenpoll is the FALLBACK for non-Claude agents, not the primary path. - Sidebar metadata is a no-auth Pulse bridge.
report_meta/report_meta_block/set-status/set-progress/logwrite agent status/progress into the workspace sidebar and persist to the session JSON at~/Library/Application Support/cmux/session-*.json— which is readable without the socket. LifeOS reads that file to mirror cmux agent state into Pulse without touching the auth wall. - Mac-only. cmux is a macOS app. The remote fleet still runs LifeOS, but cmux drives it via local SSH panes, not by running cmux on the minis. No Linux/WSL — that path is tmux.
- Refs are positional and can shift.
workspace:1/surface:2indexes move as you open/close things. For anything long-lived, resolve UUIDs (--id-format uuids) fromtreeand hold those. - Public skill — private specifics live in USER config. The remote fleet's hosts come from
~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/CMUX/fleet.json({"hosts":[{"name","ssh"}]}), never from this skill's files. The socket password comes fromCMUX_SOCKET_PASSWORD.
Examples
Boot a debugging team and drive the lead:
User: "boot a cmux team to chase the flaky test"
→ bun $CT boot-team --name flaky --tiers orchestrator,lead,worker,worker
→ bun $CT send --surface <lead-ref> "find why auth.test.ts flakes; delegate repro to a worker" --enter
→ bun $CT monitor --workspace <ws> # {{DA_NAME}} voice when the lead reports back
Race a production hotfix:
User: "prod login is 500ing — race it"
→ bun $CT race --feature login-500 --agents 4
→ (four agents attack the same repo; first with a root cause wins)
→ bun $CT read --surface <winner> ; close the losers
Full reference for the migration and feature map: DESIGN.md.
Frequently asked questions about CMUX
Similar skills
Agent Skill Stack
Assemble compatible AI Agent Skills for workflows.
AI Team Orchestration
Streamline multi-agent development workflows.
Advisor Orchestrator Worker
Efficiently manage complex tasks with multiple AI models.
Agent Orchestrator
Automate multi-agent workflows with zero manual intervention.
Agent Governance
Implement safety and trust controls for AI agents.
Microsoft Foundry
End-to-end management for Microsoft Foundry agents.

