From telling sessions apart to the finished project.

Explore a section: Switch sessions · Resume · Comment · Docs · Code · Phone.

For macOS and Windows with WSL. Ask your coding agent:

Clone https://github.com/albertwujj/agent-term to ~/agent-term, then set it

up and launch it for my current project, following the basic setup in its

docs/setup.md.

Click docs/setup.md if you want to read it.

Once it opens, start or resume your usual agent, select something in its output, and write a comment.

The landscape this repo is in. Skip to what's added so far if you want to get straight to it.

People run coding agents in an IDE, in the terminal, or in the vendor's desktop app. The terminal keeps pulling them in: Claude Code and Codex shipped as terminal programs, and Cursor and Copilot, born in the IDE, added CLIs of their own. A form from decades ago turned out to have what an agent needs: text in, text out, and your shell, git, and every other tool one command away.

So why do people still run agents in the IDE, and why are the vendors adding their agents to desktop apps? Partly because the standard terminal interface (TUI), great for text-centric iteration, cannot offer agents and users the essentials and the boosts a richer interface can. One answer is to move the agent out, into an app built around it. The other is to treat the terminal as the core and extend it. This repo is the second path: a full terminal wrapped in a modern extensible window (Electron), retaining everything you already have and raising the ceiling.

Extending it on demand is what keeps it a terminal. Additions come in only when you need them, and the window is a terminal again the moment you finish. An IDE or a vendor's desktop app has its panels up before you type, which can distract. Here the window is your session alone, shaped only by the work you do in it, and full screen if you like, with nothing else in view (one OS window per session).

A vendor's desktop app holds that vendor's agents and only those, and pulls you away from your shell. Here the agent can be of any kind, right in your shell, like a plain terminal.

Some other terminals have gone the vendors' way and grown an agent of their own, with ways to run many at once, including in the cloud; to get their environment, you take their agent. In this one, nothing about working with your agent changes.

Why not tmux, or one manager app over every session? This terminal takes the opposite shape: each session is its own OS window and process, the way each agent stands on its own. The OS is the manager you already know, so the taskbar, the Dock, Mission Control, and alt-tab do the juggling, and each agent, through its terminal host, is instantly recognizable. An agent and its host grow into one whole, cooperating with the others through shared conventions.

This path can look hacky: the host parses text, and reacts to it. But established text patterns are a stable interface, and a helpful output style sticks around. An agent's intentions arrive in those patterns through every turn, so the parsers keep working. It holds from both sides: guide files instruct the agents to print what the host understands, and the parser tracks the natural output styles the agents use intuitively. Extending it is quick when something new shows up, and none of it is tied to a vendor SDK or API.

With a host that understands its agents, and agents that understand the host, a capable agent does more than its CLI can alone. A CLI does not own the window, so when Claude Code publishes a design mock it can only print the URL and go around the terminal, opening your browser on it. This terminal responds to the reference an agent calls out and opens it inside the window, rendered, for you to read, comment on, and edit, and agents can see and update it through their protocol with the host.

You and your agents can change and extend this terminal, down to its code, to fit your work and your team's.

Use it as is first, a boost for working with your agents; what you need may already be there. When something is missing, add it with your agents: the gap is in front of you and the agents, who are in a good position to evaluate it and build the addition. And with the features listed below, agents run better when you build with them.

Below are examples, all on the same terminal. Follow the links to revisit the demos and explore features not shown in the GIF.

The first start gives you sessions as windows with their taskbar buttons or Dock tiles, the picker, and commenting on anything the agent prints. Existing sessions from before this terminal work too.

The rest are the optional suite: plans and reviews (one repo covers both), the checkout lock, long jobs, the phone view, the IDE integration. Ask your agent for the ones you want. For example, this adds the checkout lock:

Clone https://github.com/yunxin/agent-lock into ai/ in this project,

and leave ai/ out of .gitignore.

Then start a task with @proceed-b, which completes to the lock's guide doc in the agent-lock clone, and the agent takes the checkout lock before it works. For the other pieces, see their guides.

Grow it. Make a change with your agents, and the next window you open picks it up, since every window starts from the latest source (how a window opens).

AgentTerm is built on Electron with xterm.js (the terminal emulator) and node-pty (the shell's pty). MIT.