GitHub Copilot CLI can run /every and /after prompts only inside active experimental sessions; build safer cron fallbacks now. Full breakdown.
What scheduled prompts actually do in Copilot CLI
GitHub Copilot CLI supports scheduled-style prompts such as /every and /after so you can ask the agent to re-run a task on a cadence or after a delay instead of retyping the same instruction. That sounds like a built-in cron for coding work: refresh a status report, re-check a flaky test suite, or re-apply a fix pattern after a build finishes. In practice, those commands only run while an experimental session stays active. If the session ends, the schedule stops with it. There is no durable background worker implied by the prompt syntax alone.
Treat /every and /after as session-local timers, not production schedulers. They are useful for interactive loops while you are at the keyboard—short intervals, tight feedback, tasks that should stop when you leave. They are the wrong primary control plane for overnight jobs, unattended releases, or anything that must survive a disconnect, laptop sleep, or closed terminal.
Why “active experimental session” is the hard limit
An active experimental session means the CLI process is still running in a mode where scheduled prompt handling is enabled. The schedule is bound to that process lifetime. Network drops, shell exits, remote session timeouts, and intentional stops all cancel pending work. Experimental also signals that behavior can change: command shape, permissions, and failure modes may shift. Designing automation that assumes these prompts are always available and always reliable will break when the session or the experimental surface moves.
Before you lean on session schedules, map the failure modes you care about. Does the job need to run if you are offline? If the machine reboots? If the CLI is upgraded mid-run? If the answer is yes to any of those, the CLI schedule is a convenience layer at best. Keep it for live, supervised work and put durability elsewhere.
Build safer cron fallbacks outside the session
A safer pattern is to put the durable trigger in your OS or CI scheduler and treat Copilot CLI as the worker that runs when invoked. Cron, systemd timers, or a CI workflow own the clock. Each tick starts a fresh, non-interactive CLI invocation with a fixed prompt, a pinned working directory, and explicit environment. The schedule no longer depends on a human-held session remaining open.
- Write the task as a script or prompt file the CLI can run headlessly, with clear success and failure exit codes.
- Log stdout, stderr, and exit status to a dated file so missed or partial runs are visible without relying on chat history.
- Scope credentials and repo access to the minimum the job needs; do not reuse a long-lived interactive login for unattended runs.
- Add locks or a “already running” check so overlapping ticks do not stack concurrent agents on the same tree.
- Keep a manual kill path: a known process name, lock file, or CI cancel button so a stuck agent cannot burn tokens indefinitely.
Prefer one well-defined job per schedule entry. “Every hour, do the right thing” is hard to audit. “Every hour, run lint, open a draft PR only if diffs exist, and exit non-zero on tool failure” is testable. Validate the script by hand once, then let the external scheduler call the same path the CLI would use inside a session.
When to use /every and /after vs cron
Use /every and /after while you are iterating: poll a long build, re-run a check after a wait, or keep a short agent loop alive during a focused block of work. Use external cron (or equivalent) for anything that must fire without you, report outcomes, and survive session death. A practical hybrid is fine: explore the workflow interactively with session schedules, then promote the proven prompt into a scripted, scheduled job once the steps stabilize.
The takeaway for this tutorial is simple. Copilot CLI scheduled prompts are powerful inside an active experimental session and empty outside it. Design for that boundary now: enjoy in-session cadence for live work, and put safer cron fallbacks under anything you expect to run unattended.