Unattended Runs
How an automation runs while the app is closed, and what happens when it cannot.
A locked keychain fails fast
A run that cannot unlock the system keychain stops immediately with a credentials-locked warning, amber in the run detail with a notification, and tries again on its next schedule. It never runs half-authenticated.
The background service
Automations run inside PandaOS, but the window does not have to be open. A background service in the system tray keeps the scheduler, the integrations and the credentials alive. It starts at login by default, in Settings, General.
When the machine sleeps
Nothing executes while it is asleep, so each automation says what to do about the fires it missed: run once on wake, the default, which fires once however many were missed, or skip, which lets them go.
How much it may do
- Full access. Any tool, no prompts. Simplest, and the most that can go wrong.
- Restricted. A limited set of tools, never asks.
- Rules. Only pre-allowed calls run; anything else pauses the run and waits for your approval.
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.