Shipped 2026-08-30. A trigger's continuation is what a firing does. Before this change, every firing either started a thread (a model read the prompt plus the event) or woke a parked run. Two new kinds run without a model: tool makes one journaled tool call, and script runs a workflow module headlessly. Both run as a workflow run linked from the firing. An optional onFailure: 'thread' setting escalates into the ordinary trigger thread when the run fails.

The triggers reference documents the full behaviour: the $event input template, the write-time checks, the firing statuses (running, succeeded, escalated), and the desktop forms. Read that page for current details.

What changed in the code at the time:

TriggerContinuation gained the tool and script members and TriggerFailurePolicy.

trigger_firings gained a run_id column.

Every fire site calls one entry point. It enqueues the headless run with no session and a deterministic id (firing-<id>), so a duplicate firing does nothing.

A failed run with onFailure: 'thread' starts a recovery session titled <trigger> — automation failed: <summary>, with the failure attached inside <trigger_context>.

The model-facing contract at read ~/triggers/ and the ~/tools/write/triggers guide gained the example of authoring a tool and then wiring a webhook to it.

Limits that still hold:

Headless runs have maxAttempts: 1, so there is no automatic retry.

The write-time tool check consults the registry and the agent's tool documents, but not definition.tools narrowing. An excluded tool fails at run time, and the workflow's usual "not available" error is recorded on the firing.

ctx.delegate from a trigger script creates a top-level session.

A trigger script can call execute only where the server offers code execution.

Tests: the headless cases in trigger-events.test.ts, the webhook $event.payload path in main.test.ts, the validation and explanation cases in verbs.test.ts, and the run_id column assertions in sqlite.test.ts.

See also