GitHub Copilot CLI Scheduled Prompts Tutorial [2026]

Scheduled prompts in GitHub Copilot CLI are useful when you want a terminal agent to keep checking, testing, or summarizing without retyping the same instruction. The reliability trap is persistence: GitHub documents /every and /after as experimental, interactive-session features, while unattended jobs should run copilot -p from an external scheduler. This tutorial builds both patterns, then adds permissions, logs, and verification so the loop behaves like engineering automation instead of a hopeful chat transcript.

Prerequisites

Install from the official GitHub path for your platform, then start a session in the repository you want Copilot to inspect. GitHub's installation guide also documents direct binary downloads and token-based authentication.

curl -fsSL https://gh.io/copilot-install | bash
cd ~/work/my-repo
copilot
/login

Build the Loop

1. Start with an interactive schedule

For a loop you actively monitor, launch Copilot CLI with --experimental or enable experimental mode inside the session. GitHub's scheduled prompts documentation says /every and /after are available only in experimental mode.

copilot --experimental
# or, inside the session:
/experimental on

Now schedule a bounded recurring prompt. Keep the instruction narrow: tell Copilot what to inspect, which commands are allowed conceptually, where to write output, and when to stop.

/every 30m run npm test, summarize only new failures, and write a short report to .copilot-reports/test-loop.md

Use /after when the job should run once after a delay. This is useful for checking whether a background process, preview deploy, or flaky test stabilized.

/after 10m check whether the local server on port 3000 still responds and summarize the result

2. Manage the live schedule

The schedule manager is intentionally lightweight. In the interactive session, run the command with no arguments to list active schedules. GitHub documents the same behavior for /every and /after.

/every
/after

• Use the arrow keys to select a schedule in the manager.
• Press d to delete the selected schedule.
• Press Esc to leave the schedule list.
• When a scheduled prompt fires, Copilot prefixes it with a scheduled prompt ID.

The important limitation: schedules are scoped to the session. If you close and reopen the session with --continue or --resume, the interval restarts from the moment the session is reopened.

3. Move durable loops to an external scheduler

If the job must run overnight, after logout, or on a runner, use copilot -p. GitHub's automation docs define this as the programmatic mode: the CLI processes the prompt and exits.

mkdir -p .copilot-reports
copilot -p "Run npm test, identify failures introduced in the last day, and write a concise report to .copilot-reports/nightly.md" \
  --allow-tool='shell(npm test)' \
  --allow-tool='shell(git:*)' \
  --allow-tool=write \
  --no-ask-user

On macOS or Linux, wrap that command in a script and schedule it with cron. The script should set a working directory, create a log directory, and record stderr/stdout.

#!/usr/bin/env bash
set -euo pipefail
cd /srv/my-repo
mkdir -p .copilot-reports logs
copilot -p "Run npm test, compare with recent git history, and write .copilot-reports/nightly.md with failures and likely owners." \
  --allow-tool='shell(npm test)' \
  --allow-tool='shell(git:*)' \
  --allow-tool=write \
  --no-ask-user \
  >> logs/copilot-nightly.log 2>&1

# Run at 2:15 every morning
15 2 * * * /srv/my-repo/scripts/copilot-nightly.sh

For GitHub Actions, authenticate with COPILOTGITHUBTOKEN stored as a repository secret, then call copilot -p in a scheduled workflow. The official docs use --allow-tool and --no-ask-user for this exact automation shape.

name: Copilot nightly report
on:
  schedule:
    - cron: '15 2 * * *'
  workflow_dispatch:
jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Copilot CLI
        env:
          COPILOT_GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        run: |
          copilot -p "Review today's commits and test status. Write summary.md with failures, risk areas, and links to relevant commits." --allow-tool='shell(git:*)' --allow-tool=write --no-ask-user
          cat summary.md >> "$GITHUB_STEP_SUMMARY"

4. Design prompts like runbooks

Reliable loops need deterministic boundaries. Treat the prompt as an operational runbook, not a brainstorming request.

• State the goal in one sentence.
• Name the exact files, reports, or commands the agent may inspect.
• Require a fixed output path such as .copilot-reports/nightly.md.
• Ask for pass, fail, or inconclusive as the first line.
• Tell the agent not to modify source files unless that is the explicit job.

After Copilot writes code or config, run deterministic cleanup outside the prompt. For snippets and generated examples, TechBytes' Code Formatter is a practical final pass before sharing the output.

Verification and Expected Output

Verify three layers: scheduler registration, agent execution, and artifact quality. A live schedule should show up when you enter /every or /after with no arguments. When it fires, the prompt is marked with a scheduled prompt ID, which tells you the run came from the scheduler rather than manual input.

/every
# Expected: a schedule list containing the 30m test prompt

For cron or CI, the expected output is a completed process, a log entry, and a report file. A minimal successful report should look like this:

PASS
Checked: npm test, git log --since yesterday
Summary: No new failures detected.
Artifacts: logs/copilot-nightly.log

• If the process exits non-zero, inspect the scheduler log first.
• If the report is missing, check whether --allow-tool=write was granted.
• If the run hangs, check whether --no-ask-user is missing or the prompt requires clarification.

Troubleshooting Top-3

1. The /every command is unavailable

Enable experimental mode with /experimental on or start the CLI with --experimental. If your organization manages Copilot policy, confirm that Copilot CLI and experimental features are allowed for your account.

2. The schedule stopped after closing the terminal

That is expected behavior. Interactive schedules only fire while the session is running. For persistent jobs, move the same prompt to copilot -p and invoke it from cron, Task Scheduler, or GitHub Actions.

3. Automation waits for approval forever

Unattended jobs need explicit permissions. Add narrow --allow-tool rules for commands such as shell(git:*) or shell(npm test), grant --allow-tool=write only when a file must be created, and include --no-ask-user so the run fails instead of waiting for a human.

What's Next

Once the basic loop is stable, make it more observable and less privileged. The next iteration should add a fixed report schema, alert routing, and a review step before any automated source change lands.

• Promote reports into issues or pull request comments only after the local report is reliable.
• Split read-only monitoring loops from write-capable remediation loops.
• Use --deny-tool for commands that should never run, such as pushes or deploys.
• Keep prompts short, versioned, and reviewed like scripts.
• Revisit GitHub's Copilot CLI command reference before adopting new flags or slash commands.

The durable pattern is simple: live-session schedules for active supervision, external schedulers for unattended execution, and explicit permissions everywhere. That is what turns scheduled prompts from a clever terminal trick into a maintainable automation loop.