Taskforce — a Skill that supervises multiple coding CLIs inside cmux

[lhanyun]

I've been using cmux to run multiple coding agents (codex, claude, opencode) at once, and the visibility is great — notification rings, sidebar highlights, the attention panel. But once I scaled past a few panes, I noticed the visibility only goes so far: I still had to manually babysit each agent. Approving permission menus one by one, catching drift before it wasted a run, hand-starting the next CLI when one finished, figuring out whether "done" actually meant done.

cmux tells you which agent needs you; it doesn't decide what to do about it. That gap is exactly what I wanted to close.

So I built Taskforce — a Skill that adds an outer supervision loop on top of cmux. It launches your coding CLIs in cmux surfaces, reads their real terminal tails every ~15s, and lets the host agent (Chief) decide per node: continue / send a key or correction / relaunch an exited worker / complete after verification.

Repo: https://github.com/lhanyun/taskforce
Install: npx skills add lhanyun/taskforce --skill taskforce --agent codex --global

What it does

You describe the workflow in one sentence to your coding CLI:

Use Taskforce. Launch codex to write the architecture design; when done,
launch claude to implement the code; when done, launch opencode to review
the code and tests. Supervise the entire workflow.

Taskforce then:

1. Launches each worker CLI in its own cmux surface (via cmux workspace create)
2. Observes — reads every running surface's real TUI tail (~80 lines) each tick
3. Decides — Chief reviews each node's tail and picks an action per node
4. Verifies — checks goal + implementation + validation before marking done

Workers run independently between ticks. The runtime never kills a live worker for relaunch — it only relaunches after a worker PID has actually exited.

Why it complements cmux

cmux is a terminal built for AI coding agents — notification rings, attention panel, agent session restore, tmux-compat shims so a CLI's own subagent panes become native splits. That covers visibility and per-CLI lifecycle really well. What it deliberately doesn't do is make decisions across CLIs: it won't auto-approve a permission menu, won't send a correction when an agent drifts, won't launch the next CLI when one finishes, won't verify a task is actually done. Those are left to the human.

Taskforce fills exactly that layer — it reads what cmux can show you, and acts on it:

	cmux alone	cmux + Taskforce
Permission menus	Notification ring + "Needs input" chip	Chief inspects command & scope, sends enter for safe project-scoped ops
Agent drift	You notice, Ctrl+C, lose context	Chief sends a text correction to the same TUI, no restart
Sequential handoff	You manually start the next CLI	Next node launches when the previous completes
Worker exit	Session restore / autoresume covers cmux restarts, but no workflow-level exit detection	Chief detects PID exit, relaunches with attempt tracking + recovery context
"Is it done?"	You check the screen	Chief verifies goal + code + tests before complete

It uses cmux's CLI API throughout: workspace create to launch, read-screen/capture-pane to observe, send/send-key to intervene, ping for health checks. CMUX_SURFACE_ID env var is how it tracks each worker. cmux stays the terminal and transport; Taskforce is the decision layer on top.

Design choices worth noting

• No new agent platform. It's a Skill installed into the CLI you already use (codex / claude / opencode / codebuddy). Your existing config, Skills, and model settings stay.
• Screen-hash validation before every send. Re-reads the surface and compares hash before sending — a late decision won't select an option on a menu that already changed (stale_screen).
• Evidence on disk. Every send / relaunch / complete is logged to .taskforce/state/workflows/<id>/decisions.jsonl for post-run review. Ordinary continues are not accumulated.
• Narrow scope on purpose. It's not a model router, role system, or workflow platform — just runtime observation + guidance for coding CLIs.

Where it fits

If a single CLI + its subagents handles your task, keep it simple — Taskforce won't make that better. It's for when you genuinely need different CLIs (different models, tools, configs) to collaborate on one task, and the manual pane-switching and handoff becomes the bottleneck.

I'd love feedback from cmux power users who run multiple agents — especially on:

• Whether send-based permission approval is the right granularity, or whether cmux would rather expose a first-class permission hook for external decision-makers
• Whether sequential auto-handoff (next CLI launches when previous completes) is a workflow you'd actually use, or whether you prefer manual control
• Whether an external supervisor that tracks worker PID exit and relaunches fits how you run multi-agent fleets, or whether that's something cmux would rather own natively

Happy to write up a cmux Agent Integrations doc page if the maintainers think this fits.