Skip to main content
The app calls these Scheduled tasks. The CLI command screenpipe pipe, local API paths under /pipes, and configuration file pipe.md retain their technical names. Use those exact identifiers in commands and configuration.

​
Overview

Scheduled tasks can access the Screenpipe API to read screen data, manage meetings, send notifications, and more. By default, scheduled tasks have full access to every endpoint — no restrictions. If you want to limit what a scheduled task can do, add a permissions block to the YAML frontmatter in pipe.md. This is useful for:
  • Preventing accidents — a scheduled task that reads meetings shouldn’t be able to stop one
  • Least privilege — scheduled tasks from the store should only access what they need
  • Safety — deny destructive endpoints like /data/delete-range

​
Quick start

This preset restricts supported Screenpipe API calls. It blocks meeting start/stop, deletion, and raw SQL, but also allows selected operations such as notifications, speaker-name updates, and submissions to output targets bound to the authenticated task. It does not sandbox shell commands, files, or external tools.

​
Presets

​
reader — restricted API defaults

Allowed endpoints: Everything else is denied.

​
writer — reader + write operations

Includes all reader endpoints, plus:

​
admin — full access (explicit)

Allows everything. Functionally the same as no permissions block, but creates a token for logging/auditing.

​
Custom rules

For fine-grained control, use allow and deny lists with Api(METHOD /path) patterns:

​
Pattern syntax

* in the method position matches GET, POST, PUT, DELETE, etc. * in the path position matches any sequence of characters.

​
Evaluation order

Rules are evaluated in this order — first match wins:
  1. Deny — if the request matches any deny rule, it’s blocked (403)
  2. Allow — if the request matches any allow rule, it passes
  3. Default allowlist — if allow is empty and the scheduled task uses a preset with defaults (reader/writer), the default list is checked
  4. Reject — if nothing matched, the request is blocked
Deny always wins over allow, just like firewall rules.

​
Examples

Deny specific endpoints (keep full access otherwise):
Allow only what you need (everything else denied):
Reader defaults + custom deny:
This uses the reader defaults but also blocks screenshot access.

​
Data access rules

Data filtering uses the same allow/deny lists with App(), Window(), and Content() rules:
Deny rules always win over allow rules. If no rules of a given type exist, everything is allowed.

​
How it works

When a scheduled task has any restrictions (permissions block, data filters, etc.):
  1. Screenpipe generates a unique token (sp_pipe_*) for the scheduled task session
  2. The token is registered with the server middleware
  3. Every API request from the scheduled task includes the token in Authorization: Bearer sp_pipe_*
  4. The middleware checks is_endpoint_allowed(method, path) before forwarding
  5. The Pi extension also enforces rules client-side (blocks curl commands before they run)
  6. When the scheduled task finishes, the token is cleaned up
Scheduled tasks without any restrictions run without a token — full access, zero overhead.

​
Common recipes

​
Meeting-safe scheduled task

Your scheduled task reads meeting data but should never interfere with active meetings:

​
Read-only analytics scheduled task

​
Work-hours-only scheduled task

Full API access, but time and day restrictions limit when data is visible. Need help? ask in our Discord