
Zmx
- 76 installs
- 52 repo stars
- Updated June 24, 2026
- 0xbigboss/claude-code
zmx is a Claude Code skill that provides session-management patterns for running long-lived dev processes (servers, watchers, tests) with the zmx CLI.
About
zmx is a Claude Code skill that gives an agent conventions for managing long-lived shell processes with the zmx session tool. It covers deriving session names from the git root, starting processes idempotently, reading scrollback for errors or readiness, waiting on completion, and killing only the current project's sessions. A developer uses it when an agent needs to keep a dev server, file watcher, test watcher, or tilt process running across turns without blocking the shell.
- Session-management patterns for zmx to run dev servers, watchers, and tests that outlive the conversation
- Idempotent start/monitor/kill recipes keyed off a git-derived project prefix
- Includes a when-to-use table separating long-lived processes from one-shot commands
Zmx by the numbers
- 76 all-time installs (skills.sh)
- Ranked #270 of 550 CLI & Terminal skills by installs in the Skillselion catalog
- Data as of Jul 30, 2026 (Skillselion catalog sync)
zmx capabilities & compatibility
- Capabilities
- process management · dev server · session management
- Use cases
- devops
What zmx says it does
Use when starting dev servers, watchers, tilt, or any process expected to outlive the conversation. Provides zmx session management patterns for long-lived processes.
Use `zmx run` to send commands without attaching — `zmx attach` blocks the agent's shell and makes it unresponsive
npx skills add https://github.com/0xbigboss/claude-code --skill zmxAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 76 |
|---|---|
| repo stars | ★ 52 |
| Last updated | June 24, 2026 |
| Repository | 0xbigboss/claude-code ↗ |
What it does
Manage dev servers, watchers, and test processes that need to run in the background across an agent session.
Who is it for?
agents that must run dev servers, watchers, or tests in the background across turns
Skip if: one-shot builds or quick commands under ten seconds whose stdout is needed directly
When should I use this skill?
starting a dev server, watcher, tilt, or any process expected to outlive the conversation
What you get
Background processes run in named zmx sessions the agent can monitor, wait on, and clean up without blocking.
By the numbers
- 9-row when-to-use decision table
Files
zmx Process Management
Session Rules
- Check
zmx list --shortbefore creating sessions — duplicates cause port conflicts and confusing output - Derive session name from
git rev-parse --show-toplevel— hardcoded names collide when multiple agent instances run concurrently - Use
zmx runto send commands without attaching —zmx attachblocks the agent's shell and makes it unresponsive - Use separate sessions with a common project prefix for multiple processes
One project = one session prefix. Multiple processes = multiple sessions sharing the prefix.
Session Naming
PROJECT=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" || basename "$PWD")All subsequent examples assume PROJECT is set. Session names follow ${PROJECT}-<role>:
myapp-server,myapp-tests,myapp-tilt
Starting Processes
SESSION="${PROJECT}-server"
# Idempotent: skip if already running
if ! zmx list --short 2>/dev/null | grep -q "^${SESSION}$"; then
zmx run "$SESSION" 'npm run dev'
fiFor multiple processes, loop over name:command pairs:
for name_cmd in "server:npm run dev" "tests:npm run test:watch"; do
name="${name_cmd%%:*}"
cmd="${name_cmd#*:}"
SESSION="${PROJECT}-${name}"
if ! zmx list --short 2>/dev/null | grep -q "^${SESSION}$"; then
zmx run "$SESSION" "$cmd"
fi
doneSending Commands
# Run a command in a session (creates session if needed)
zmx run "${PROJECT}-main" 'cat README.md'
# Pipe via stdin
echo "ls -lah" | zmx r "${PROJECT}-main"Monitoring Output
zmx history "${PROJECT}-server" # full scrollback
zmx history "${PROJECT}-server" | tail -50 # last 50 lines
zmx history "${PROJECT}-server" | rg -i "error|fail" # check for errors
zmx history "${PROJECT}-server" | rg -i "listening|ready" # check for readyWaiting for Completion
zmx wait "${PROJECT}-tests" # block until done
zmx wait "${PROJECT}-build" "${PROJECT}-lint" # wait for multipleLifecycle
zmx list # all sessions
zmx list --short # names only
zmx kill "${PROJECT}-server" # kill one session
# Kill all project sessions
zmx list --short 2>/dev/null | grep "^${PROJECT}-" | while read -r s; do
zmx kill "$s"
doneIsolation
- Only kill sessions matching the current project prefix — other agent instances may have their own sessions running
- Always verify the session name before kill operations
When to Use zmx
| Scenario | Use zmx? |
|---|---|
tilt up | Yes, always |
Dev server (npm run dev, rails s) | Yes |
File watcher (npm run watch) | Yes |
Test watcher (npm run test:watch) | Yes |
| Database server | Yes |
One-shot build (npm run build) | No |
| Quick command (<10s) | No |
| Need stdout directly in conversation | No |
Polling for Readiness
for i in {1..30}; do
if zmx history "${PROJECT}-server" 2>/dev/null | tail -20 | rg -q "listening|ready"; then
echo "Server ready"
break
fi
sleep 1
doneRelated skills
FAQ
When should I use zmx instead of running a command directly?
Use zmx for dev servers, watchers, test watchers, database servers, and tilt; skip it for one-shot builds or quick commands under ten seconds.
How does zmx avoid session name collisions?
Session names are derived from the git repository root so concurrent agent instances do not collide, and sessions are created idempotently only if not already running.