Termio: a terminal-first ADE that keeps your coding agents alive in a daemon
A terminal-first agentic development environment for agentic coding. Build for CLI/TUI agent. Runtime for Coding Agent, Tmux alternative
At a glance
- What is it?
- Termio is a macOS terminal emulator and agent orchestrator built around termiod, a daemon that owns every session's shell so quitting the app only detaches. It is MIT-licensed Swift, and the interesting question is whether its session-status model earns the extra daemon.
- Who is it for?
- Adopt Termio if you already run several CLI coding agents in parallel on macOS or on a Linux box you can ssh into, and you want their state to survive closing the laptop lid. Do not adopt it if you work on Linux desktops or Windows, if you need a terminal that is not tied to an agent workflow, or if you are unwilling to run a background daemon that holds your shells.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Termio targets: too many agents, no shared status board
Running one CLI agent in one terminal is easy. Running four in four tabs is where the workflow breaks down, because the bottleneck stops being the agent's speed and becomes your ability to notice which one is waiting for input. Termio's README states the premise directly: when agents write most of the code, the environment's job is to run them and to tell you which one needs you. That is a narrower and more defensible goal than "better terminal". The target user is someone already running Claude Code, Codex, OpenCode, or one of the other named CLI agents, who wants the multiplexing to be handled by the app rather than by tmux keybindings they have to memorise. The README frames tmux as the thing you are being spared: "Many people tell you to learn tmux. You don't have to." Whether that trade is worth a daemon is the question the rest of this review keeps returning to.
termiod: the daemon that makes the app disposable
The architectural decision that matters is that shells do not live in the GUI process. According to the README, every session's shell lives in termiod, a daemon, so quitting the app only detaches. Close the laptop, reopen Termio, and the README says the agent is where you left it: same process, same scrollback. Only Close Session (⌘W) ends one. This is the same conceptual move tmux makes with its server, and it is the reason Termio can claim to be a tmux alternative rather than merely a nicer terminal. The practical consequence is that the app window becomes a view onto state owned elsewhere. Crash the window, and the work continues. The cost is that you now have a background process holding your shells, and the README does not describe what happens to termiod when it is killed, when it is upgraded, or how session state is persisted across a daemon restart. That is a gap worth knowing about before you put a long migration inside it.
How status reaches you: hooks, dots, a tray, and a phone
Termio does not guess at agent state by scraping terminal output. The README says it wires up each agent's own hooks on first launch, and that a session reports working, idle, or needs you. That signal surfaces in three places: a dot in the sidebar, a menu-bar tray that rings when a session is blocked, and the same signal on your phone through the companion iOS beta. The list of agents named for hook support is Claude Code, Codex, OpenCode, Pi, Amp, Cursor, Copilot, Kimi, Antigravity, Crush, and Grok, plus "any other CLI agent". That last clause is doing a lot of work and the README does not explain how a generic agent with no hook system would report status. The status set also appears as a CLI command, termio sessions list, which the README shows returning working, done, and needs-you states. Using an agent's own hooks is the right call, since it avoids the fragility of pattern-matching a TUI, but it means status fidelity is bounded by what each agent chooses to emit.
Driving Termio from inside Termio
The CLI is the part that distinguishes Termio from a terminal with a sidebar. Because termio drives the running app, an agent inside Termio can spawn a sibling, hand it a task, and read back the reply. The README's example sequence is the clearest statement of intent: termio sessions spawn "fix the flaky test" starts a new agent session on a prompt, termio sessions send ab12cd34 "1" answers a sibling's permission prompt, and termio sessions read ab12cd34 --lines 40 prints what is on a session's screen. Flags adjust the shape of that: --wait blocks until the turn settles and returns the final status plus the transcript range to read, --json makes any sessions command machine-readable, --agent picks which agent spawn starts, and --direction with --ratio decide where the new pane lands and how big it is. The README's combined example is termio sessions spawn "run the migration" --agent codex --wait. To make this discoverable, session control installs a termio agent skill into each agent's skills folder (~/.claude/skills, ~/.codex/skills) and refreshes it on every launch. This is a genuine mechanism, not a marketing line: the agent learns the CLI because the CLI installs itself into the agent's context.
Install and the remote path through ~/.ssh/config
On macOS 14 or later, the README gives two routes. Download the disk image from downloads.termio.sh, described as free and requiring no account, or use Homebrew with brew install --cask termio-sh/tap/termio. The iPhone companion is a TestFlight beta, paired by scanning the QR code in the Mac app's Settings ▸ Mobile. Remote work is the more interesting configuration. Termio targets any Linux VPS you can ssh to, reads ~/.ssh/config, and per the README never rewrites it. Settings ▸ Devices ▸ Set Up copies one binary into ~/.local/bin over SSH, starts the daemon there, and installs the agents' hooks on the remote host. The README's claim is that 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 working and reattaching restores the exact screen. Read carefully, the read-only treatment of ~/.ssh/config is a deliberate restraint worth noting, since tools that manage SSH targets frequently take ownership of that file.
What Termio deliberately does not do
The scope boundaries are explicit and they are the most useful part of the README. The file editor does syntax highlighting and autosave, but the README says the terminal stays the place where you commit. The Changes pane is read-only, showing the current unified diff, and commit, push, and PR stay in the terminal. Search is project-wide content search that jumps to the matching line in the editor. This is a coherent position: Termio refuses to become an IDE with a git client bolted on. It also means anyone hoping for staging hunks, resolving conflicts, or reviewing a diff inline will be disappointed, because those are not in the described feature set. The absence is a design choice, and it is consistent with the claim that agents live in the terminal. The trade-off is real, though. If your review workflow depends on a graphical diff, Termio gives you a read-only view and sends you back to the shell.
Where the model strains: platform lock-in and the daemon bet
The clearest limitation is the one stated in the install section. The desktop app is macOS 14+ only. The remote story extends reach to Linux servers, but the client you sit in front of is a Mac application, and the iPhone companion is a beta distributed through TestFlight. If your team is on Linux workstations or Windows, Termio is not a candidate regardless of how well the session model fits. The second limitation is the daemon itself. Termio asks you to trust a background process with the shells running your agents, and the README does not document termiod's failure modes, its upgrade path, or what a daemon restart does to live sessions. Compare that with tmux, where the server model is decades old and its behaviour under kill, upgrade, and detach is widely understood. Termio is at v0.52.1 as of the supplied release list, with v0.52.0 and v0.51.0 published within two days of it. That cadence suggests active development, and it also means the surface you adopt today will move. The release notes are the place to check for what changed in termiod between versions.
How this differs from tmux plus a status script
The honest alternative is tmux, optionally with a script that polls pane output for prompts. The difference in approach is where state comes from. A tmux status line is built from pane titles and whatever your script can infer from the screen; Termio's status comes from each agent's own hooks, which the README says are wired up on first launch. That is a categorically different signal, and it is why the needs-you state can ring a menu-bar tray and reach a phone. The second difference is the control surface. tmux gives you send-keys and capture-pane, which are powerful but stringly typed and agent-agnostic. Termio gives you termio sessions spawn, send, read, watch, focus, and close, with --wait and --json to make the results structured. The third difference is the remote path: tmux over SSH is a familiar pattern, while Termio's Settings ▸ Devices ▸ Set Up automates binary placement and hook installation on the remote host. If you already have a tmux configuration you like and your agents are few, the marginal gain is small. If you are coordinating several agents and want structured replies rather than screen scraping, the difference is the point.
Editorial conclusion
Adopt Termio if you already run several CLI coding agents in parallel on macOS or on a Linux box you can ssh into, and you want their state to survive closing the laptop lid. Do not adopt it if you work on Linux desktops or Windows, if you need a terminal that is not tied to an agent workflow, or if you are unwilling to run a background daemon that holds your shells. Before committing, verify three things yourself: that Settings ▸ Devices ▸ Set Up completes against your VPS without modifying ~/.ssh/config, that your specific agent is covered by the hook installation the README describes, and that Close Session (⌘W) is the only thing that kills a session you expected to persist.
Community notes