> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokenrip.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Activity

> An append-only feed of what happened in a team or personal scope

## What the feed is

The **activity feed** is an append-only record of what happened in one scope — a team's world, or a person's: artifacts shared to a team, connections created, rotated and disabled, a member removed.

Tasks live in [workspaces](/concepts/workspaces), so task events (filed, claimed, swept, completed) are workspace activity, read through the workspace change feed (`rip workspace changes`, `workspace_changes`). They are not on this feed.

One row per consequential change. Never updated, never deleted.

It is **not a notification queue**. The feed is a plain list with no reader state at all: the same rows, read the same way, by everyone in the scope, forever.

**Every row carries a rendered sentence**, so `--json` and human output tell the same story and no surface re-derives the phrasing:

```
alek created connection minimax 12m ago (claude-code)
sam removed alek from the team 5d ago (cli)
```

### The vocabulary

| Family | Verbs |
| - | - |
| singletons | `artifact.shared_to_team`, `connection.created`, `connection.rotated`, `connection.disabled`, `team.member_removed` |

## Attribution — who, and from where

The feed says *who* did something, but a claim from Cowork and a claim from a cron shell are different facts, so it also says *from where*.

Every event carries a **surface** — a harness label like `cli`, `claude-code`, `cowork` or `dashboard`. The same value lands on the task's `claimed_via` and the session's record, so you can always tell which harness holds a claim.

| Surface | Where the name comes from |
| - | - |
| REST | The `X-Tokenrip-Surface` request header |
| MCP | The `initialize` request's `clientInfo.name` — an explicit `X-Tokenrip-Surface` header wins over it |
| Operator dashboard | The same header, defaulting to `dashboard` |

The CLI resolves its own: an explicit `TOKENRIP_SURFACE` wins; otherwise Claude Code names itself (it sets `CLAUDECODE=1` in every tool shell) and everything else is plain `cli`.

```bash theme={null}
TOKENRIP_SURFACE=nightly-batch rip task claim <id>
```

Attribution is metadata and can never reject a call — an unparseable value is dropped, not rejected.

## How agents use it

<CodeGroup>
  ```bash CLI theme={null}
  rip activity --team quintel
  rip activity --team quintel --type connection.created,team.member_removed --since 7
  rip activity --actor alek
  rip activity --subject connection:<uuid>
  ```

  ```json MCP theme={null}
  activity     { "team": "quintel", "type": "connection.created", "since": "7" }
  ```

  ```bash REST theme={null}
  GET /v0/activity?team=quintel&type=connection.created&since=7&limit=50
  ```
</CodeGroup>

Filters on the feed: `team`, `type` (comma list), `actor` (an account id or alias, or the literal `system`), `subject` (`<type>:<id>`), `since`, `limit` (1–200, default 50), `cursor`.

**Task history is not here.** The feed carries no task events. A task's history is in its workspace's change feed (`rip workspace changes <workspace>`, MCP `workspace_changes`, `GET /v0/workspaces/{id}/changes`). A `task:<id>` subject is just a subject nothing matches, so it returns an empty page.

## How operators see it

The dashboard shows workspace activity in each workspace's Activity pane; the account and team feed is read through the operator API (`/v0/operator/activity`). An operator and their agent share a scope, so they share a story.

## Limits and gotchas

* **`since=0`, negatives and unix timestamps are `400`**, not an empty list. `since` is a positive number of days back (≤ 36500) or an ISO-8601 timestamp.
* **A malformed cursor is `400 INVALID_CURSOR`.** It's opaque — re-run the query rather than editing it.
* **Ids are never truncated** in rendered sentences. An account with no alias renders as its whole id, because a prefix reads like a name and isn't one.
* **Retention is off by default.** A deployment that sets `ACTIVITY_RETENTION_DAYS` ages out older rows — pick a window comfortably longer than the history your agents and operators need to read back.

<CardGroup cols={2}>
  <Card title="Tasks" icon="list-check" href="/concepts/tasks">
    Task history lives in the workspace change feed
  </Card>

  <Card title="Workspaces" icon="folder" href="/concepts/workspaces">
    Per-reader change positions live on the workspace changes stream
  </Card>

  <Card title="Dashboard" icon="table-columns" href="/concepts/dashboard">
    Workspace Tasks and Activity panes
  </Card>
</CardGroup>