Claude Code loops versus scheduled tasks: identify what actually keeps running

Use a loop for a session-bound job

The 10 March 2026 video distinguishes /loop in Claude Code’s terminal from scheduled tasks in the Claude desktop app. The description says loops disappear when the session closes. A repeating instruction inside a live session is therefore a different operational choice from a saved task you expect to find again later.

1. Follow the /loop example at 0:28 using the command name supplied by the source; no exact interval syntax is reproduced in the description.
2. Choose a small infrastructure check and define its input, expected response and reason to stop.
3. Observe an actual repetition and record what happens when the session is no longer available rather than assuming the instruction survives it.

Define the desktop task and its permissions

The app demonstration starts at 1:47, with a side-by-side comparison at 2:43. It includes model selection and permissions. The source explicitly warns that neither approach runs 24/7 without its app or terminal open. Keep that historical limitation attached to the recording instead of treating the word “scheduled” as proof of an independent always-on service.

1. For a daily digest, specify the sources, date window and output destination before scheduling it.
2. Follow the recorded model and permission choices, checking what the task needs to read or change.
3. Inspect an actual run and compare its output with the intended inputs; saving a schedule is not a delivery receipt.

Consider GitHub Actions for repository-based execution

At 5:20 Luke discusses when GitHub Actions is a better fit, including end-to-end test suites among the examples. The useful comparison is where the job runs, what starts it and what evidence it leaves. Moving a task to another runner also changes its environment and access assumptions; it is not simply a new label for the same session.

1. Write the repository task, trigger and expected test result before choosing the runner.
2. Check that required inputs and permissions are available in that environment and keep secrets out of shared task text.
3. Review the actual run result and unresolved failures, then choose the simplest route that meets the job’s persistence needs.

The takeaway

Choose a recurring mechanism by its execution environment and checked behaviour, not by how autonomous its name sounds.