GitHub Copilot CLI Scheduled Prompts Automation Guide

As of June 03, 2026, GitHub Copilot CLI scheduled prompts are useful when you want a terminal agent to keep checking, testing, summarizing, or reporting without manually retyping the same instruction. The reliable pattern is to separate two cases: use /every and /after for prompts that should fire while an interactive session stays open, and use an external scheduler with copilot -p for jobs that must survive logout, terminal closure, or machine restarts.

Prerequisites

Install or update Copilot CLI using one of the official methods from the GitHub installation guide. The npm path is:

npm install -g @github/copilot

If your npm config sets ignore-scripts=true, GitHub documents this variant:

npm_config_ignore_scripts=false npm install -g @github/copilot

Start the CLI once and authenticate when prompted. On first launch, Copilot CLI can ask you to use /login. For non-interactive hosts, GitHub also supports a fine-grained personal access token with the Copilot Requests permission exposed through COPILOT_GITHUB_TOKEN, GH_TOKEN, or GITHUB_TOKEN.

Step By Step: Build A Reliable Loop

1. Decide whether the loop is session-scoped or durable

• Choose /every when you are actively watching an interactive session and want repeated prompts.
• Choose /after when you need a one-time delayed prompt in the same live session.
• Choose copilot -p under cron, Task Scheduler, or CI when the automation must run without an open Copilot session.

2. Create a live recurring prompt with /every

Inside an interactive Copilot CLI session, use /every followed by an interval and the prompt. GitHub documents s, m, h, and d suffixes; a bare number means minutes. The minimum interval is 10 seconds and the maximum is 1 day.

/every 30m run npm test and summarize only new failures since the previous run

For a short-lived guardrail while you edit a risky area, use a tighter interval:

/every 10m inspect the last commit, run the focused test command, and tell me if the public API changed

3. Create a one-time delayed prompt with /after

Use /after for checks that should happen once after a delay. This is good for reminders, delayed validation after a deployment, or a follow-up after a long local build.

/after 20m check whether the staging smoke test has finished and summarize failing endpoints

You can schedule user-invocable skills the same way, either by naming the skill naturally or by using its slash command. GitHub notes that built-in slash commands such as /clear cannot be scheduled.

4. Make durable automation with copilot -p

For real terminal automation loops, write a small wrapper script and call Copilot CLI in non-interactive mode. GitHub's programmatic reference documents -p and --prompt for executing a prompt and exiting; -s suppresses decorations so output is easier to pipe.

#!/usr/bin/env bash
set -euo pipefail

cd /srv/my-app

prompt='Run npm test. If tests fail, summarize the failing test names and the most likely changed files. Do not modify files.'

copilot -p "$prompt" \
  -s \
  --allow-tool='shell(npm test), read' \
  --deny-tool='write' \
  --no-ask-user \
  --secret-env-vars='DATABASE_URL,STRIPE_SECRET_KEY' \
  >> /var/log/copilot-test-loop.log 2>&1

This wrapper has four reliability properties:

• It runs from a known working directory instead of depending on the scheduler's launch path.
• It grants only the tools needed for the job with --allow-tool and blocks file modification with --deny-tool.
• It uses --no-ask-user so the job fails or completes instead of waiting forever for input.
• It redacts named secret values from output with --secret-env-vars.

5. Add the scheduler

On macOS or Linux, open your crontab and schedule the wrapper. This example runs every hour at minute five:

crontab -e

5 * * * * /srv/my-app/scripts/copilot-test-loop.sh

For Windows, create a Task Scheduler task that runs the Copilot wrapper under a user account with access to the repo and token environment. Keep the same design: fixed working directory, explicit permissions, log file, and non-interactive prompt.

Verification And Expected Output

Interactive schedule verification

To list active session schedules, type /every or /after with no arguments. When a scheduled prompt fires, GitHub says Copilot labels it with text like [Scheduled prompt #4]. Use that ID to reason about what ran and, when supported in the session, cancel the schedule with a natural command such as stop prompt 4.

/every

# Expected: an interactive list of active recurring schedules.
# Select an entry with arrow keys, press d to delete, or Esc to exit.

Durable loop verification

Before trusting cron, run the wrapper by hand from a clean shell:

env -i HOME="$HOME" PATH="$PATH" COPILOT_GITHUB_TOKEN="$COPILOT_GITHUB_TOKEN" \
  /srv/my-app/scripts/copilot-test-loop.sh

tail -n 40 /var/log/copilot-test-loop.log

The expected result is not a byte-for-byte string, because the model response is generated. Verify these concrete signals instead:

• The command exits with status 0 for a successful test run or produces an actionable failure summary.
• The log contains the command result and Copilot's response, without terminal UI decoration when -s is used.
• Secret values configured in --secret-env-vars do not appear in the log.
• No files changed when the loop is intended to be read-only; confirm with git status --short.

Troubleshooting: Top 3 Failures

1. The scheduled prompt stopped running. If you used /every or /after, check whether the original interactive session is still open. Reopen with the CLI's resume or continue flow if that matches your workflow, or move the job to cron with copilot -p.
2. The cron job works manually but not on schedule. Cron starts with a minimal environment. Set PATH, HOME, token variables, and the working directory inside the wrapper rather than assuming your login shell config was loaded.
3. The agent hangs waiting for input. Add --no-ask-user, narrow the prompt, and pre-authorize only required tools with --allow-tool. If the task needs network or extra directories, grant them explicitly with official options such as --allow-url or --add-dir.

What's Next

Once the read-only loop is stable, extend it in small steps:

• Add structured log rotation before the file grows without bound.
• Use --prompt from CI to generate release notes, dependency summaries, or failure triage comments.
• Move write-capable jobs behind review by letting Copilot draft a branch or pull request instead of committing directly from a scheduler.
• Run formatting after generated edits. For quick cleanup of pasted snippets, TechBytes' Code Formatter is useful before you turn a prompt into a repeatable script.
• Review GitHub's official scheduled prompts guide and programmatic CLI reference when you add permissions, models, agents, or external URLs.