When terminals become control surfaces

The terminal is becoming a control surface

Coding agents changed the shape of terminal work. A single prompt can run for minutes, stop for a decision, launch tests, or finish while the developer is reading another diff. Multiplying that by several projects turns a row of indistinguishable tabs into an attention problem. Kero’s answer is to treat each command as a durable session with an observable state, not merely as a process attached to a window. Its documentation describes working, waiting, idle, error, and exited states, plus a shortcut that jumps to the pane requiring attention. That is a modest idea with practical consequences: the interface is organized around what needs a human next.

Kero appeared publicly in 2026, and its v2.0.0 release is the first stable release in the upstream release history. The project is still young, so this is not a claim of mature adoption. It is evidence of a new tool entering a quickly changing category. The useful question is not whether it replaces every terminal, but whether its session model matches how someone actually supervises agents.

Persistence moves outside the window

Kero runs sessions in a small daemon named kerod. Closing the graphical application leaves those sessions running; reopening it restores panes and scrollback. The same architecture supports remote hosts over SSH or Tailscale, allowing an agent to continue on a workstation or cloud machine while the laptop sleeps. The Kero CLI can also create sessions, split panes, type input, wait, and read screens. In other words, an agent can operate neighboring sessions as part of a larger task.

That design is useful when work is long-lived, but it changes the trust boundary. A persistent daemon retains active processes after the window disappears, and remote hosts add credentials, network reachability, and another machine’s security posture. Notifications indicate that work finished or became blocked; they do not prove that the result is correct. A sensible trial should begin with disposable repositories and explicit resource limits.

An actual evaluation can be concrete:

• Start two agent sessions and one test watcher in a temporary project.
• Close and reopen Kero, then verify process state and scrollback.
• Trigger a question or failure and check whether the attention state is accurate.
• Repeat on a remote host, then confirm which credentials and ports were required.

These checks measure the documented workflow without treating installation counts as evidence of individual users or reliability.

Three products, three different boundaries

Kaku is closer to a polished general-purpose Mac terminal. It builds on WezTerm, supplies fonts, themes, shell integration, and familiar Mac shortcuts, while retaining Lua customization. It can run coding agents, but its primary promise is a pleasant terminal with useful defaults. Choose that boundary when the terminal itself is the product and agent supervision can remain in ordinary tabs or panes.

Ghostex takes the opposite direction. Its upstream documentation describes chat views, readable diffs, queued prompts, worktrees, embedded browser panes, session search, and mobile access. It can hand a session between different agents and lets agents create and steer other sessions through a command. That makes it closer to an integrated agent workspace than a terminal with status indicators. The tradeoff is a larger surface area: more application features, more state, and more remote-access decisions to understand.

Kero sits between them. It keeps a terminal-first mental model but adds persistence, status, project grouping, and agent-drivable session control. The comparison is editorial rather than an official compatibility claim: these projects do not need to integrate with one another, and their rapid release cycles make feature matrices perishable.

Decide by the handoff you need

The central choice is where the human-agent handoff should live. Kaku leaves it mostly inside the command-line program. Kero elevates session state and attention routing while preserving terminal interaction. Ghostex moves the handoff into chat, review, previews, and cross-device access.

Before adopting any of them, document the failure path. What happens when an agent requests approval, a daemon restarts, a remote connection drops, or a session consumes excessive resources? Confirm how to terminate work independently of the interface. Review whether transcripts, commands, and remote credentials persist, and decide which repositories are appropriate for experimental tooling.

Agent-oriented terminals are valuable precisely because ordinary terminals reveal too little about parallel asynchronous work. Their dashboards can reduce attention switching, but they can also make many autonomous processes feel safer than they are. The strongest workflow pairs visibility with mundane controls: isolated branches or worktrees, bounded permissions, reviewable diffs, tests, and a reliable way to stop everything.