Activity record off-machine copy

What it is

A daily background copy of the control server's activity trail. The trail itself is the local audit — starting a session, raising an inbox alert, changing a protected setting, publishing something — kept in this computer's database. This feature takes the day that just ended, removes anything private from each line, links the lines together with SHA-256 hashes, and sends that off the machine to your own email address.

The fingerprints are what make it evidence rather than a snapshot: each line's hash is built from the line before it, so one altered line — or one removed line — stops matching at a known place, and each day's copy is chained onto the last hash of the day before.

Where to find it

• The copies arrive in your own email, one per day, in the mailbox of the account signed in to this Omniscio install. The subject names the day: 2026-10-24 activity record.
• The switch is in Settings → Diagnostics: Keep a copy of this computer's activity record somewhere else. It is on by default.
• The card about a copy that is not getting out appears in your Omniscio inbox.

How it behaves

What is in a copy. Every action of the day, in full. Routine reads — the constant "check the status" polling agents do — appear only as a count per route, such as 412 x /sessions, because thousands of those lines would bury what matters, and because copying them would let anyone who can generate cheap requests push their own actions out of a size-capped copy.

What is taken out. Email addresses, phone numbers, API keys, tokens and connection strings are removed from every free-text field before anything is hashed or sent.

The header of each copy states the day, the computer, the install, how many rows were recorded that day and how many of them were actions versus routine reads, the range of record numbers that day so an unexplained hole in the middle is visible, and the previous copy's last hash with the exact rule for recomputing the fingerprints — so a copy can be checked without this app or its code.

When it sends. Once the day has ended: hourly checks, one day per check, starting shortly after midnight. A computer that was off for a week catches up over the following hours and says in each copy how many older days it could not reach. A day with an unusual number of actions is split into parts that name themselves; a day too large to copy in full says so in the copy rather than pretending to be complete. A quiet day still sends, and says it was quiet — a missing email is the alarm, and a quiet day must never look like a deleted one.

When it cannot send. Nobody signed in: the day is held and retried, with no card. Signed in but no sending address on the account: you get the existing "security alerts cannot leave this computer" card, because that is the same missing piece. A real send failure that lasts a day: one inbox card, which clears itself as soon as a copy gets through.

When the record changes after it was copied. Each day Omniscio checks the day it copied last time against the copy it sent. If the record here no longer matches, you get a card that says so, and that card is not cleared by later successful copies — the email already in your mailbox is the version that was not changed.

What it cannot do. The fingerprints are built when the copy is made, so someone who acts and then deletes their own record inside the same day is copied as a clean day; the record range in each copy makes a hole in the middle visible, but a tidy deletion at the edges will not show. Someone who edits the database and also rewrites this feature's own state file can fake continuity going forward — copies already delivered keep the older fingerprint, so the fake is visible to anyone comparing emails. And deleting the emails deletes the copy: the mailbox is the store, and Omniscio does not check after delivery.

Turning it off. The switch stops future copies and retires the failure card; it does not delete anything already sent. It is deliberately not changeable from a paired phone or from a command-line call, so a stolen device or a wandering agent cannot quietly switch the record off.

For agents

• Service: src/main/services/security/api-activity-export-service.ts; chain and canonical row: api-activity-export-chain.ts; contract: .claude/memory/contracts/api-activity-export-contract.md.
• Setting key securityAuditExportEnabled; it is in REMOTE_FORBIDDEN_SETTING_KEYS and in OWNER_HELD_SETTING_KEYS in cli-settings-patch-policy.ts.
• State file api-activity-export-state.json under the app data folder (last day, chain tail, the tail before that day, failure clock).
• The cloud append-only store is NOT wired; see the contract for why and what it would need.

Related

• Security file integrity check — the other half: what changed on disk.
• Recent CLI activity — the on-screen view of the same trail.
• Security alerts by email — how a break-in becomes an email.
• Weekly security digest — the weekly summary of the week's cards.