The scheduled task that only ran on days my desk was awake

On a Monday morning, the research summary I expected was not there. Through the previous Friday, the same task had been leaving the same output at the same hour.

I opened the settings. The schedule was intact. There was no failure notice. What was missing was the run history itself, and only for Saturday and Sunday.

I found it by walking back through the creation dialog. In the field asking which folder Claude should work in, I had picked one folder on my own machine. That single field had quietly pinned the task to my desk.

The last field in the dialog decides where the task lives

By default, scheduled tasks run remotely. The official help center states that scheduled tasks run remotely, so they keep their cadence even when your computer is asleep or the Claude Desktop app is closed.

The manual setup steps, though, carry a short note under the working-folder field: if a scheduled task requires local files or apps, it will only run locally. The same page adds that scheduled tasks work with built-in schedule options, your connectors, and the files saved to your Claude account — and that they cannot be tied to a folder on your computer.

So the field that names a location also names an execution environment. The source is Schedule recurring tasks in Claude Cowork (Claude Help Center).

That last row is the one people miss. A day your machine was closed does not arrive as an alert — it arrives as a day when nothing happened. That is why my weekend gap waited until Monday to reach me.

What I had confused was where the materials lived

As an indie developer with more moving parts each year, I had picked up the habit of naming a working folder for every task. The reason was thin: naming a folder made the destination of the output feel settled.

It did not serve me well. Research tasks that never touched a file were tied to my machine anyway, and on days I was out, or nights I shut things down, they stopped together.

Looking back, I had read that field as a place to put the output. What it was really answering was a different question — not where the result goes, but where the work happens.

Now I sort tasks by where their materials are. Work that reaches into a connected folder — sorting source images for my wallpaper app, for instance — goes in a slot when the machine is awake. Research for topics on the Lab sites leaves the folder field empty and runs remotely.

Work that needs my desk belongs in the hours my desk is open. Since I wrote that line down, outputs have stopped disappearing on particular days of the week.

Three questions before opening the dialog

There are three questions I answer out loud before creating a task.

1. Where do the materials live? If connectors and account files are enough, leave the folder field empty. If the task must read something on your machine, plan for it to be a local task from the start.
2. Where should the output end up? A briefing you read in your inbox and an updated file that must sit in a folder are not the same requirement, and they do not want the same execution environment.
3. When would you notice a miss? For something you read every morning, the next morning. For something you only use at month end, a month later. The longer that gap, the less you want the task tied to a machine.

Only the third question has no matching field in the dialog. That is exactly why it is worth answering before you start.

Have each run tell you where it happened

Rather than guessing, I ask every task to print one line about its environment and paste it at the bottom of whatever it produces.

# Three lines to run at the end of the task; paste the output into the result
TZ=Asia/Tokyo date '+run at %Y-%m-%d %H:%M'
uname -s -m
# Replace the path with your own connected folder
[ -d "$HOME/Workspace/Materials" ] && echo "connected folder: visible" || echo "connected folder: not visible"

The output you are looking for is three short lines.

run at 2026-09-16 07:00
Linux x86_64
connected folder: not visible

If the third line says the folder is not visible, that task never touches a local file, and clearing the folder field will not change its output. If it says visible, rebuild the task assuming it only runs while the machine is open.

The value of those three lines shows up on the days nothing goes wrong. A row of healthy records is what gives a missing day a shape. On catching runs that end without a sound, I wrote more in Why Cowork Scheduled Tasks Stop Mid-Run and How to Recover.

When the work truly needs local files

You do not have to give up daily cadence for work that touches folders. What settled for me was splitting one task into two.

The first half — gathering and shaping the material — runs remotely. Only the second half, filing the result into a local folder, sits in a machine-bound slot. The first half advances every day regardless of my machine, so the material is waiting by the time I sit down.

The other route is to move the materials themselves to the cloud side. Once they are reachable through a connector, the task is free of your machine. Deciding what to hand over is a separate question, and I put my thinking on scope in What you keep the agent from walking matters more than what you hand it.

Keeping both modes and choosing between them is where I landed. Nothing had to move entirely to the cloud, and nothing had to stay entirely on the desk.

One thing to do today

Open one scheduled task you already run and look only at the working-folder field. If something is named there while the instructions never touch that folder's contents, clearing the field is all it takes to free that task from your power button.

If you have several tasks tied to folders, resist clearing them all at once. Change one, watch a week of run history, and let the record tell you whether anything actually depended on the machine. A week of evidence costs you nothing and settles the question better than my advice can.

I started with a single task. I still remember how it felt to find the result already waiting before I sat down the next morning.