atrium — Docs
docs/panes/chat.md

Agent chat pane: coding agents as a transcript

Run an agent over its own protocol — streamed transcript, approvals, plans, live canvases, generated images, computer use, subagents, steering, and rewind.

An agent chat pane runs the same vendor CLI a terminal pane would — but over the tool's programmatic protocol instead of a PTY. Nothing is reimplemented and nothing is scraped: the agent streams structured events, and atrium renders them as a real transcript with approval cards, diffs, subagent drill-in, and a composer that knows what the engine can do.

Terminal panes are still first-class. Chat is the better surface when you want to read the work; the terminal is the better surface when you want the tool's own TUI.

Launching into chat

The chat/terminal choice is a surface, resolved the same way at every launch point:

  1. An explicit flag (--surface chat / --surface terminal).
  2. The launch profile's surface.
  3. Your per-adapter preference from the launcher.
  4. The adapter's capability default.
In the launcher, the toggle is a chat/terminal icon pair at the right of the composer's identity row, disabled for adapters with no chat transport.
atrium agent launch <slug> --surface chat
atrium launch <slug> --surface terminal

--surface applies to that one launch; it never changes your launcher preference. When a CLI launch wanted chat and chat isn't available, it opens a terminal and says so in its output (surfaceFallback plus a warning). If atrium can't tell whether chat is available, the launch is refused rather than guessed. Background runs are always terminal (a chat pane needs a pane to render into) and only warn when you ask for --surface chat explicitly. See Task dispatch for the task-side equivalent.

Transports and capabilities

Each adapter declares a chatTransport in its manifest (spec). The transport determines which affordances the pane can offer — the UI is capability-gated, so a chip or card never appears for an engine that cannot honor it.

AdapterTransportNotable capabilities
Claude Codeclaude-sdkCheckpointing (rewind), plan mode, images, steering, subagents, background tasks
Codexcodex-app-serverPlan mode, images, steering, subagents, background tasks
GrokacpSteering, subagents, background tasks, command discovery
Oh My PiacpSubagents, background tasks, command discovery
OpenCodeacpSubagents, command discovery
Kimi CodeacpPlan mode, images, command discovery
Cursor AgentacpSubagents, command discovery
HermesacpCommand discovery, context usage
Pipi-rpcImages, steering, command discovery
GooseacpImages, command discovery, context usage
Muse Codemuse-mspConversation rewind, images, steering, subagents, background tasks
AntigravityacpImages, command discovery, background tasks

Every transport above supports permission callbacks and thinking; most support resume, model selection, and context-usage reporting. Capabilities reported by the running engine determine which controls appear.

Antigravity chat uses a separate managed ACP runtime. atrium installs it on demand when needed, instead of trying to run the agy terminal interface as a chat server. Muse Code supports in-chat sign-in: open the supplied sign-in page and check that its confirmation code matches the code shown in atrium.

The transcript

  • Turn-granular virtualization keeps long sessions responsive; heights are cached and seeded on restore so scroll position survives a restart.
  • Markdown, tables, and prose are rendered and sanitized (anchors forced to noopener, style and code-execution vectors stripped).
  • A now line and relative timestamps under user and agent bubbles.
  • Clickable URLs — open in an atrium browser pane, the system browser, or a split, with the shortcut shown on hover.
  • A prompt navigation rail for jumping between your own messages, including messages sent mid-turn. Agent and system messages are hidden from this rail by default; enable either under View options → Prompt navigator.
  • Message actions on assistant blocks: copy the response or quote it into the composer with Markdown framing.
  • Search (Cmd+F) with boundary navigation across the transcript.
  • Reader mode caps the column width for comfortable reading.
  • Session recap appears on longer conversations. Hover or keyboard-focus its bar to review the original request, latest request, and most recent agent response; expand an excerpt or summary to read its source.
  • Inbound agent messages identify their sender. Click the sender to open its pane, including senders on another location. View options → Collapse agent messages reduces long peer messages to an expandable summary.

Tool calls

Tool calls collapse by default into work groups, and consecutive runs of them bundle into a single row — live, while streaming. File-changing tools auto-expand.

  • Diffs render from the tool's own input, syntax-highlighted, with unchanged lines folded and an open-the-file affordance.
  • Codex fileChange events are preserved as unified patches and rendered as such.
  • File changes made through shell commands also render as edit cards when atrium can recover their changes. Path-only records show the affected file without invented line counts.
  • Always show regex exceptions let you pin specific tools open. Click a pattern to edit it; Enter saves and Escape cancels.
  • Always show skills keeps skill loads visible even when surrounding tool calls are collapsed. Click a skill load to open the skill beside the chat pane.
  • Subagents appear as drillable child rows with live status, a stop control, and token counts. Workflow agents show up the same way.
  • Background shells drill into a terminal view of the engine's output — including shells the engine never named.

Cards

Beyond plain messages, the transcript renders typed cards:

  • Approval / permission cards with exactly the options the request offered — allow once, allow for the session, or deny with a message. Tool input renders visually rather than as raw JSON.
  • Question cards stay in the drawer above the composer while awaiting your answer, with multiple questions rendered as tabs. Draft choices survive room switches. Answered questions remain in the transcript with the response, including Codex structured and asynchronous questions.
  • Plan cards — approve (which restores the prior permission mode before proceeding) or reject with feedback.
  • Todo checklists, live.
  • Memory cards for atrium memory calls, including episode and superseded metadata.
  • Lifecycle cards for interrupted or errored turns, with Resume and Retry.
  • Model fallback cards when the requested model refuses or cannot continue. The card names the original and fallback model when the engine supplies one, or states that no fallback was available.
  • Computer-use cards for scope requests, screenshots, actions, approvals, and stop controls. See Computer use.
  • Connector cards for browser sign-in, forms requested by connected tools, and changes that need your confirmation. See Connectors.

Generated images

Generated images render inline at their natural aspect ratio with Save image as… and Copy image actions. The same surface works when the generating agent is remote: atrium reads the result from the pane's owning location instead of assuming the path is on your Mac.

Live canvases

A fenced canvas block in an assistant response becomes a live, interactive surface in the transcript. atrium parses partial specs while the message streams, so the canvas can take shape before the turn finishes, then settles onto the final declarative JSON spec. It uses the same safe component catalog and action model as canvas notes: structured UI and state bindings, not arbitrary code execution.

Canvases also render natively on iPhone and iPad. Form values are shared between connected devices, so you can continue an answer on another screen. A canvas needs a submit action to send your answer to the agent; changing a field alone does not send it.

Interactive HTML pages

Agents can publish a custom HTML page directly into a conversation, for diagrams, comparisons, prototypes, or interactive explanations. On macOS, click the preview to interact with the page; on iPhone and iPad, tap it to open the live page. Pages can include controls that send an answer back to the conversation. Images open in the shared image viewer.

An agent creates a local HTML file, previews it, then publishes it with atrium html. The published reference renders in chat; an ordinary HTML code block remains source code. Pages use atrium's theme tokens and can load network resources. Publishing here stores a chat artifact; it does not deploy a public website.

Settings → Appearance → Chat → Inline canvases and pages controls desktop rendering. The phone has its own inline-canvas preference. For an artifact you want to keep separately from the conversation, use a note.

The composer

The chat composer shares its shell with the launcher and terminal composers, so the grammar is identical everywhere.

  • Config chips — model, reasoning effort, and permission mode, edited in place and pushed to the engine over its config RPC. Capability-gated.
  • A usage ring showing context consumption, with a breakdown popover and a Compact action. The popover also includes a View usage limits link that opens the provider's usage page in your system browser (Claude, Codex, Grok, Cursor, Antigravity, Kimi, OpenCode, Hermes).
  • Plan-usage windows when the engine reports them, combining context fill with 5-hour and weekly limits in one meter.
  • Slash commands discovered from the engine, surfaced through the same autocomplete pipeline as sigils.
  • Image attachments by paste, drag, or the + menu, as removable chips. Image-only sends are allowed; oversize images and engine rejections degrade to a notice rather than failing silently.
  • A changed-files panel — the live turn's digest in the composer drawer, plus a cumulative session panel you can collapse and drill into. The session panel also lists commits made during the conversation; open a file or commit diff beside the chat to review it.
  • Ghost-text prompt suggestions and state-aware placeholders that teach the surface, then graduate out of the way.
  • A Claude Remote Control chip (Claude Code only) that surfaces inbound prompts from mobile.
  • Saved prompts from the + menu. Save, search, rename, and delete reusable prompts; an empty Cmd+S opens the same picker.
  • Connectors in the composer show the tools available to this session. Session switches and launch-profile defaults are described in Connectors.
  • Formatting in the + menu shows the Markdown toolbar; Hide formatting or the toolbar's × closes it.
The usage popover brings context, quota windows, and account switching together. Where supported, each account shows its usage and reset time; select an account to switch. Context details and auto-continue settings open beside the popover. See Accounts for account rotation and limit recovery.

Sending, queueing, and steering

  • Messages send optimistically and restore your text on failure.
  • Claude Code mid-turn sends steer by default: your message appears in the conversation immediately and reaches the engine at its next tool step. In Settings → Tools → Claude Code → Messages sent while it's working, choose Queue to keep it above the composer for editing or retracting until delivery.
  • Other engines use their supported delivery mode: native steering where available, or a queue that waits for the current turn to finish. Consecutive queued sends retain their order.
  • With a message queued, the displayed Enter to send now action interrupts to deliver it immediately; Esc or ↑ brings it back for editing.
  • Esc interrupts and re-inserts your message, highlighted.
  • Accepted steers render as Acknowledged user turns, so you can see what the engine actually took.

Session goals and loops

Choose Set goal in the + menu, or enter /goal, then type the objective. The drawer keeps that goal visible and lets you change or clear it. Claude Code and Codex use their native goal support; Codex also offers pause and resume. On other adapters, atrium appends the objective to subsequent sends, without claiming that the engine has evaluated completion.

Claude Code's Start loop menu action, or /loop, captures a prompt for its native scheduler. The drawer reports scheduling, the next run countdown, and completed runs; Stop loop cancels the schedule. A native loop belongs to that engine session and does not survive closing or restarting it.

Where the engine has no native loop command, atrium offers a local /loop that resubmits the seed after each completed turn, bounded by a count or duration such as /loop 5 or /loop 10m. Its chip shows the remaining count or time and lets you stop it. For recurring work that needs a durable schedule and separate runs, use a repeating task.

Moving a conversation into a worktree

Choose Move to worktree… in the composer's + menu to move an existing conversation to a new or existing worktree of the same repository. The move keeps the pane, conversation history, draft, launch settings, and task association. Copying uncommitted changes is optional and off by default; select individual files to copy them while leaving the source checkout intact.

An idle conversation stays idle and receives a move notice. If the agent was active when the move was requested, atrium waits for its turn to finish, then nudges it to pick up the conversation in the destination. There is no continuation checkbox to manage.

This works with every chat tool. atrium uses native resume or fork when available; otherwise, it starts a fresh engine session in the same pane with instructions to read the preserved conversation. Each move has a status card beside its request. Focus follows the pane you are viewing, including back to its original room if the move fails. No extra terminal pane is created.

Agents can schedule the same action with agent move, then finish their turn so atrium can complete the move.

Forking a conversation

Choose Fork conversation in the pane's ⋯ menu (or its header's right-click menu) to try another direction without disturbing this one. A new chat pane opens beside it with the same history, the same working directory, and the same model, effort, permission mode and launch profile. It continues as its own session, and the original pane is left exactly as it was. A pane running on another machine forks on that machine.

Forking works with Claude Code, Codex and Pi. The action appears once the agent has started a session, so a brand-new pane needs one message first. While the agent is mid-turn it waits ("after this turn"), because a copy taken mid-turn can end on a tool call that never got its result.

You can also fork from a point in the conversation:

  • Fork from here, in the ⋯ handle beside a reply, a thinking block or a finished tool call, opens a fork whose history ends at that block. A fork from a tool call keeps its result, along with the results of any calls made at the same time. On Codex, which can only fork whole turns, the action reads Fork through this turn and keeps the turn that block belongs to.
  • Fork and edit this message, beside Rewind when you hover one of your messages, opens a fork of everything before that message and puts the message in the new pane's composer, ready to change and send. It isn't offered on the first message.
Both work with Claude Code and Codex, and appear once the block's turn has finished. Pi only forks whole conversations.

From the CLI, atrium pane create --adapter <name> --resume <session-id> --fork opens a fork of a session by id; Copy session ID in the same menu gives you the id. When an atrium pane owns that session, the CLI fork takes that pane's directory, settings, launch profile and account, exactly as the menu does. A session started outside atrium has no pane to copy from, so it uses the adapter's launch profile and the --cwd you pass. An atrium that predates forking refuses --fork rather than resuming the session.

Rewind

Hover one of your messages for Rewind when the engine supports it. The preview offers Files, Conversation, or Both, according to that engine's capabilities. Claude Code supports file checkpoints and conversation rewind; Muse Code supports conversation rewind. File previews show the files and line counts to restore, and warn that shell-command side effects are not checkpointed. Rewind is disabled while streaming.

Switching to a terminal, and back

A chat pane and a terminal pane can hand the same session back and forth. The header offers the switch; atrium resumes the session natively on the other surface rather than restarting it.

Restore and resume

Chat panes persist their adapter, engine session id, transport kind, and working directory. On restart:

  • The restore chooser lists them and relaunches through the transport's own resume — never by shelling out to --resume in a PTY.
  • Sessions still running in the daemon are adopted: atrium re-subscribes and replays rather than launching a second copy.
  • A daemon restart marks persisted sessions interrupted rather than faking liveness.
  • The effective model / effort / permission config rides the resume, so your knobs never silently reset.
Panes auto-title from the first prompt, and a transcript can be sent to a note in one action.