# termio: a terminal-first agentic development environment for parallel coding agents

> Termio bundles a real terminal emulator, a session daemon and a CLI into one macOS app so several CLI coding agents can run side by side. It replaces the tmux-plus-tabs habit, but it is macOS 14+ only and its git pane is deliberately read-only.

**termio-sh/termio** — A terminal-first agentic development environment for agentic coding. Build for CLI/TUI agent. Runtime for Coding Agent,  Tmux alternative

- Repository: https://github.com/termio-sh/termio
- Website: https://termio.sh
- Stars: 534 · Forks: 40
- Language: Swift
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/termio-sh-termio

## The problem: too many agents, no single place that says who is blocked

Running one CLI coding agent in a terminal is fine. Running five is a scheduling problem. Each agent sits in its own tab or tmux window, and the only way to know whether one is waiting on a permission prompt is to cycle through them. Termio's pitch is that the environment's job, once agents write most of the code, is to run them and report which one needs you. That framing is stated directly in the README.

The target user is narrow and specific: someone who already drives Claude Code, Codex, OpenCode, Pi, Amp, Cursor, Copilot, Kimi, Antigravity, Crush or Grok from a shell, on macOS, and who wants a dashboard layer rather than a new editor. The README lists those agents by name and adds "and any other CLI agent", which suggests the integration is meant to be agent-agnostic rather than tied to one vendor. If you use a single agent and never run two tasks at once, the sidebar has nothing to tell you.

## termiod, hooks and the status signal that drives the sidebar

The mechanism has three parts. First, every session's shell lives in a daemon called termiod, so quitting the app detaches rather than kills. The README states that only Close Session (⌘W) ends a session, and that reopening Termio restores the same process and the same scrollback. That is the tmux claim, implemented as a background service rather than a multiplexer you attach to.

Second, Termio wires up each agent's own hooks on first launch. Those hooks are what let a session report working, idle or needs you. The signal surfaces in three places: a dot in the sidebar, a menu-bar tray that rings when an agent is blocked, and the companion iPhone app. The README also notes that session control installs a termio agent skill into each agent's skills folder, naming ~/.claude/skills and ~/.codex/skills, and refreshes it on every launch.

Third, the same status list is exposed as a command. The README shows termio sessions list producing the working, idle and needs-you states visible in the sidebar, so the GUI and the CLI read from one source. Remote sessions use the same path: the README says local and remote sessions run through the same host, and that the session lives on the box rather than in the connection, so dropping the link leaves the agent running and reattaching restores the screen.

## Installing termio on macOS and spawning your first sibling agent

The README gives two install routes: a direct DMG download from downloads.termio.sh, described as free and account-free for macOS 14+, or Homebrew via a cask. The Homebrew command is the one worth copying, because it makes upgrades a single command later.

```bash
brew install --cask termio-sh/tap/termio
```

After launching, the README's first real workflow is opening a checkout as a project. The CLI drives the running app, so this assumes Termio is already open.

```bash
termio .
termio sessions list
```

The first command opens the current directory as a project; the second should print the same working, idle and needs-you states the sidebar shows. From there, the interesting case is an agent spawning a sibling and reading its output back. The README's example hands a task to a new session and blocks until the turn settles.

```bash
termio sessions spawn "run the migration" --agent codex --wait
```

According to the README, --wait returns the final status plus the transcript range to read, --json makes any sessions command machine-readable, and --direction and --ratio control where the new pane lands and how large it is. A sibling's permission prompt can be answered with termio sessions send followed by the session id and the response, and termio sessions read with --lines prints what is on a session's screen.

## The git pane is read-only, and that is a deliberate boundary

Termio includes a Files inspector with syntax highlighting and autosave, a project-wide content search that jumps to the matching line, and a Changes tab that renders the current unified diff. The README is explicit that the Changes pane is read-only and that commit, push and PR stay in the terminal. That is a real limitation if you expected an IDE-style source control panel, and it is also consistent with the project's stated position that the terminal remains the place where you commit.

The sharper constraint is platform. The download is a macOS DMG, the install instructions target macOS 14+, and the companion mobile app is an iPhone beta distributed through TestFlight and paired by scanning a QR code in Settings ▸ Mobile. Nothing in the README describes a Linux desktop build or a Windows build, even though the remote story is explicitly about any Linux VPS you can ssh to. So the remote machine runs termiod and the agents' hooks, but the machine you sit at is a Mac.

One more thing to check before relying on it: the README says Termio reads ~/.ssh/config and never rewrites it. That is a claim about a file many engineers treat as load-bearing, and it is the kind of claim worth verifying against your own config before you point the app at a production host.

## How termio differs from tmux, and when tmux is still the better answer

The README addresses the comparison head-on: many people tell you to learn tmux, and Termio's answer is that you do not have to. The architectural difference is where the session lives. In tmux, a server process holds the panes and you attach a client to it, which is why tmux works over any SSH connection and inside any terminal, including on a remote box you have never installed anything on. In Termio, the daemon is termiod and the client is a native macOS app, which buys you the status model, the tray notification and the phone signal that a plain multiplexer cannot produce.

That trade cuts both ways. tmux is a package you install on the server and drive with a config file; its behaviour is scriptable and identical everywhere. Termio's value is concentrated in the GUI layer, and the CLI is described as driving the running app rather than standing alone. If your workflow is headless, scripted, or runs on machines where you cannot install a binary into ~/.local/bin, tmux remains the lower-friction choice. The README's remote setup does exactly that install: Settings ▸ Devices ▸ Set Up copies one binary into ~/.local/bin over SSH, starts the daemon, and installs the agents' hooks there. That is a reasonable amount of setup for one VPS and a nuisance across a fleet.

## Release cadence, licence and what upgrading costs you

Termio is MIT licensed, and the README shows an MIT badge pointing at the LICENSE file. For most users that means the usual permissions to use, modify and redistribute, with the usual absence of warranty; anyone embedding it in a product should read the actual LICENSE text rather than a badge. The repository also carries a SECURITY.md, which is where vulnerability reports are meant to go.

The release history suggests a fast pre-1.0 cadence: v0.51.0 on 2026-09-08, v0.52.0 later the same day, and v0.52.1 on 2026-09-09. The last push to the repository was on 2026-09-10, ten days before this writing. Three releases inside roughly 24 hours is a signal about how quickly the surface is moving, and it has a practical cost: the CLI flags documented today are the flags you will be scripting against, so pin a version if you build automation on termio sessions spawn --wait. Homebrew users get whatever the cask points at, which is convenient and also means an upgrade can change CLI behaviour without you asking for it. The README does not document a rollback path or a version-pinning mechanism for the cask.

## Conclusion

Adopt termio if you already run Claude Code, Codex or OpenCode in a terminal on macOS 14+ and you keep losing track of which agent is blocked. Skip it if you work on Linux desktops or Windows, if you want an editor that commits and pushes for you, or if you rely on tmux scripting and expect a drop-in replacement. Before committing, verify three things: that the agents you use are covered by the hook wiring on first launch, that the remote daemon installs cleanly on your VPS over the SSH config you already have, and that you are comfortable with a pre-1.0 release cadence, since v0.52.1 landed on 2026-09-09 and v0.52.0 the day before.

## FAQ

### What is termio and who is it for?

It is a terminal-first agentic development environment for macOS that runs CLI coding agents and reports which one needs you. It is aimed at engineers who already drive agents like Claude Code, Codex or OpenCode from a shell and want a status layer over them.

### How do I install termio on macOS?

The README offers a free DMG download from downloads.termio.sh for macOS 14+, or the Homebrew cask termio-sh/tap/termio. There is no account requirement mentioned.

### Is termio a tmux alternative?

The README presents it as one: each session's shell lives in a daemon called termiod, so quitting the app detaches instead of killing the process, and only Close Session ends a session. The difference is that the client is a native macOS app rather than a terminal multiplexer you attach to.

### Does termio work with remote Linux servers?

Yes, per the README: Settings ▸ Devices ▸ Set Up copies one binary into ~/.local/bin over SSH, starts the daemon and installs the agents' hooks there. Termio reads ~/.ssh/config and, according to the README, never rewrites it.

### Can termio commit and push from its git pane?

No. The README describes the Changes tab as a read-only git pane showing the current unified diff, and states that commit, push and PR stay in the terminal.

## Sources

- [License: MIT](https://github.com/termio-sh/termio/blob/main/LICENSE)
- [Project website](https://termio.sh)
- [README](https://github.com/termio-sh/termio/blob/main/README.md)
- [Releases](https://github.com/termio-sh/termio/releases)
- [termio-sh/termio on GitHub](https://github.com/termio-sh/termio)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/termio-sh-termio