NTM (Named Tmux Manager)
Turns tmux into a local control plane for multi-agent software development: session orchestration, work triage, safety approvals, and automation surfaces in one Go binary.
- Source repo
- Dicklesworthstone/ntm
- Stars
- ★ 461
- Last updated
- today
- License
- NOASSERTION
- Primary language
- Go
- FA score
- 73/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A solo developer running 3-5 Claude/Codex panes on one project who wants a unified dashboard and command palette instead of raw tmux pane wrangling
- Not a fit if
- Teams that need native Windows support
- Users unwilling to install tmux and optional external tools
- Source review
- 73/100 · Some gaps
What does this agent do, and when should you use it?
NTM is a pure-Go single binary that wraps tmux as a control plane for running multiple AI coding agents in parallel. It spawns labeled agent panes (Claude, Codex, Antigravity, Grok Build, with Gemini as legacy) inside named tmux sessions and exposes a dashboard and TUI command palette. Beyond session management, it integrates graph-aware work triage and auto-assignment via br/bv, Agent Mail coordination with file reservations, policy and two-person approval workflows for destructive commands, and durable state via checkpoints, timelines, and audit logs. For automation it offers --robot-* machine-readable CLI surfaces plus a local REST/SSE/WebSocket server (ntm serve) with a generated OpenAPI spec. The system is local-first and degrades gracefully when optional integrations such as Agent Mail or CASS are absent.
NTM creates named tmux sessions (ntm quick, ntm spawn), allocating agent panes via flags like --cc/--cod/--agy/--grok, with labeled swarms, worktree isolation (one ntm/<session>/<agent> branch per agent), and merge/cleanup flows. Operators dispatch prompts with ntm send, interrupt with ntm interrupt, monitor with ntm watch/activity/health, and inspect output with ntm diff/grep. Work triage runs through ntm work triage/next and ntm assign --auto against the br/bv work graph, gated by approval labels. A coordination layer provides ntm mail, ntm locks (with approval-gated force-release), and ntm coordinator auto-assign/digest. Safety uses ntm safety check, ntm policy, and ntm approve workflows. Durable state covers ntm checkpoint, ntm timeline, ntm audit, and resumable ntm pipeline runs. Automation surfaces include --robot-snapshot/--robot-send commands and ntm serve (REST /api/v1, SSE /events, WebSocket /ws, OpenAPI docs). Custom agent types load as TOML plugins from the agents/ directory, including a verified built-in Oh My Pi (omp) preset.
- A solo developer running 3-5 Claude/Codex panes on one project who wants a unified dashboard and command palette instead of raw tmux pane wrangling
- A tech lead who wants specific tasks auto-assigned to particular agents based on a br/bv work graph with an auditable assignment record
- A team needing multiple agents on one repo without conflicts, using --worktrees for isolated Git checkouts and Agent Mail for file reservations
- An engineer in a sensitive environment requiring policy gates and two-person approvals before destructive commands like git reset --hard
- Automation users driving agent swarms programmatically from scripts or CI via --robot-* JSON output or the ntm serve REST/WebSocket API
- Anyone running long multi-step agent pipelines (e.g. review.yaml) who needs resume-from-checkpoint after failures
How do you install or deploy this agent?
Three options: 1) Install script: curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/ntm/main/install.sh?$(date +%s)" | bash -s -- --easy-mode; 2) Homebrew: brew install dicklesworthstone/tap/ntm; 3) From source: git clone https://github.com/Dicklesworthstone/ntm.git && cd ntm && go install ./cmd/ntm. Docker images (amd64/arm64) are available at ghcr.io/dicklesworthstone/ntm:1. Runtime requires tmux plus whichever agent CLIs you want to launch (Claude Code, Codex, Antigravity CLI, or Grok Build); verify with ntm deps -v.
How do you use this agent?
Enable shell integration: eval "$(ntm shell zsh)". Scaffold a project and spawn a mixed swarm: ntm quick api --template=go, then ntm spawn api --cc=2 --cod=1 --agy=1. Open operator surfaces: ntm dashboard api and ntm palette api. Dispatch work: ntm send api --cc "Map the auth layer and propose a refactor plan." Use ntm work triage to inspect the work graph and ntm assign payments --auto --strategy=dependency for automated assignment. Save a checkpoint: ntm checkpoint save api -m "before auth refactor". Start the local API: ntm serve --port 7337; for scripts, use ntm --robot-snapshot and related robot commands.
What are this agent's strengths and limitations?
- One Go binary unifies session orchestration, work triage, safety approvals, coordination, and APIs — no glued-together scripts
- Destructive operations are approval-gated by default (e.g. locks force-release requires a second operator; self-approval is rejected), making safety core rather than bolt-on
- Strong durability design: checkpoints, timelines, audit logs, and resumable pipelines make interruptions recoverable
- Dual automation layers: local --robot-* JSON commands for scripting plus ntm serve with REST/SSE/WebSocket/OpenAPI for long-lived integrations
- Pluggable custom agent types via TOML files in agents/, with a verified built-in Oh My Pi preset, extending beyond built-in CLIs
- Intentionally tmux-centric with Linux and macOS as primary environments; no native Windows story
- Advanced features depend on external tools (br, bv, Agent Mail, CASS) that are unavailable when not configured
- Grok Build support is phase one only: automated prompt delivery, interrupt-with-message, restart, and restore-time relaunch fail closed
- No outside contributions accepted; PRs are not merged directly, fixes depend on the author's AI-assisted review flow
- License is MIT plus an additional rider (GitHub shows NOASSERTION), so compliance review is warranted before adoption
- Strict config loading (unknown fields are errors) and migration steps such as moving [health] settings to [resilience]
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| NTM (Named Tmux Manager) This agent | 73 · Some gaps | CLIFree + model costs | ★ 461 | today | Go | Codex · Claude Code |
| OpenRig | 79 · Good | CLIFree + model costs | ★ 8.2k | today | TypeScript | Codex · Claude Code |
| MCO | 73 · Some gaps | CLIFree + model costs | ★ 540 | 17d ago | Python | Codex · Claude Code |
| Maestro Orchestration Platform | 75 · Some gaps | Agent plugin / skillFree + model costs | ★ 485 | 1d ago | JavaScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Safety design is unusually strong: policy/approval system, two-person approvals with self-approval rejected, labels as authorization boundaries for auto-assignment, fail-closed behavior, worktree isolation, and comprehensive rollback surfaces (checkpoints, timelines, audit) — full marks for user_confirmation and rollback. Deductions: the product drives coding agents that execute arbitrary shell commands and perform impactful git merges; external_effects relies on the policy layer with no execution-level proof in evidence, so 1; the recommended install is curl | bash executing a remote script, weakening least_privilege and data_flow_transparency; govulncheck is continue-on-error in CI and bubbletea is locally replaced, so dependency_security 2; sensitive_data_handling rests on an assertion that credentials stay out of NTM config, so 2.
README is internally consistent, documents fail-closed behavior, typed robot error documents, ntm deps -v, and graceful degradation; CI includes reality guards and a parity gate. All three criteria merit 2. Not 3 because the core Go source is absent from the provided files, so actual error-handling implementation cannot be statically verified.
Audience and scenarios are exhaustively covered; Grok phase-one explicitly lists unsupported operations and fails closed, earning full marks for capability_boundaries and audience_and_scenarios. Deductions: environment is Linux/macOS only (Windows explicitly excluded), with hard tmux and multiple external-tool dependencies — environment_fit 2; trigger precision relies on readiness regexes and explicit robot surfaces described but not shown in implementation — 2.
Information architecture, command map, and user/project config layering are excellent; known-limitations disclosure is candid (Grok scope, config migration notes) — full marks. Heavy deductions: the license is MIT plus a restrictive rider targeting OpenAI/Anthropic — likely not OSI-compatible and of doubtful enforceability, consistent with NOASSERTION — license 1; install_notes is a single curl | bash line with no manual or checksum-verified path — 1; no CHANGELOG appears in evidence despite VERSION/release preflight in CI — versioning_changelog 1; single-author maintenance (Jeffrey Emanuel) with low bus factor — maintenance_responsibility 2.
Output usability is excellent: robot JSON, OpenAPI with CI drift detection, parity matrix, markdown/terse formats; the problem statement is clear and the combination (tmux multi-agent + policy/approvals + work-graph triage) has genuine marginal value — both full. cost_benefit 2: the system requires tmux, several external CLIs, and Agent Mail; the benefit depends on ecosystem availability and the maintenance surface is large.
README claims are partially corroborated by CI workflows and test scripts (OpenAPI drift gate, coverage threshold, SHA-pinned dependencies, parity harness) — cross_source_corroboration 2; claim_traceability 2: claims are specific (badge state table, one-shot approval consumption) but the main source code is absent from the evidence, so implementation cannot be checked item by item; fact_inference_separation is good — the README explicitly separates claimed from unclaimed capabilities — but the doc is self-assertive without third-party verification, capped at 2.
- Do not blindly run the README's curl | bash install; inspect install.sh and verify checksums first.
- The license is MIT plus a rider barring OpenAI/Anthropic and affiliates; it is not a standard OSI license and requires legal review before enterprise adoption, especially for teams using either company's tooling.
- The tool drives coding agents that execute arbitrary shell commands and merge git worktrees; destructive risk depends heavily on policy configuration quality. Review defaults and keep approval gates enabled before deployment.
- govulncheck does not fail CI, and the locally replaced bubbletea fork is outside upstream vulnerability fixes; track these yourself.
- Single-maintainer project with bus factor 1; no visible CHANGELOG, so diff behavior release-by-release when upgrading.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Antigravity (agy) agents now run Gemini 4 Argon (High). Otherwise identical to v1.37.1: same source, Go 1.26.9 and golang.org/x/net v0.60.0. Changed - Antigravity default model is Gemini 4 Argon (High) (gemini-4-argon), replacing Gemini 3.8 Flash (High). The required-model pin, the session-resume command, the model registry (1M-token context), the flag help and both spawn wizards move together, matching ACFS's agy-locked launcher. Argon accepts no --effort value, so the pin names the model only. Not in this release …View on GitHub ↗ -
v1.37.1 v1.37.1: security patch (Go 1.26.9, golang.org/x/net v0.60.0)
Release notes excerpt
Security patch: Go 1.26.9 and golang.org/x/net v0.60.0 ([#347](https://github.com/Dicklesworthstone/ntm/issues/347)). The source is v1.37.0's, unchanged. Only the toolchain, the HTTP/2 module, the Docker builder image and the README badge move. Security - Go 1.26.8 → 1.26.9. On 1.26.8, govulncheck reports that ntm's code reaches 10 Go standard-library vulnerabilities: GO-2026-6603, 6604, 6605, 6607, 6608, 6610, 6611, 6612, 6613 and 6617, several of them in net/http and HTTP/2, which ntm's HTTPS download and upgrade paths use. On 1.26.9 with x/net v0.60.0 it reports none. …View on GitHub ↗ -
Release notes excerpt
Spawns can enforce per-agent-type fleet limits that hold across processes, Claude agents launched by ntm now carry the safety policy hook, robot work reads are verified against the tracker, and ntm's integrations with bv, br, cass, cm, caut, caam, ubs, xf, ms, jfp, slb, ru, rano, pt and dcg now read those tools' real output. Also fixes GitHub issues [#283](https://github.com/Dicklesworthstone/ntm/issues/283), [#335](https://github.com/Dicklesworthstone/ntm/issues/335), [#336](https://github.com/Dicklesworthstone/ntm/issues/336), [#337](https://github.com/Dicklesworthstone/ntm/issues/337) a …View on GitHub ↗