kooky: A macOS Terminal That Wraps AI Coding Agents in Workspaces, Panes and Git Worktrees

The problem kooky targets: agent sessions with no home

Running an AI coding agent in a plain terminal works until you run two of them. Then you are juggling tabs, losing track of which one is waiting for approval, and re-typing the same cd and branch-switch commands in each. kooky's answer is to treat a project directory as a workspace object with persistent state, and to treat each agent session as a first-class tab inside it. The README frames the product as "a minimal modern terminal built for AI coding", and the feature list is organised around that claim rather than around terminal emulation itself. The intended user is a macOS developer who already has one or more agent CLIs installed and wants them grouped by repository, with the sidebar showing what is running where. It is not aimed at people who want a general-purpose terminal replacement, and it is not a hosted service: the README states there are no accounts and no telemetry, and that app state stays local.

Workspaces, panes and tabs: the state model

The unit of organisation is the workspace, shown in a sidebar that collapses through three states with Command-Control-S. Each pane inside a workspace owns its own tab strip and active tab, and panes split right or down either from buttons on the tab bar or with Command-D and Command-Shift-D. Tabs can be dragged to reorder, moved across panes, or dropped into a different window, and the README says the live session moves whole, with scrollback and running process intact. Window geometry persists across launches. Command-Shift-E zooms the active pane to fullscreen and back while the other panes keep running off-screen. Workspaces can be tagged with one of seven preset colours or a custom colour plus name, and that tag carries into the agent panel. This is a conventional tiling-terminal model with one addition that matters: the workspace, not the window, is the thing that remembers which agents belong together.

How agent integration actually works

kooky does not ship an agent. It launches the CLI you already have. The README lists fifteen supported agents with their exact commands, including claude, codex, gemini, opencode, amp, cursor-agent, copilot, grok, agy, kimi, pi, omp, reasonix, kiro-cli and droid. Selecting one from the plus menu starts that binary in a new tab. Three per-agent signals are documented in a table: a waiting dot that turns amber when the agent stops and needs an answer (including a pending tool approval), a tool pill in the pane status bar showing the tool currently running, and session history browsable from the agent panel. Support is uneven and the README says so: only Claude Code, Pi, Oh My Pi and Reasonix have all three; Grok Build and Kiro CLI expose no waiting signal at all, so their dot only reports running and finished. All fifteen are claimed to resume their conversation across kooky restarts using each CLI's own session ID. That claim depends on the CLI exposing a resumable session, which is a property of the agent, not of kooky.

Bring-your-own-agent and what it inherits

Under Settings, Agents you can add an agent that is not on the list by supplying a name and a command. It then appears in the plus menu and launches like any other tab. There is a meaningful distinction in the README between a standalone command and one based on a built-in agent: basing a custom entry on a built-in makes it inherit that agent's launch binary, brand mark and activity tracking, because the sidebar dot is reported by the built-in's wrapper. A standalone command runs fine but the dot stays dark. Custom logos are accepted as PNG, JPEG or SVG at a recommended 64x64. Claude-based entries can carry their own environment variables, which the README suggests for a mirror or proxy endpoint. That last point is the most practically useful part of the customisation story, and it is also the most fragile, because it depends on the wrapper's behaviour rather than on anything kooky documents as a stable contract.

Git worktrees and SSH workspaces

Right-clicking a git workspace offers Create Worktree, which creates one on a new branch or checks out an existing one; the worktree appears nested under its source repo with its own tabs and agent. There is also an adopt mode in the same sheet for worktrees created from the command line, and the README says sidebar entries whose directory is gone are cleaned up at launch. SSH workspaces are created through File, New SSH Workspace or Command-P, and every new tab, split and restored tab reconnects to the same host independently. Agent tabs start the agent on the remote with the remote shell setup loaded, so tools installed through nvm are found. Pasting a local file or screenshot uploads it first and pastes a remote-readable path. Connections to the same host are shared, and password-authenticated hosts are supported including pasting. The design choice here is that each tab reconnects on its own rather than multiplexing through one connection object, which is simpler to reason about but means connection state is per-tab.

Install, settings and the commands you actually type

Distribution is a download from the GitHub releases page; the README points to the latest release and the repository ships a CHANGELOG. The platform floor is macOS 14 or later, stated in the README badge. Rendering is done through libghostty, the Ghostty project's library, which is the one external dependency named. There is no package-manager install line in the supplied material, so treat any brew or similar instruction you see elsewhere as unverified. Keyboard surface is where the product lives: Command-Control-S for sidebar collapse, Command-D and Command-Shift-D for splits, Command-R to rename a tab, Command-Shift-R to rename a workspace, Command-Shift-N for a new window, Command-O to open a folder as a workspace, Command-P for SSH workspaces and recent-project search, Command-Shift-E for pane zoom. Configuration is split across Settings, Appearance (including the option to switch off sorting agents by who needs you first) and Settings, Agents for the agent list and custom entries. Keep-awake is a three-position control in the top bar: Off, Auto, and Always, with Auto using a one-time admin authorization for lid-closed operation.

Where it does not fit

The clearest limitation is platform. macOS 14 or later, Swift and SwiftUI, no Linux or Windows build mentioned. If your team is not on Macs, this is not a candidate. The second limitation is that kooky is a layer over other people's CLIs, so its behaviour degrades exactly where those CLIs are opaque: Grok Build and Kiro CLI cannot report a waiting state, and a custom agent added as a standalone command gets no activity dot. The third is the keep-awake feature in Auto mode, which the README says requires a one-time admin authorization to stay awake with the lid closed. That is a real privilege request for a convenience feature, and whether it is acceptable depends on your machine policy. Finally, the release cadence visible in the material is high, with v0.51.8, v0.51.9 and v0.51.10 all landing within four days of each other in early September 2026. Frequent patch releases at a 0.51 version number suggest the surface is still moving.

The alternative, and the real difference

The obvious comparison is Ghostty itself, since kooky renders through libghostty. Ghostty is a general terminal emulator; kooky is an agent session manager that happens to be a terminal. If you only need fast, correct terminal rendering and you are happy to run claude or codex in ordinary tabs, Ghostty gives you that without the workspace sidebar, the agent panel, the waiting dot or the worktree sheet. The difference in approach is where state lives: in Ghostty the terminal is the product and sessions are your problem, while in kooky the workspace is the product and the terminal is the substrate. A second alternative is a multiplexer such as tmux inside any terminal, which gives you persistent sessions and splits but has no notion of an agent, no per-agent activity readout, and no one-click branch or Node switching. Neither alternative is worse in the abstract; they answer a different question.

Maintenance, licensing and version risk

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and imposes no copyleft obligation on your own code, but it also means no warranty, and the supplied material contains no statement about who maintains the project beyond the repository owner. The dependency on libghostty is the main upgrade consideration: rendering behaviour is tied to that library's releases, not only to kooky's own. The CHANGELOG in the repository is the place to look before upgrading, and the four-day release window in September 2026 is a reason to pin a specific release rather than track latest if you depend on agent session resumption. Nothing in the material describes a plugin API, a config file format, or a way to script kooky from outside, so customisation is confined to the Settings panes and the agent definitions. This is not legal advice; read the LICENSE file in the repository for the actual terms.

Editorial conclusion

Adopt kooky if you run several agent CLIs side by side on a Mac and want those sessions grouped by project rather than scattered across terminal tabs. Skip it if you work on Linux or Windows, or if your workflow does not involve agent CLIs at all, since the workspace and pane features alone are not the reason this exists. Before committing, verify three things on your own machine: that each agent command you rely on (claude, codex, gemini, cursor-agent and the rest) is on PATH in the shell kooky starts, that the agents you care about expose the waiting signal the status dot depends on (Grok Build and Kiro CLI do not), and that the keep-awake Auto mode's one-time admin authorization is something you are willing to grant for lid-closed operation.

Official sources

1. iAmCorey/kooky on GitHub
2. Issues
3. License: MIT
4. README
5. Releases