---
title: Session Event Log
---

# Session Event Log

## What it is

A per-session **troubleshooting view** that lists only that session's *lifecycle
events* — the behind-the-scenes things Omniscio did to keep the session running —
without the chat or the huge volume of tool output that normally buries them. It
answers "what actually happened to this session?" at a glance.

## Where to find it

### Where it is (the UI surface)

Open any session, then use the message-filter control (the **All / Agent / You**
segmented control in the session's overflow "⋯" menu, under **Filter Messages**).
It now has a fourth option, **Events**. Selecting it replaces the conversation with
a flat, day-grouped list of lifecycle events, each with a timestamp. Switch back to
**All** to return to the normal conversation.

## How it behaves

### What shows up

Each row is one lifecycle/system event:

- **Auth token refreshed** — the login token was renewed and the last turn re-run.
- **Account switched / moved to a less busy account** — the session moved to a
  different Claude account (e.g. because one hit its rate limit).
- **App restarted / reconnected after a crash** — recovery after a restart or crash.
- **Session paused / resumed / snoozed**, and **conversation compacted** markers.
- **Self-archived / automatically archived** — when a session ended itself or was
  archived automatically (by the agent, a recipe, a CLI command, or a cleanup sweep),
  a note names the reason (e.g. "Self-archived — the agent ended its own session"). A
  session you archived by hand posts nothing, and a branch landed by the auto-lander
  keeps its own richer "Landed …" note.
- **Triggered via CLI · …** — when this session fired a *consequential* action through
  the control server (spawned a session, published a Share, raised an alert, ran a
  recipe, changed a setting), a note summarises what it did. Read-only
  status checks never post. **The summary is a link** — click it to jump straight to
  whatever the action touched: the spawned session, the published Share's URL,
  the changed setting's Settings section, the inbox, or the cron / recipes panel (a note
  whose target isn't knowable, like a created tag, stays plain text). A **raised alert**
  names the alert and reflects what actually
  happened to it — `Raised an inbox alert: "…"` for a new card, `Updated an existing inbox
  alert: "…"` when it bumped an already-showing one, and `Re-flagged a recent inbox alert
  (no new card): "…"` when the 24-hour re-raise cooldown suppressed it (so you don't go
  hunting for a card that never appeared).
- **Messaging another session is deliberately NOT one of these grey notes** — that is one
  agent talking to another, so it gets its own violet **"Sent to ‹session›"** card carrying
  the message you sent, with the target's name as a link and a *Show more* toggle for a long
  body. It is the same card whichever route sent it, and it mirrors what the *other* session
  sees when the message arrives — so both halves of an agent-to-agent exchange read as one
  object instead of a full bubble on one side and an anonymous grey line on the other.

These two, like the account/pause markers, are kinded system notes, so they show up
both here in **Events** and inline in the normal conversation.

The normal chat (your messages and the agent's replies) and the large
`subagent-result` tool-output rows are deliberately hidden here — that's the point.

### Which account → which (account switches)

When the session switches Claude accounts, the event names **which account it moved
from and to**, shown as the accounts' human names (email / display name), resolved
live when you view the log. If an account was removed since the switch, the row
falls back to a generic "switched accounts" wording rather than showing a raw id.

**Privacy:** Omniscio stores only opaque internal account *ids* on the event — never
the account email/label. So if you **share or export** a session, the log never
leaks your account address; a recipient who can't resolve the id just sees the
generic wording. Names appear only in your own live app.

Coverage note: the common rate-limit / load-balance account moves are named. A rarer
"silent" respawn-time move is still listed but not named (its destination isn't known
at the moment the event is recorded).

## For agents

### How it works (for agents with repo access)

- The "Events" value is a fourth `MessageFilter` (`src/renderer/src/features/sessions/session-composer-constants.ts`);
  when active, `SessionPanel` renders `<SessionEventLog>` (`src/renderer/src/features/sessions/SessionEventLog.tsx`)
  from the raw message list instead of the turn view.
- The event set is `LIFECYCLE_EVENT_KINDS` (`src/renderer/src/features/sessions/coalesce-system-rows.ts`) —
  the inline lifecycle-marker kinds plus `notable-system` / `compact-divider`.
- Old→new account ids are stamped on the `rate-limit-recovery` system row by
  `emitRecoveryMarker` (`src/main/services/rate-limit-recovery-service.ts`), ids only.
- It reuses the existing `SESSION_GET_HISTORY` feed (no new data channel), so it works
  on the mobile/web client too; opening Events on mobile loads the full history first.
- Invariants: `.claude/memory/contracts/session-event-log-contract.md`.

## Related

No sibling page is linked from this one yet, so the library map is the way on: [INDEX.md](INDEX.md) lists every page and area, including the transcript and session-status pages that sit next to this view.