Summary
When a scheduled prompt fires (/every or /after), it interrupts and stops the existing task queue from processing. The queue doesn't resume until the schedule time comes up again, which could be hours or days away.
Steps to Reproduce
- Start an interactive Copilot CLI session with experimental mode enabled
- Queue up multiple tasks (e.g., 15 items in the inbox/queue)
- Schedule a prompt with
/every 1h check for new issues
- Let the queue start processing tasks
- Wait for the scheduled prompt to fire
- Observe that after the scheduled prompt completes, the queue does NOT resume processing the next queued item
Expected Behavior
After the scheduled prompt fires and completes, the runtime should automatically resume draining the queue - popping the next item and processing it. The scheduled prompt should not permanently halt the queue.
Actual Behavior
The scheduled prompt interrupts the queue and the queue remains halted until the next scheduled time arrives. This can mean the queue is stuck for hours or days if the schedule interval is long.
Environment
- Copilot CLI version: latest experimental
- Mode: experimental mode with
/every scheduling
- OS: Windows 11
Impact
- High: Blocks all queued work for extended periods
- Affects workflows that depend on queue processing (e.g., batch PR reviews, issue triage, test runs)
- Makes
/every scheduling unreliable when you also have a queue of tasks
Suggested Fix
Add queue resumption logic after scheduled prompt completion:
function onScheduledPromptComplete(scheduleId) {
if (queue.hasNext()) {
dispatchNextQueueItem()
}
}
Alternative: Add a config option resumeQueueAfterSchedule: true to control this behavior.
Additional Context
The user explicitly requested this behavior: when an AI agent schedules its own prompts, it should not kill in-flight work. The scheduler should either:
- Resume the queue after the scheduled prompt completes, OR
- Warn the user that scheduling will pause the queue and ask for confirmation
This is particularly problematic when the AI autonomously schedules prompts during a session with active queue items.
Summary
When a scheduled prompt fires (
/everyor/after), it interrupts and stops the existing task queue from processing. The queue doesn't resume until the schedule time comes up again, which could be hours or days away.Steps to Reproduce
/every 1h check for new issuesExpected Behavior
After the scheduled prompt fires and completes, the runtime should automatically resume draining the queue - popping the next item and processing it. The scheduled prompt should not permanently halt the queue.
Actual Behavior
The scheduled prompt interrupts the queue and the queue remains halted until the next scheduled time arrives. This can mean the queue is stuck for hours or days if the schedule interval is long.
Environment
/everyschedulingImpact
/everyscheduling unreliable when you also have a queue of tasksSuggested Fix
Add queue resumption logic after scheduled prompt completion:
Alternative: Add a config option
resumeQueueAfterSchedule: trueto control this behavior.Additional Context
The user explicitly requested this behavior: when an AI agent schedules its own prompts, it should not kill in-flight work. The scheduler should either:
This is particularly problematic when the AI autonomously schedules prompts during a session with active queue items.