{"version":"2.1.293","anchor":"trigger-fire-scheduling-needs-a-fourth-argument-to-be-later","canonical_anchor":"trigger-fire-scheduling-needs-a-fourth-argument-to-be-later","heading":"Trigger-fire events are put off until later in fewer cases","tier":"internal","area":"Elsewhere","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.293\/e\/trigger-fire-scheduling-needs-a-fourth-argument-to-be-later","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.293","markdown":"### Trigger-fire events are put off until later in fewer cases\n\nClaude Code now defers a trigger-fire event only when an extra piece of information comes with it, so fewer are put off\n\n**Unclear.** What a trigger-fire event is for a user, and what extra information decides whether it waits, is not stated.\n\n**What**\n\nClaude Code decides whether some events run now or are put off until later. For events of the kind called `trigger_fire`, it now puts them off only when an extra piece of information is supplied along with the event. Without that information, they are no longer deferred on that basis.\n\n**Why**\n\nIn practice this narrows the cases where a trigger-fire event waits instead of running straight away.\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}