Skip to content

Synced items

Synced Items (/admin/items) answers “what is actually in this workspace”. It counts the records users have synced to the server, in total and per account, and lets you open one account to see the individual rows.

Nine counters across the top — templates, personas, providers, sessions, memories, todos, scheduled jobs, research sessions and assistant chats — then one row per user with the same nine columns and an E2EE pill where encryption is on.

Soft-deleted rows are excluded everywhere, so the counts are what a client would actually pull, not what the tables hold.

Search matches on email. The Refresh button has no auto-interval on purpose: each row counts nine collections for one user, which is not a query to leave on a timer.

The row link, or /admin/items/{userId}, opens that account. Each collection gets a tab with its count in the label, its own search box, and a Delete action per row.

Tab Columns beyond the timestamps
Templates Name
Personas Name, archetype, tool scope
Providers Name, type, endpoint, model
Sessions Template, provider, tokens used
Memories Type, label
Todos Title, priority, status
Scheduled Jobs Name, status, owner device
Research Sessions Provider, status, step count, completion time
Assistant Chats Title, window mode, last accessed

One Refresh control sits above the tab strip rather than one per tab, because the tabs share a load: it re-reads the counts and the rows of the tab you are on.

An account with end-to-end encryption enabled shows a banner saying so, and every content column — names, titles, labels, text — is replaced with an encrypted marker. The server holds ciphertext it has no key for, and the admin UI does not pretend otherwise.

What stays visible is metadata: how many rows there are, when they were created and updated, structural fields such as a persona’s archetype or a todo’s status, and token counts. That is enough for capacity and support questions and nothing more. See End-to-end encryption.

Delete is a soft delete: the row is tombstoned and re-stamped for sync, so the deletion travels to the user’s devices on their next pull rather than reappearing from a client that still has it. The row itself stays in the database.

Every deletion writes an Admin.UserItem.Deleted event to the audit log recording the acting administrator, the target user, and the kind and id of the item — never its content, which for an encrypted account the server could not read anyway.