Why break scheduled-task failures into checkpoints?
Because the documented problems appear at different stages: where it runs, the workspace, folder access, tool approval and approval mode. What they share is that nobody responds in real time. Splitting them into checkpoints lets you ask "does this step need a person?" at creation time, which is cheaper than debugging afterward.
If the workspace fails to start, does the task still run?
Per the changelog, yes: due Scheduled Tasks start without the workspace after about ten minutes, but commands that need the workspace fail in those runs. A task can therefore look as if it ran while only completing the parts that do not need the workspace. Confirm through the "Scheduled Task failed" notification and the actual results.
What happens to a tool marked "ask" inside a Scheduled Task?
Per the changelog, the run shows an approval prompt and waits instead of skipping it, and a newer run retires an earlier run's unanswered prompt. The documentation does not say whether the wait times out, so do not assume the task gives up by itself. For truly unattended tasks, avoid depending on such tools.
Does the "Automatically approve" default make these problems disappear?
No. Automatic approval only affects whether tools ask first; it does not touch workspace start failures, folder access or tools your organization marks "ask." It also applies only to tasks Claude creates, and only where the organization allows it. The documentation does not explain how the ask policy interacts with this default, so do not assume.
The selling point of Scheduled Tasks is that you do not have to be there. Yet the recent fixes in the official changelog are almost all about a step getting stuck when nobody is. This piece organizes those documented behaviors into five checkpoints to ask about when you create a task. The design advice is my own organization of them, not an official checklist.
From October 6, newly created scheduled tasks run in the cloud, while existing computer-based scheduled tasks keep running on your computer. A local task needs the desktop app and a usable computer, which is the sleep limitation discussed in an earlier article. Work out which side your task is on.
The changelog records that on a computer where Claude's workspace fails to start, due scheduled tasks now start without the workspace after about ten minutes, and commands that need the workspace fail in those runs. In other words, a task may "run" but run in a reduced form.
The October 8 update fixed a case where Claude re-asked for a folder the session already had, leaving scheduled runs waiting on an approval nobody was there to give. That case is fixed, but the lesson stands: confirm the folders a task needs when you create it.
An organization's approval policy can mark some tools "ask." Per the changelog, when a Scheduled Task reaches such a tool, the run now shows the approval prompt and waits instead of skipping it, and a newer run of the same task retires an earlier run's unanswered prompt. The documentation does not say whether the wait times out, so assume it may wait indefinitely.
Since October 1, scheduled tasks Claude creates for you default to "Automatically approve" where your organization allows it: runs use tools directly and pause only when something looks unsafe. Tasks you set up manually are not affected by that default.
Before creating a scheduled task, ask one question: does any step need a person to respond in real time? If so, either redesign it or accept that it will stop and wait. Walk through the folders and tools a task needs when you create it, and watch for the "Scheduled task failed" notification, one of the few unattended signals the product gives you.