github / github/copilot-cli

Scheduled prompts interrupt and halt the task queue

Open
#4,079 0 comments 0 reactions 0 assignees View on GitHub
area:sessions
Dominant language
Shell
Stars
11.2k
Forks
1.9k
Avg merge
14h 16m
Merged PRs (30d)
6

Description

## 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

1. Start an interactive Copilot CLI session with experimental mode enabled
2. Queue up multiple tasks (e.g., 15 items in the inbox/queue)
3. Schedule a prompt with `/every 1h check for new issues`
4. Let the queue start processing tasks
5. Wait for the scheduled prompt to fire
6. 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:
```pseudocode
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.

Contributor guide

Open the contributing guide

Research direction

Begin at the /every and /after scheduling entry points and trace how a completed scheduled prompt interacts with queue draining. Reproduce the issue with multiple queued tasks and a scheduled prompt, then verify that completion resumes processing the next queued item without waiting for the next schedule.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.