[Feature]: Skip scheduled task occurrences when the bound thread is already running

[KobieHazon]

Problem or use case

A recurring scheduled task can target a thread that the user is actively working in. I want the scheduled occurrence to be skipped when that thread already has an active agent turn, without manually pausing and re-enabling the schedule.

For example, a maintenance task runs every hour in a thread. If a coding task is still running at the hourly trigger, skip that occurrence and try again at the next regular scheduled time.

Proposed solution

Add an optional Skip if thread is running setting for thread-bound scheduled tasks, available in the schedule editor and the scheduler MCP create/update tools.

When enabled:

• Check whether the bound thread has an active turn immediately before dispatch, with a guard that prevents a race with another turn starting.
• If it is busy, skip that occurrence without interrupting the active turn or queueing the scheduled prompt for later.
• Keep the task enabled and advance to its next normal scheduled time, without accumulating missed runs.
• Show a reason such as Skipped: thread was running in the task's run history/status.

Smallest useful scope

An opt-in setting for recurring tasks bound to an existing thread. Tasks that create a fresh thread per run do not need this behavior. Preserve existing behavior when the setting is disabled.

Why this matters

Recurring maintenance and check-in tasks should be able to run only when their thread is idle. A scheduler-level check provides that guarantee before a prompt is dispatched; an instruction inside the scheduled prompt cannot prevent dispatch.

Related requests

Related to the general scheduling request in #7966; this request specifically concerns skipping an occurrence when its target thread is already running.

[AdEx-Partners-DE]

+1, and a data point: I ran into exactly this at scale. 13 tasks on a 15-minute interval left 56 prompts queued, 40 in one thread.

My fork now does a narrow version: a timed task skips its slot while its own previous prompt is still queued or running in the bound thread, and only recalculates the next run. Someone else's prompt in the thread does not block it. There is a service-level test for both cases, and the pile-up has not come back.

Your version (skip when the thread has any active turn) is stricter. I could see both as one option with two values. Which one would you want as the default?

Code: 13baaa6aa. on stark/main.

---

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.