Watch Claude Code work in a desktop UI: the seven streamed blocks a terminal can’t render

The raw claude CLI prints a streaming text transcript. A native UI subscribes to the same Agent Client Protocol (ACP) session and renders the stream as discrete UI elements instead of flat text. Each ACP event (text delta, tool_call, tool_call_update, agent_thought, system_event) becomes its own bubble or card. The agent loop is unchanged. What changes is that a tool call no longer disappears into scrollback, a thinking trace is collapsed by default instead of pushing your last reply off-screen, and an interruption is a card with a colored border instead of an italicized line you miss when you tab back.

Seven, defined as the ContentBlockGroup enum in Desktop/Sources/MainWindow/Components/ChatUIComponents.swift lines 7-17: text, toolCalls, thinking, discoveryCard, observerCard, systemEvent, and browserActivity. Consecutive blocks of the same type are merged into one bubble or one collapsible group, so you do not get 40 individual rows for 40 file reads, you get one Tool Calls row that says "40 actions" with a one-line summary of whatever it is doing right now.

Tool call rows show a spinner while running. After 5 seconds, an elapsed-time counter appears next to the spinner: "5s, 6s, 7s…" then "1m 12s" etc. This is gated by the literal line `if elapsed >= 5` in the ToolElapsedTime view at ChatUIComponents.swift line 295. Anything that finishes in under 5 seconds just shows the spinner so the row does not flash a number for a fast call. Anything that hangs gets a visible timer you can use to decide whether to interrupt.

Yes. The group header shows the action verb plus a one-line summary of the running call. Click the chevron and the group expands into a list of every individual tool call in that run, each with its name, input summary, status (spinner or green check), and the first six lines of output rendered in a monospaced inline block. Markdown code fences are stripped so the inline output stays compact. The detail panel is the same code path the FaqSection uses for its accordion.

Some agent loops emit a structured summary block ("here is what I found in this codebase") that is not the same shape as a normal assistant reply. The UI gives it a boxed card with a bold title, a short summary, and an expand-to-full-body chevron, so the user can decide whether to read the synthesis or skip it. In a terminal these summaries fight with everything else for vertical real estate; in the UI they get their own visual lane.

Anything the agent wants a one-tap human decision on. Concretely: "I think this is the right command to run, approve / dismiss / show me a different one." The card carries an activityId, a content body, and a list of buttons, each with a label and an action key. The buttons fire a callback that the host hooks into the agent's protocol; once acted on, the card shows which action was selected and disables further input. A terminal can ask the same question with "y/n" but it cannot remember which choice you already made next time you scroll back through the chat.

Six right now, defined in SystemEventCardView (ChatUIComponents.swift lines 403-494): sessionRecovered (blue, circular-arrow icon), sessionRecoveryEmpty (orange, warning triangle), toolHangCanceled (orange, xmark.octagon), taskHangCanceled (orange, person-warning), userInterrupted (gray, stop.circle), and browserExtensionResumed (green, puzzle piece). Each is a thin-bordered card centered in the message stream with a colored border, an icon-led header, body text, and an optional Show details toggle that reveals a key-value table.

When the agent uses the browser tool, the event arrives with a toolName, an action (navigate, click, type, screenshot), a mode (visible or headless), and a URL. The UI renders this as a dedicated row instead of folding it into the generic Tool Calls group, so you can see at a glance which page the agent is on, even when the same tool fires dozens of times in a session. The status (running, success, error) is the same enum the generic tool calls use, so you get the same spinner and green check.

Yes. Every event arriving over ACP is persisted as a row in the chat's local store, so the conversation survives a Mac restart and you can scroll back through the entire timeline of one chat. Because each block is a typed object and not a flat string, the UI can re-render tool-call groups and system-event cards correctly even on cold start, without having to re-parse a text transcript.

No. Zed has had ACP-aware Claude Code integration for a while, Cursor and Cline have their own surfaces, and the underlying @agentclientprotocol/claude-agent-acp adapter on npm is open for anyone to build against. What is specific to Fazm is the native macOS shell, the seven streamed block types, the 5-second elapsed-time guard, persistent sessions that survive a Mac restart, one-click chat forking, no auto-compacting, and the same agent reaching beyond the terminal into the browser and other Mac apps. The source is at github.com/m13v/fazm if you want to read the chat UI implementation yourself.

If you have a Claude Pro or Max subscription with Anthropic, the same OAuth account works inside the desktop app and usage hits your existing plan. If you do not, you can plug in an API key or route through a corporate proxy or compatible gateway. The desktop UI does not bring its own model, it is a presentation layer on top of the same agent loop. Whatever you pay for Claude Code at the CLI is what you pay for it in the UI.