Skip to main content
Work is where active sessions live. A session can be an agent chat, a provider CLI running in its own terminal, or a plain shell you type into. Whatever kind it is, it’s scoped to a lane’s worktree and tracked as a durable session — with a transcript, a status, and a clear lane association — so nothing an agent does is anonymous.

Three kinds of session

Every Work session is the same kind of tracked record under the hood, which is why they all live in one list and one grid.

Agent chat

A chat backed by a provider SDK — Claude Code, Codex, Cursor, Factory Droid, or OpenCode. Streams tool calls and diffs, with approval gates.

Provider CLI

The provider’s CLI running inside ADE in a tracked terminal. It runs ADE’s own downloaded copy of the CLI, with your existing sign-in; open a plain shell to run a CLI you installed yourself. ADE knows how to resume it, so an ended CLI session can be continued.

Shell

A plain interactive shell (a PTY) in the lane’s worktree, for running commands by hand. Pick the shell new ones start with in Settings › App › Behaviour.

Lane scope

Each Work session belongs to a lane and runs in that lane’s worktree, with that lane’s environment. The same command behaves differently across two lanes, so check the lane label before you type or prompt. Launching a session always resolves the lane’s worktree first — sessions can’t drift into the wrong directory.

Tracked, not anonymous

Every session is a row that ADE keeps so you can revisit it later. A session record carries:
  • Identity — the lane, the tool type, and (for terminals owned by a chat) the parent chat.
  • Intent — a title and goal, often auto-derived from the first prompt.
  • Lifecycle — running, completed, failed, disposed, or detached, with start/end times and exit code.
  • Content — a transcript and a last-output preview.
  • Provenance — the commit range the session spanned and links to its diff.
A shell code block in an agent’s reply can be run from the chat: Run opens a new terminal in the chat’s tools pane, and Send output to the agent sends the result back. See run a command from a reply. When a chat runs commands on another machine, those commands join the chat’s terminal list with that machine’s logo. An agent can watch a terminal (ade terminal watch) and is woken when it prints something new; the terminal’s Watching pane lists every watcher, with Stop. Tracked provider CLI sessions also store enough resume metadata that, after one exits, you can Resume the TUI or send a follow-up prompt and ADE rebuilds the right claude --resume, codex resume, or equivalent command — continuing in the same durable session.

Organize the list, tile the grid

The Work sidebar lists sessions and can group them by lane, by status, or by time, with search and filters. The view area shows them as tabs, a single focused session, or a grid of tiled panes so several terminals and chats stay live at once.
Grid view keeps every tile mounted, so multiple agent CLIs or shells run side by side without detaching. Arrange them Auto, Rows, or Columns from the grid menu.

Tools alongside the session

A right-edge sidebar follows the active lane and Work session, with tabs for Git, Files, the iOS Simulator, App Control, and the Browser. Pick an element in the browser or simulator and it’s inserted as context into the active chat, draft, or agent CLI — so the agent works against exactly what you’re looking at.

Recovery

If ADE restarts, it reconciles each session against the process that owns it: live sessions owned by another window or the daemon are left alone, while genuinely orphaned ones are marked detached. The durable row and transcript always remain, so even a session whose process is gone stays readable in History.