Activity Tab
Activity is the unified event feed: chat turns, tool calls, permission prompts, connection events, and skill outcomes — all in one stream with filters and live updates.
Activity is where you go when you want to know exactly what your agents have been doing.
What Activity captures
The Activity service aggregates events from across the daemon — chat, tool, permission, session, connection, and skill categories — into a single chronologically ordered feed. Events come from the daemon stream bus, not from the desktop polling, so the panel updates in real time. The aggregator implementation lives in internal/desktop/services/activity (service.go, aggregator.go), and every event is persisted so historical scrolls hit a real store rather than a fading buffer.
Event types
| Event | Meaning |
|---|---|
chat:turn | A user prompt or agent reply was committed to a session. |
tool:start / tool:finish | Boundaries around a tool call, with inputs and result. |
permission:ask / permission:decision | Permission gate entries — request and outcome. |
connection:state | Daemon transitions between online, degraded, and offline. |
skill:invoke | A skill manifest was invoked. |
session:open / session:close | Session lifecycle from sessionmgr. |
Filters and search
The lists panel exposes a filter set covering event type, machine, time range, and free-text search. Filters compose as an intersection — combining “tool” + “machine = build-server” + “last 1 h” gives only the tool calls run by that one machine in that window. Search matches across the event payload, not just the type.
Live tail vs. historical browse
By default the panel auto-scrolls with new events as they arrive. Scrolling up pauses the tail and shows a “resume live” pill so you do not lose your place. Switching the time-range filter to anything other than “live” puts the panel into historical mode, which paginates against the persisted store rather than the in-memory tail.
Drilling into an event
Each row expands to show the full payload (redacted to the user’s scope). From an event you can jump in one click to the source chat, the source issue on the Board, or the source connection on the Connection tab — Activity is built as a hub, not a dead-end log.
Permissions audit
The permission events are the user-facing audit surface for the permission gate. This is where you see “agent X tried to write /etc/hosts, you denied” with the full rule that triggered the prompt and the decision you made. The conceptual model lives in permissions; the gate implementation is internal/desktop/services/permissionspolicy.
If you are chasing “why did the agent do that”, start in Activity and filter by tool plus the time window. Every tool call is recorded with its inputs.