fleetcom

fleetcom supervises your local development fleet: multiplexers, application servers, REPLs, builds, tests, and AI agent sessions.

Running several long-lived commands is pesky once they span terminal panes or need to survive a disconnect. fleetcom gives each command its own PTY and exposes every screen through one dashboard. A daemon owns the jobs, so closing the client does not stop them.

Key Features

Fleet view

See every task’s state and latest output from one dashboard.

Quick peek

Press Space for a quick peek at a task’s live screen without attaching to it.

Attach and interact

Press Enter to take control of a task, then ^\ to return to the fleet without interrupting it.

Operational model

• Runs each command in its own PTY and groups tasks by state, by working directory, or by custom named groups.
• Keeps jobs running after the client disconnects.
• Saves and reloads task recipes with directories, commands, group assignments, and display names.
• Preserves supported claude, codex, and grok conversations so saved or rerun tasks can resume them.
• Launches commands in other directories through the @ picker.

Documentation

The docs/ directory covers configuration, on-disk state, session files, commands, and a complete first run.

Installation

Unix only: it relies on PTYs and process-group signals (killpg).

Cargo (recommended)

For normal use, install the published crate from crates.io:

cargo install fleetcom

From source

From the project root:

• cargo install --path . to install fleetcom on PATH, or
• cargo build --release and run target/release/fleetcom.

Usage

The first ordinary invocation starts the daemon when necessary. --daemon is an internal mode.

Key Commands

Dashboard

Attached

docs/commands.md covers every key and launch flag, including the routing mechanics.

How it works

Every task runs in its own pseudo-terminal, emulated with alacritty_terminal. The dashboard preview, peek overlay, and attached view all read the same emulated screen grid, so full-screen programs such as vim and htop retain one consistent terminal state across views. docs/how-it-works.md documents the terminal emulation, input routing, and activity windows.

Scope and tradeoffs

fleetcom targets concurrent build, test, watch, server, and interactive-agent processes. Each task is one command rather than a persistent shell session.

When to use fleetcom

• Several long-lived commands need one place for observation, tagging, and attachment.
• Jobs must survive a terminal closing and remain available for reattachment.
• The same command set is launched often enough to justify a saved session.
• Agent sessions (claude, codex, grok) must resume their conversations on rerun rather than start new ones.

When to avoid fleetcom

• You primarily need persistent interactive shell workspaces; use tmux or zellij directly. fleetcom can supervise a multiplexer, but it does not replace one.
• You need a full process manager: the fleet’s lifetime is bounded by the daemon’s.

Operational limits

• The fleet dies with the daemon: the daemon process is the fleet's single point of failure.
• Commands run through the client's non-interactive shell ($SHELL -c, or /bin/sh when SHELL is unset), so functions and aliases defined in ~/.zshrc are not available.
• The daemon serves one client at a time.

Operational constraints documents the shutdown and signal mechanics.