Scheduled and recurring tasks

Cowork can run a task on a schedule. Anthropic's framing: "Tell Claude once to check your email every morning, pull your metrics every week, or compile a Friday report, and it handles it from there without being asked again."

Without being asked again is the whole feature and the whole risk in one phrase.

A schedule is a standing grant

A one-off task is a decision you make with the situation in front of you. A recurring task is that decision, applied to every future situation, by something that will not notice the difference.

The access you granted in January is still in force in June. The instruction that suited the data you had then is running against data you have not seen. Nothing prompts a re-read.

That is not an argument against scheduling. It is an argument for scheduling the things whose inputs are stable and whose failure is visible, and for putting a review date on the rest.

The machine still has to be there

The constraint from running unattended applies to every occurrence, not just the first. A local task needs the computer awake and the desktop app open when the schedule fires. Overnight, that usually means it does not run.

For anything that should fire whether or not you are at your desk, use a cloud session. This is the single most common reason a schedule silently produces nothing.

What suits a schedule

Tasks where the input is a stream you already trust and the output is something you read rather than something that acts.

A Friday summary you review. A weekly metrics pull. A morning triage that labels things for you and stops there.

What does not

Anything that sends, publishes, pays or deletes without a person in between. The gap between an unattended action and someone noticing is a week, and a recurring task repeats its mistake on schedule until somebody looks.

Anything reading content other people write is also worth thinking about twice. A task that processes incoming mail every morning is a task that reads whatever arrives, which is the injection surface with a cron entry attached. Combine that with tools that reach outward and you have a channel that runs on a timer.

Keep the thread, but read it

Cowork keeps a single persistent thread: "This thread doesn't reset." You can message from a phone and follow up from a desktop in the same conversation.

Continuity helps, and it also means an accumulating history that nobody has re-read since setting the thing up. Schedule a look at your own schedules, at whatever interval matches the answer above.

Try this

List your recurring tasks. For each, write the date you created it and the date you last read its output properly.

Where the second date is missing, you have a task running on trust rather than on evidence. That is the one to review first.

What goes wrong

Scheduling a local task overnight. The machine sleeps and it does not run.

Set and forget. The grants persist, the inputs change, and nothing reconciles the two.

A recurring task with side effects. One mistake becomes a weekly mistake.

Never reading the output. A schedule producing something nobody reads is consuming quota to no purpose, and doing it reliably.

How to check it worked

Read one occurrence of every schedule you run, end to end, including the step trail. If the work is right and the reach is what you expected, keep it and set the next review date. If you cannot say what it touched, the task has been operating outside your knowledge for however long it has existed, and that is the finding rather than the output.