Claude Cowork scheduled tasks: what actually enters the context window
The coverage of Claude's scheduled tasks feature treats automation as the headline. Set up a task once, it runs on a schedule, work happens while you are away. That framing is technically accurate and practically incomplete.
The question that determines whether scheduled tasks are useful or useless is simpler: when Claude runs your scheduled prompt, what does it actually know?
What Claude reads when your scheduled task runs
A scheduled task is a prompt that executes automatically. When it runs, Claude starts a new Cowork session with your instructions. It does not inherit memory from previous sessions. It does not automatically check your calendar, your inbox, your project management tool, or any other external system.
What Claude knows at execution time is exactly what you give it — your prompt, plus whatever tool connections you have explicitly configured and Claude actively calls during that session.
If your task is "generate a daily briefing summarizing what happened in the project today," Claude cannot do that without a live connection to where that information lives. Without configured MCP integrations pointing at your actual project data, Claude is running your prompt against its training data and general reasoning ability. The output will look like a briefing. It will not be based on your actual data.
This is not a failure of the feature. It is what the feature is. The gap appears when the setup skips this step.
The two categories of tasks that actually work
Once you understand the data question, the distinction becomes clear.
Self-contained tasks work well and require no integrations. If your scheduled task processes files that already exist in a folder Claude can access, analyzes a document you have explicitly pointed to, or runs against a dataset your prompt specifies directly — the task is self-contained. The input is defined. The output is reliable.
Data-dependent tasks only work if the data pipeline is verified. A daily briefing works if Claude has working connections to your calendar, messages, or project tools via MCP — and if you have tested those connections produce the data you expect. A weekly report works if there is a defined source Claude reads, not a vague instruction to "summarize this week."
The difference matters in practice: self-contained tasks can be set up and run. Data-dependent tasks require infrastructure verification before automation adds any value.
The accountability problem automation creates
Automating a task does not remove the accountability for its output. It shifts when and how that accountability is exercised.
Before automation, you write the prompt, review the output, and act on it — or don't — in one continuous session. You are present when the work happens.
After automation, the output exists in a folder. Whether it is reviewed, how carefully, and by whom is now an organizational question rather than a natural workflow step. The automation that was supposed to save time creates a new obligation: a committed review step that someone actually performs.
Teams that treat scheduled output as background noise — letting it accumulate unread — have not gained productivity. They have created a system that produces authoritative-looking documents nobody is responsible for.
The only scheduled tasks worth running are ones where the review step is as defined as the task itself. Who reviews it. How often. What action results from it. Without that, the automation is a false efficiency.
What the "computer must be awake" limitation tells you
Every article about this feature mentions that scheduled tasks require your computer to be awake and the Claude Desktop app to be open. This is framed as a temporary limitation.
The more useful observation: this constraint is fine for the narrow category of tasks that scheduled automation is actually suited for. If you are generating a structured morning briefing at 8am, your computer is on at 8am. If you are running a weekly research summary on Monday, your computer is on Monday.
The constraint only matters if you are trying to use scheduled tasks as always-on infrastructure — overnight log scanning, production monitoring, continuous processing. For that, you need cloud infrastructure. Scheduled tasks are not cloud infrastructure. Using them as a substitute creates gaps that are hard to detect and easy to miss.
What makes a scheduled task worth setting up
Before automating any recurring task, three things need to be true:
The data source is explicit. Not "Claude will figure out what to read" — the task specifies exactly what input Claude processes, with working integrations verified before automation is turned on.
The review step is defined. Someone reads the output on a defined cadence. If the output is wrong, degraded, or based on stale data, they will notice.
The task is genuinely recurring. The same work, the same structure, the same questions, every time. If the task requires judgment about what to include or how to frame it, it is not ready for automation — it requires a human in the loop for each execution.
Scheduled tasks are a legitimate tool for the narrow slice of recurring work that meets these criteria. For everything outside that slice, the manual prompt you write and review yourself is not a shortcut you have skipped — it is the accountability mechanism you have kept.
Scheduled tasks are available in Cowork on Claude Desktop for all paid plans (Pro, Max, Team, and Enterprise). MCP integrations require separate configuration.