Usage
This guide covers every supported Harness feature — what each one does, how to configure it, and the exact commands to drive it from the keyboard or a script.
All commands below assume the harness binary is on your $PATH and the
harness daemon is running. New to Harness? Getting started walks
from install to a supervised, scheduled, event-driven agent setup; the pages
here are the reference behind it.
The shape of Harness
Harness is a single Go binary with two roles, modeled after systemctl:
harness daemon— long-lived supervisor. It owns every harness: the processes, their PTYs, daemon-side scrollback, restart policy, and state. Run it once, supervised by init.harness— thin client. Open the TUI dashboard with no arguments, or run one-shot verbs (list,start,logs, ...) for scripting. A client can die at any moment without affecting a single harness.
A harness is any long-running command you want kept alive and re-attachable — an agent CLI, a REPL, a watcher, a background service.
What you can do
| Area | Docs |
|---|---|
| Install & quickstart | Quickstart |
| CLI verbs (list, start, stop, logs...) | CLI reference |
Configuration (harness.toml) | Configuration |
| Model pins (fail-closed model + provider policy) | Model pins |
| Scheduled agent one-shots (cron) | Configuration → Scheduled one-shots |
| Supervision & restart policy | Supervision |
| The TUI dashboard | Cockpit TUI |
| Exporting agent telemetry (OTLP, JSONL) | Production observability |
Project-scoped compose (up / down / ps) | Projects |
| Remote access over SSH | Remote access |
| Merge train (auto-landing approved PRs) | Merge train |
| Switchboard relay (leased-harness lease client) | Switchboard relay |
Prometheus metrics (/metrics) | Metrics |
Where the architecture comes from
Harness's engineering decisions are recorded as Architecture Decision Records and specifications. If you want the why behind any behavior here, see Architecture Decisions and Specifications.