A trigger spawns a session on its own — this is how you automate recurring or event-driven work. Triggers are triggers entries in the project manifest (kortix.yaml; [[triggers]] in legacy kortix.toml); by default, each fire starts a fresh session that runs a templated prompt as its first message.

cron — runs on a schedule (6-field cron expression + IANA timezone).
webhook — runs on a signed POST to the project's webhook URL. No unauthenticated surface: a webhook trigger must name a signing secret.

A fresh-mode fired session is an ordinary session — isolated sandbox, its own branch, work reviewed as a change request. The manifest holds the config; runtime state (e.g. last_fired_at) lives in the database, so a fire doesn't write a commit.

A trigger can instead opt into session_mode: reuse: each fire re-prompts the most recent session that trigger already created — resuming its existing sandbox and branch instead of spawning a new one — so context accumulates across fires. This suits recurring cron triggers that should feel like one long-lived agent run rather than a new isolated task every time. If no reusable session exists yet (or the last one is dead or failed), the trigger falls back to creating a fresh session, which then becomes the canonical one for the next fire.

The scheduler reads triggers from the default branch, so a new or edited trigger goes live only after its change request merges. Fields, signature format, and template variables: Triggers.