Unattended Runs
How automations run while the app is closed: the background service, sleep catch-up, locked credentials, permission rules and pause-for-approval
The background service
Automations execute inside PandaOS itself — but the app no longer needs a window to be "running". A background service (PandaOS resident in the system tray, headless) keeps the scheduler, integrations and credentials alive:
- Starts at login by default. Settings → General → Start Background Service at Login (on by default) registers a login item that boots PandaOS invisibly. The separate Launch at Login toggle additionally opens the window.
- Closing the window doesn't stop it. With Keep Running in Background (default on), closing the window hides PandaOS to the tray and schedules keep firing. Choose Quit PandaOS from the tray menu to exit completely.
- Opening the app later materializes the window in the same process — there is never a second copy competing to run your automations.
Sleep and missed schedules
While the machine actually sleeps, nothing can execute. What happens to a missed fire is the automation's catch-up policy:
- Run once on wake (default for new automations) — the automation fires once shortly after wake or service start, no matter how many fires were missed.
- Skip — a skipped run is recorded instead ("Machine was asleep" / "App was closed").
Automations created before catch-up existed default to Skip, so updating PandaOS never causes surprise runs. The default for new automations is Settings → General → Missed Runs After Sleep.
Locked credentials
Unattended runs use the integration credentials stored on this machine. If the system keychain can't be unlocked when a run starts, the run fails fast with a distinct credentials locked warning — shown amber in the run detail, with an OS notification — and simply runs again on its next schedule. No cryptic per-tool auth errors.
Permission modes and rules
Every automation has a permission mode (Shield icon on its detail view):
- Full access — any tool, no prompts. Simplest, biggest blast radius.
- Restricted — a limited tool set, never asks.
- Rules — only pre-allowed tool calls run; anything else pauses the run for your approval.
Rules are parameter-aware: gmail_send only when to matches *@pandata.de, Bash only when command matches npm run *:check. A rule names one tool plus optional per-parameter matchers (exact or glob; * matches anything, matching is case-insensitive). All matchers on a rule must match; any rule in the list can allow a call. Read-only tools (Read, Grep, Glob…) are always allowed as a built-in baseline.
Rules attach to the automation directly and/or via rule sets — reusable bundles managed in the Rule-set library (Automations tab header) and shared across automations. The effective-rules preview shows everything the automation may do unattended, with the source of each rule. Rules mode always runs on the Claude Code engine.
Pause & approve
When a rules-mode run hits a call no rule covers:
- The run pauses (awaiting approval) and an OS notification appears — click it to open the approval.
- The approval card at the top of the Automations tab shows the tool and its full arguments. Choose Deny (the agent adapts and continues), Approve once (this exact call, this run), or Approve & always allow — which saves a rule you can edit per-parameter first, with one-click generalization like
*@your-domain.com. - If you don't answer before the approval timeout (Settings → General, default 24 h), the automation's fallback applies: deny the call & continue (default) or fail the run.
Limitations: a run paused for approval does not survive an app/service restart — it fails with "interrupted while paused for approval" and runs again on its next schedule. Webhook triggers still require the service to be running and reachable.