Omniscio documentation
Browse all documentation
  1. Getting Started13
  2. Sessions & Agents115
  3. Inbox & Notifications59
  4. Projects & Tasks95
  5. Automation & Scheduling75
  6. Knowledge & Memory26
  7. AI Features60
  8. Integrations100
  9. Plugins & Marketplace33
  10. Cloud & Teams56
  11. Settings & Customization58
  12. Account & Billing28
  13. Troubleshooting84
  14. CLI & API Reference22
  15. Legal & Policies4
  16. Uncategorised22

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 400 body 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):

  1. Anonymous restart commands are refused. Every POST /app/restart caller must identify itself — a validated X-AMC-Source-Session-Id (AMC-spawned agents already have it in $AMC_SESSION_ID), a validated active X-AMC-Source-Cron-Job-Id, or the dev supervisor's own X-AMC-Restart-Origin header (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 clear 400 explaining 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.

  2. 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.

Last verified 2026-09-25