Recurring work that is still running next week

The failure mode here is quiet. You set up a daily job, it confirms, and
weeks later you discover it ran twice and then stopped. Nothing errored.
Nobody was told.

This is how to avoid that.

The trap: session-scoped scheduling

The assistant has a built-in scheduler. It accepts your job and confirms it.
Read the confirmation carefully — it says the job is session-only, not
written to disk, dies when the process exits, and auto-expires after 7 days.

So it cannot run anything daily. If your session restarts between turns — and
most do — the job is already gone.

Use the built-in scheduler for: "check again in 20 minutes, during this
session."
Never use it for: anything that must happen tomorrow.

Where the schedule actually belongs

Put it in the operating system. It outlives the assistant, the terminal, and
the reboot.

Windows

schtasks /create /tn "<name>" /tr "<full command>" /sc daily /st 09:00
schtasks /query  /tn "<name>" /fo list          # prove it exists
schtasks /run    /tn "<name>"                   # run once, now, to test
schtasks /delete /tn "<name>" /f

macOS / Linux

crontab -e
crontab -l                                      # prove it exists

Use absolute paths in the command. A scheduled task does not inherit your
shell's environment, your working directory, or your PATH. This is the most
common reason a task "runs" and does nothing.

Make it prove itself

A scheduled job you cannot verify is a job you should assume is broken.

Have the job write a line — timestamp and outcome — to a log file every run,
including the runs where there was nothing to do. Then "is it alive?" is
answered by looking at the file, not by trusting the scheduler.

[2026-03-01 09:00:03] ran, nothing to do
[2026-03-02 09:00:02] ran, 2 items processed

A gap in that file is the alarm. Without it, silence looks identical to
success.

Test it the hard way, once

Before you trust a schedule, run the command exactly as the scheduler will:
same account, same working directory, no interactive terminal.

Things that work in your shell and fail under a scheduler: relative paths,
commands that expect a TTY, anything that prompts, anything that needs a
logged-in desktop session, and credentials that live in your shell profile.

Run it once by hand through the scheduler (schtasks /run) and check the log
file. Do not wait until 9am tomorrow to find out.

Jobs that touch the screen need one more guard

If the recurring job clicks, types, or reads the screen, it will fight the
human using the computer. Add a check: if there has been keyboard or mouse
input in the last minute, skip this round and try again later.

Being a minute late is cheaper than stealing focus mid-sentence.

Choosing the interval

Match the interval to how fast the thing you are watching actually changes.
Checking every minute for something that changes twice a day is not
diligence, it is noise — and on a screen-touching job it is disruption.

Ask: if this fires and finds nothing, what did it cost? If the answer is
"nothing", frequent is fine. If the answer is "it interrupted someone",
slow down.