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

The event log is one of two ways into a session’s history, and the logs hold the raw detail behind it.

• Session forensics — reading a finished session’s past in detail.
• Logs and debugging — where the logs live and what to look for in them.