GitHub Copilot CLI Scheduled Prompts Done Right [2026]

Scheduled prompts in GitHub Copilot CLI are useful when you want an agentic terminal session to keep checking, testing, or summarizing without another manual nudge. The catch is scope: /every and /after run only inside an active interactive session, while durable automation needs an external scheduler calling copilot -p. This tutorial builds both patterns, then wraps them with logs, bounded prompts, and verification so the loop is observable instead of mysterious.

Prerequisites

Install and authenticate the CLI before building any schedule. GitHub's Copilot CLI getting-started guide documents npm, WinGet, and Homebrew installation paths, then starts the first session with copilot and /login.

npm install -g @github/copilot
# or: brew install copilot-cli
# or: winget install GitHub.Copilot

copilot
/login

Because automation often echoes repository data into prompts, scrub secrets before sharing logs or examples. For reports that include customer-like payloads, run samples through TechBytes' Data Masking Tool before pasting them into prompts or tickets.

1. Use live-session schedules first

The interactive scheduler is the fastest way to keep a local loop running while you are actively steering a session. GitHub's scheduling documentation marks /every and /after as experimental, so enable experimental mode in the session or launch with --experimental.

copilot --experimental

Inside the session, schedule a recurring check with /every. The syntax is interval first, prompt second.

/every 30m run the frontend tests and summarize only new failures

Use /after for a delayed one-shot check:

/after 10m check whether the local build is still passing and list changed files

Intervals accept seconds, minutes, hours, and days with s, m, h, and d. A bare number is interpreted as minutes. The documented minimum interval is 10 seconds, and the maximum is 1 day.

What this pattern is good for

• Running repeated checks while you keep the same terminal session open.
• Asking for periodic summaries of test failures, token use, pull request comments, or file changes.
• Triggering user-invocable skills on a cadence, such as a review or refactor-planning skill.

2. Make each prompt bounded and reviewable

A scheduled AI prompt should read more like a runbook step than a chat message. Give Copilot a narrow command, a success condition, and a reporting format. That makes repeated runs easier to compare and less likely to drift into broad code changes.

/every 1h run npm test -- --runInBand. If tests fail, report:
1. failing test file
2. first error message
3. suspected changed file
Do not edit files unless I explicitly approve.

For automation loops, define guardrails directly in the prompt:

• State whether file edits are allowed.
• Specify the exact command to run, not just "check the app".
• Ask for deltas since the previous run when possible.
• Require a compact output format that can be logged or posted to an issue.
• Keep secrets, tokens, and production data out of prompt context.

For larger code tasks, use /plan before implementation. GitHub recommends planning for multi-file work because the CLI can analyze, ask questions, create a plan, and wait for approval before writing code.

3. Build a durable cron loop with copilot -p

For reliability, move from in-session scheduling to the programmatic CLI mode. GitHub documents -p for passing a prompt without opening the interactive interface, and -s for response-only output. That is the right shape for cron, CI, and shell scripts.

Create a wrapper script that captures output, timestamps runs, and exits cleanly when Copilot fails.

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

REPO="/srv/apps/checkout"
LOG_DIR="$REPO/.copilot-scheduled"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
LOG_FILE="$LOG_DIR/test-report-$STAMP.md"

mkdir -p "$LOG_DIR"
cd "$REPO"

PROMPT=$(cat <<'PROMPT_EOF'
Run npm test. Summarize failures in Markdown with these headings:
Status, Command, Failing files, First actionable fix.
Do not modify files. Do not include secrets or environment values.
PROMPT_EOF
)

if copilot -sp "$PROMPT" > "$LOG_FILE" 2> "$LOG_FILE.err"; then
  printf 'ok %s
' "$LOG_FILE"
else
  printf 'copilot failed; see %s.err
' "$LOG_FILE" >&2
  exit 1
fi

Make it executable and test it manually:

chmod +x ./scripts/copilot-test-report.sh
./scripts/copilot-test-report.sh

Then schedule it with cron on Linux or macOS:

# Run every weekday at 8:15 UTC
15 8 * * 1-5 /srv/apps/checkout/scripts/copilot-test-report.sh >> /srv/apps/checkout/.copilot-scheduled/cron.log 2>&1

Why the wrapper matters

• It centralizes the prompt, so schedule changes do not hide in crontab history.
• It keeps stdout, stderr, and generated reports in predictable files.
• It makes failures visible to cron, CI, or monitoring by returning a nonzero exit code.

4. Verify output and session behavior

Verification has two layers: prove the scheduler fires, then prove the output is useful. In an interactive session, list active schedules by typing /every or /after with no arguments. When a scheduled prompt fires, Copilot labels it with text like [Scheduled prompt #4], which gives you an ID you can cancel or track.

/every
/after

Expected interactive signs:

• The schedule list shows the interval or delay and the prompt text.
• A triggered run is prefixed with a scheduled prompt ID.
• A one-shot /after prompt disappears after it fires.
• Closing the session stops execution until the session is reopened.

For the cron wrapper, check the generated report and error file:

ls -1 .copilot-scheduled/
tail -50 .copilot-scheduled/cron.log
sed -n '1,80p' .copilot-scheduled/test-report-*.md

Expected output should be boring and structured:

ok /srv/apps/checkout/.copilot-scheduled/test-report-20260611T081500Z.md

If the report contains long prose, missing command names, or unbounded recommendations, tighten the prompt. The goal is an automation artifact a developer can scan in under a minute.

Troubleshooting top-3

1. The slash command is not recognized

• Confirm the session is running with experimental features enabled via /experimental on or --experimental.
• Remember that /every and /after are interactive slash commands, not shell commands.
• Use copilot help and /help to confirm the installed CLI exposes the expected command set.

2. The schedule stopped after closing the terminal

• This is expected for in-session schedules; they fire only while that session is running.
• Use --continue or --resume to reopen a session, but do not treat that as durable scheduling.
• Move persistent jobs to cron, Task Scheduler, GitHub Actions, or another scheduler calling copilot -p.

3. The automation edits files unexpectedly

• Add "Do not modify files" to read-only prompts and keep commands explicit.
• Run first in a disposable branch or clean working tree.
• For code-changing jobs, require a plan, diff summary, tests, and human approval before commit or pull request creation.

What's next

Once the loop is stable, add observability. Copilot CLI can export OpenTelemetry traces and metrics when enabled with variables such as COPILOTOTELENABLED, OTELEXPORTEROTLP_ENDPOINT, or COPILOTOTELFILEEXPORTERPATH. That gives teams visibility into agent turns, tool calls, token usage, and errors.

The production pattern is simple: keep live-session prompts for human-supervised cadence, use copilot -p for unattended schedules, and make every prompt narrow enough to audit. From there, wire reports into issues, chat, or CI dashboards, then graduate only the lowest-risk loops into automatic code-changing workflows.