Omniscio documentation
Browse all documentation
  1. Getting Started19
  2. Sessions & Agents140
  3. Inbox & Notifications72
  4. Projects & Tasks102
  5. Automation & Scheduling77
  6. Knowledge & Memory29
  7. AI Features74
  8. Integrations115
  9. Plugins & Marketplace44
  10. Cloud & Teams53
  11. Settings & Customization81
  12. Account & Billing29
  13. Troubleshooting84
  14. CLI & API Reference28
  15. Legal & Policies5
  16. Uncategorised20

Security file integrity check

Omniscio keeps a signed record of the files an attacker edits first, checks that record at every start and once a day, and raises one inbox card when something moved that Omniscio did not move. You read the card, decide, and either accept the change or take the machine seriously. It is on by default on every install.

What it is

By the time you notice a break-in, the useful question is what was touched. Omniscio cannot defend every part of a computer, but it can remember what a handful of files looked like and tell you when they do not look like that any more — which is the half of the problem you can act on.

The files it remembers are the ones that matter because of what they do, not because they are secret:

  • Your Claude settings and hooks, and this project's Claude settings and hooks. A hook is a program that runs on this computer every time an agent starts, so a change there can run something without you seeing it. Claude settings decide which programs are allowed to run at all.
  • Your CLI token file, which is the key other programs on this computer use to talk to Omniscio.
  • The security-relevant part of Omniscio's own settings — the ones that decide whether parts of its protection are switched on, or which programs and folders agents may reach. Ordinary preferences are deliberately not watched, so changing your theme is never news.
  • The Omniscio program itself, in an installed copy — so a swapped-out application bundle is something you find out about.

What Omniscio does not read: the contents of your files, your mail, your sessions, or anything you have written. It hashes the files above and nothing else.

Where to find it

There is nothing to open. It runs on its own, and when it has something to say it says it in your inbox, on a card titled "Files an attacker would change have changed". The card carries one button, "This was me — accept the new baseline".

The switch is in Settings → Diagnostics, as Watch the files an attacker would change. It is on when the app starts for the first time. Searching Settings for "tamper" or "compromised" finds it too.

How it behaves

The very first run writes the record and says nothing. After that, each run re-reads the watched files, compares them with the record, and:

  • Nothing moved — it says nothing and puts away any card it raised earlier, so a change you undid stops being news.
  • Omniscio updated itself — the record is quietly rewritten and nothing is raised. An app update replaces the program, its bundle and the hook files it installs, so treating those as suspicious would raise a "possibly compromised" card after every update and teach you to click "This was me" without reading. The record carries the version it was written for, and an update is the only thing that moves it.
  • Something moved — it raises one card, not one per file. The card names each file that changed, the time of the check, and what that particular file being changed actually means. Its wording deliberately does not claim Omniscio was not involved: a setting you changed from inside the app looks exactly like a setting changed from outside it, and the card asks you rather than pretending to know. The card stays until you deal with it, and the same files keep being reported rather than being absorbed quietly.
  • A watched folder could not be read — the card says so for that folder rather than claiming it is empty. A folder Omniscio cannot read is not the same as a folder with nothing in it, and is never treated as one.
  • The record itself was changed or damaged — a different card, saying so. Omniscio cannot tell you what moved in that case, and it will not overwrite the damaged record on its own. Pressing "This was me" does write a new record — but it keeps a copy of the damaged one beside it first, as security-integrity-baseline.damaged-<when>.json, so the evidence you were told to look at is still there afterwards.
  • Someone deleted the record and its key together — Omniscio records a fresh one (there is nothing left to compare against) but it does not put away a card that is already standing, so a drift or tamper alert you have not read yet cannot be erased that way.

Regenerating your CLI token is not news. The token file is judged against the token Omniscio holds, not against the bytes on disk, so regenerating it says nothing while a file swapped for something else still reports.

Pressing "This was me" records the files as they are right now and retires the card. If you changed more files between the card being raised and your click, the click records the current state — which is what "these were me" honestly means. Nothing about a watched file's content ever leaves this computer: the card names files, never their contents.

Two things worth knowing before you rely on it:

  • It is a comparison, not a guard. It cannot stop an attacker or undo a change. It tells you that a change happened, and it cannot tell you who made it — which is why the card always asks you rather than deciding for you.
  • It cannot read its own record on a machine with no system keychain. The record is signed with a key that only the operating system's keychain can unlock, so that editing the record is itself detectable. On a Linux machine without a keychain Omniscio writes no record at all rather than a record anyone could rewrite, and says so in its log.

Turning the switch off stops the checking and puts away the card, so a silenced check cannot leave a stale card standing. That switch is a desktop-only control, deliberately: it sits in the same class of settings a paired phone and an agent are refused, because turning the check off is the other way to erase what it reports. The card's accept button carries the same limit. Muting the card's type in Settings → Alerts → Files an attacker would change have changed silences the card without stopping the checking — the record keeps being maintained, so re-enabling it does not report a year of accumulated drift as one alarming change.

For agents

The service is src/main/services/security/security-integrity-baseline.ts, started at boot by src/main/startup/tasks/2978-security-integrity-baseline.ts and then once a day. It raises and clears through the one ordinary alert road (raiseAgentAlert / clearAlertByDedupKey) on the dedup key security-baseline-drift, declared in src/shared/alert-definitions/security/security-baseline-drift.alert.ts — where the card's accept button is also declared, as a run-ipc-action naming the handler accept-security-baseline.

The watched set is resolved through the app's own resolvers — getUserDataDir() (so a relocated data dir is correct), claudeConfigDir(), getTokenFilePath(), app.getAppPath() and process.resourcesPath. Nothing is hard-coded and %APPDATA% is never assumed. A target that does not apply on the current install — the app bundle in a development run, or this project's settings in a packaged install — is skipped with a declared reason recorded in the baseline itself.

The "security-relevant settings" projection is REMOTE_FORBIDDEN_SETTING_KEYS in src/main/services/web/web-access-settings-redact.ts — the same escalation class that already refuses remote writes to executable paths, auth gates, filesystem scope and pipeline-arming keys. There is deliberately no second list.

The record is <data dir>/security-integrity-baseline.json, an HMAC-SHA256-signed { v, mac, payload }; the key is a 32-byte secret sealed by safeStorage and stored as enc: in <data dir>/security-integrity.key. Verification compares the MAC with timingSafeEqual, and a missing key beside a present record is a tamper report rather than a first run.

The accept handler, IPC.SECURITY_BASELINE_ACCEPT (alert:accept-security-baseline), is declared security-boundary-human-only — it has no CLI route and is listed in BLOCKED_CHANNELS, because a caller that could move the baseline could erase the evidence the card exists to surface. The setting's off switch is securityIntegrityCheckEnabled (default true, src/shared/types/settings/system/security-integrity-settings.ts), read as !== false and rendered as the Diagnostics toggle security-integrity-check-enabled.

Related

Hooks covers the hook files this feature watches and what they do on this computer. Safe Mode explains the mode that turns background automation off — this check is off in Safe Mode with everything else. Secret paste guard is the other place Omniscio watches for something leaving your machine rather than something entering it.

Last verified 2026-10-24