[FEATURE] Scheduled tasks: pre-authorize directory access

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Scheduled tasks that need to persist data between runs (e.g., a history file that tracks changes over time) currently have no way to access the host filesystem without triggering the request_cowork_directory permission dialog. This dialog requires interactive user approval, which fundamentally conflicts with the purpose of unattended scheduled tasks.

The VM sandbox (by design) cannot see host paths like ~/Documents/ unless explicitly mounted. Even the scheduled task's own skill directory (~/Documents/Claude/Scheduled/{taskId}/) is inaccessible from within the task session.

Proposed Solution

Allow users to pre-authorize one or more directory paths when creating or editing a scheduled task. These paths would be automatically mounted when the task session starts, without requiring interactive approval.

This could look like:

A directories field in the scheduled task configuration
A one-time approval flow at task creation time ("This task will access ~/Documents/backpack-research — Approve?")
Or at minimum, give the task read/write access to its own skill directory (~/Documents/Claude/Scheduled/{taskId}/). The whole point of skills is that they can contain resources like this.

Alternative Solutions

Using the workspace folder: Resets between sessions, can't persist data.
Storing data in the skill directory: Would work conceptually, but the VM can't access it without a mount.
Running manually: Works but eliminates the value of scheduling.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

I have a scheduled task that automates Chrome to scans multiple marketplaces daily for deals (in my case on specific models of backpacks), diffs results against a history file to identify new listings, price drops, and sold items, then produces a report. The history file must persist between runs — that's the whole point. Without it, every scan is starting from zero with no ability to detect changes.

Currently, every automated run hangs waiting for me to manually approve the folder mount, defeating the purpose of scheduling it.

Additional Context

_No response_