Cline's August 19 commit #13331 adds agenda tasks, schedules, Hub commands, task storage, desktop controls, CLI support, and a long run of tests. The important reporting question is not whether the agent has acquired a calendar. It is whether the calendar still knows whose project it belongs to.
A scheduled agent task is a small change in grammar with a large operational consequence. Instead of saying “remind me tomorrow,” a user can eventually find that an agent has a stored prompt, a clock, and a chance to act after the original conversation is gone.
At the source boundary, Cline's new scheduled-task tool accepts the things a useful recurring job needs: a prompt, a one-time timestamp or cron pattern, a timezone, a model choice, and limits. But the mutation path first requires a Hub session, resolves the current workspace, canonicalizes the workspace and working directory, and rejects a record outside that scope. When it creates a schedule, it stores that workspace and tags the creator as the acting agent. A task can outlast a turn without becoming an unmoored instruction.
The hub is part of the permission
The first angle—“agents can now schedule work”—misses the project boundary threaded through the change. Cline's Hub task command service does not take the requested workspace or creator at face value. It resolves the workspace from the authenticated connection, overwrites a task-create payload with that workspace, and records the connection's user as the actor. The matching tests reject a task lookup from another workspace; their vertical slice also shows an unregistered client failing a schedule command before a registered client in the matching workspace can list the agent-created schedule.
That is a useful design line for people who operate agents across repositories. A cron expression is not the whole job identity. The workspace, the client that is allowed to speak for it, and the revision of a task that is approved, run, or cancelled belong in the identity too. Without those details, “run this later” can quietly become “run this wherever the next connection happens to point.”
Durable does not yet mean shipped
The source also refuses a simpler autonomy story. Schedule mutations require an interactive user session in the inspected tool path, while the Hub code makes a client prove a workspace before it can operate the task surface. That does not make every future scheduled run safe, and it does not prove this feature is in a released Cline build. It does make the public design choice visible: durable agent work is being treated as an authority problem, not a reminder feature.
For builders, the next audit is concrete: create two disposable workspaces, attempt to list or alter one schedule from the other, and confirm that the connected client—not a request field—sets the boundary. The next public signal is a release note and integration guidance that state which execution modes carry the same constraint. Until then, the evidence is a carefully scoped main-branch implementation, not a promise about an installed agent.