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.
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.
