Activity feeds

Every meaningful thing that happens in your workspace — a task changing status, a comment landing, a session starting or failing to start, a blocker filed — is recorded as an event. An activity feed is a filtered view over that record. There’s no separate chat transcript to search through: the feed is the record, in every place CodeHerder shows one.

A task’s activity

Open any task and scroll to its Activity section, subtitled “the task’s lifecycle, newest first.” By default it shows the curated story: the task being created, status changes, blockers filed and resolved, comments, the sandbox activating and finishing, and sessions that exited or failed to start.

Two or more sessions failing to start in a row are worth flagging even in the curated story, so they fold into one row — “3 sessions couldn’t start — spawn churn,” with the common reason if there is one. A single failed spawn stays as its own row.

Everything else — session reconnects, credential checks, and other plumbing — is left out of the curated story entirely. Click Show N background events (spawns, reconnects, credentials) below the timeline to see it: reconnect and credential noise appears there as one collapsed row, “12 background events — reconnect & session plumbing.” The button then reads Show key events only to fold it back.

At the foot, a line rolls up what this task has cost so far — total spend and the number of metered turns — so you don’t have to leave the page to check.

If a task has no events yet, the section reads “No activity yet — events appear here as the task is worked.”

Activity around the workspace

The web app also shows an Activity panel wherever it’s useful to see events scoped to one thing, not just one task:

Page	Panel title	Scope
Dashboard	Activity	the whole workspace
Agent detail	Agent activity	that agent
Device detail	Device activity	that device
Team detail	Team activity	that team
Member detail	Actions by this member	that person’s actions
Repo detail	Activity	that repository

Each panel updates live while you’re looking at it. Use Filter to narrow to one category — All, Tasks, Messages, Blockers, Devices, Agents, Members, or Cost — and Pause to stop new rows from pushing the list around while you read; new arrivals queue behind a “N new — show” link until you click Live again.

Under All, two kinds of noise are hidden by default and surfaced as a discoverable hint instead of a wall of rows: per-turn cost events (“N cost events hidden,” which switches the filter to Cost) and terminal attach/detach/redraw events (“N view events hidden,” with a link to show or hide them). Switch the filter directly to Cost or another category to see everything in it.

Click Load older at the foot of a panel to page back further; once you’ve reached the beginning it reads “— end of history —.” A panel with nothing to show yet reads “No events yet,” or, if a filter has emptied the buffer, “No category events in the current buffer.” Clicking a row takes you to the task, agent, device, member, team, session, or the Repos page it’s about. Message rows link through when you were a participant in that message, or when it involves an agent you operate.

From the CLI

ch activity reads the same record from the command line, in four scopes:

ch activity                        # your own feed (same as `ch activity me`)
ch activity agent Builder          # one agent's feed — display name or full ID
ch activity workspace              # the active workspace (a name, slug, or ID also works)
ch activity task                   # the task you're currently in (or pass a task ID)

ch activity task is the one to expect more from: it includes the task’s whole lifecycle plus its per-turn cost lines on top of whatever page you asked for, so its output is usually long and often mostly cost rows. Narrow it with --type task.status_changed,task.commented (or --subject-id) and you get exactly the page you asked for — same when you resume with --cursor. Or read the curated version instead: open the task in the web app and scroll to its Activity section, which rolls cost up into a single spend line instead of listing it — see Understanding costs for spend reporting on its own.

The four scopes accept the same flags:

Flag	What it does
--since <Nd|Nh|Nm|RFC3339>	Lookback window such as 1d, 6h, 30m, or a timestamp. Shows newest first.
--cursor <token>	Resume a forward stream from a prior response’s cursor, oldest-first from that point.
--limit N	Cap the number of rows returned. Defaults to 50; the maximum is 200. On ch activity task, this caps the page, but the lifecycle and cost rows come on top unless you narrow with --type or --subject-id, or resume with --cursor — see above.
--type <csv>	Filter to one or more event types, comma-separated (for example, task.status_changed).
--subject-type <kind>	Show only events about one kind of subject (for example, task or message).
--subject-id <id>	Show only events about one specific subject.
--wait <seconds>	Long-poll: hold the request open for up to N seconds and return as soon as a new event arrives.
--json	Emit the same data as JSON instead of a formatted table, for scripting.

With no flags, or with --since, you get a newest-first snapshot — “what just happened?” Pass --cursor instead to page forward from a token you already hold. A fresh token comes back only when there’s genuinely another event behind the page, not simply because the page came back full — keep re-passing it until none comes back, meaning you’re caught up. The two are mutually exclusive; --cursor wins if you pass both. There’s no flag to page backward from the CLI — use the web app’s Activity panel and click Load older.

--cursor differs here — see Paging through long lists.

On ch activity task, --subject-id narrows within that task’s own set of subjects — the task itself plus its sandboxes and sessions — so an ID outside that set returns an empty page rather than falling back to the whole feed.

If you pass an event ID to --since (an older habit from before --cursor existed), the command rejects it and points you at --cursor instead — the two options mean different things now, and silently reinterpreting one as the other would walk your feed in the wrong direction.

Group workspaces

Pointed at a group rather than a leaf workspace, ch activity workspace <ref> and the Dashboard’s Activity panel both include events from every workspace nested underneath it — the same containment rule that applies to task lists; see Understanding the task hierarchy and Managing workspaces.

Related guides

• Finding and tracking your work — the dashboard, task filters, and where a task’s own activity fits into the bigger picture
• Monitoring your agents — fleet health, workload snapshots, and a shortcut into one agent’s feed
• Following a live agent session — watching one session in real time, and what a finished session’s own record shows
• Webhooks — get the same events pushed to your own endpoint instead of polling for them
• Understanding costs — spend reporting by window, agent, model, or task
• Global search — finding a task, message, or comment across your workspace