Restart attribution (no restart is ever anonymous)
In a dev install, agents and automations can restart Omniscio over the command-line API. An unattributed restart looks exactly like a crash, so Omniscio refuses anonymous restart commands and raises a persistent inbox notice naming the session, cron job or supervisor that asked for the restart.
What it is
In a dev (npm run dev) install, agents and automations can restart Omniscio over the
command-line API (POST /app/restart) — for example to pick up freshly merged code. A restart
tears the window down for the ~2-minute supervisor rebuild, so from the user's chair an
unattributed restart is indistinguishable from a crash. On 2026-08-02 three anonymous
restarts (global CLI token, no source session) read as a "mystery crash" and cost a full
investigation to explain.
Where to find it
Where you see it
- The notice appears in your Inbox after an agent/supervisor-triggered restart, deduped under one card that refreshes to the latest restart.
- A refused anonymous caller sees the
400body naming the exact headers to send.
Contract: restart-amc-invariants-mechanism-contract.md (I10; the separate owner off-switch allowAgentAppRestart is I9).
How it behaves
What Omniscio does
Two halves, both dev-only (a packaged build has no dev restart at all):
Anonymous restart commands are refused. Every
POST /app/restartcaller must identify itself — a validatedX-AMC-Source-Session-Id(AMC-spawned agents already have it in$AMC_SESSION_ID), a validated activeX-AMC-Source-Cron-Job-Id, or the dev supervisor's ownX-AMC-Restart-Originheader (a closed set the supervisor sends on its automatic relaunches, e.g. after a build-configuration change). A caller with none of these gets a clear400explaining exactly how to comply, and no restart happens. The provenance requirement has no off-switch. This is attribution, not authorization — the bearer token still gates access, and a separate owner switch (allowAgentAppRestart, default OFF) 403-blocks ALL headless restarts until you enable it at Settings → CLI Control — or you allow ONE session from its ⋯ menu ("Allow restarting Omniscio", or by approving its request), in which case that session, and only it, may restart with its own key; the point here is that any restart that IS allowed can always be traced to a requester. A session that restarts with its own key is always named as itself in the notice.The relaunch says who did it. When an agent, scheduled job, or the supervisor restarts Omniscio, the next boot raises one persistent inbox notice — "Omniscio was restarted at <time> at the request of the session "<name>" … this was a deliberate restart, not a crash." — with the requesting session attached as its provenance. Restarts you trigger yourself with the header Restart button stay silent (you already know). A stale record (the relaunch didn't follow within 6 hours) or a genuine crash produces no notice, so the card can never cry wolf.
Related
Attribution answers who asked for a restart. These two cover what to do when it happens too often, and after a crash.
- Relentless relaunch — what to do when the app keeps restarting itself.
- Crash recovery — how Omniscio comes back after it dies.
Last verified 2026-09-25